Attachment 71816 Details for Bug 156154

q (text/plain), 4.97 KB, created by Andreas Gruenbacher on 2006-03-08 17:14:24 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Andreas Gruenbacher

Created: 2006-03-08 17:14:24 UTC

Size: 4.97 KB

patch

obsolete

>From fseidel@suse.de Wed Mar  8 17:04:51 2006
>Return-Path: <fseidel@suse.de>
>Received: from imap.suse.de ([unix socket])
>	by imap-dhs (Cyrus v2.1.16) with LMTP; Wed, 08 Mar 2006 17:05:04 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from Relay1.suse.de (relay1.suse.de [149.44.160.87])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(Client CN "relay.suse.de", Issuer "SuSE Linux AG internal IMAP-Server CA" (verified OK))
>	by imap.suse.de (Postfix) with ESMTP id 46E814E9437
>	for <agruen@imap-dhs.suse.de>; Wed,  8 Mar 2006 17:05:04 +0100 (CET)
>Received: by Relay1.suse.de (Postfix)
>	id 371626188B; Wed,  8 Mar 2006 17:05:04 +0100 (CET)
>Received: from tuxbox.suse.de (tuxbox.suse.de [10.10.2.164])
>	(using TLSv1 with cipher RC4-MD5 (128/128 bits))
>	(No client certificate requested)
>	by Relay1.suse.de (Postfix) with ESMTP id 3328D47FA4;
>	Wed,  8 Mar 2006 17:05:04 +0100 (CET)
>From: Frank Seidel <fseidel@suse.de>
>Organization: SUSE LINUX Products GmbH
>To: Andreas Gruenbacher <agruen@suse.de>
>Subject: Re: kABI-Test-Erweiterung
>Date: Wed, 8 Mar 2006 17:04:51 +0100
>User-Agent: KMail/1.8.2
>Cc: Oliver Ries <ories@suse.de>
>References: <200602071515.58899.fseidel@suse.de> <200603081628.23350.fseidel@suse.de> <200603081655.06417.agruen@suse.de>
>In-Reply-To: <200603081655.06417.agruen@suse.de>
>MIME-Version: 1.0
>Content-Type: multipart/signed;
>  boundary="nextPart1617569.dgHat14P3H";
>  protocol="application/pgp-signature";
>  micalg=pgp-sha1
>Content-Transfer-Encoding: 7bit
>Message-Id: <200603081705.01950.fseidel@suse.de>
>X-Length: 5141
>X-UID: 127387
>
>--nextPart1617569.dgHat14P3H
>Content-Type: text/plain;
>  charset="utf-8"
>Content-Transfer-Encoding: quoted-printable
>Content-Disposition: inline
>
>Am Mittwoch 08 M=C3=A4rz 2006 16:55 schrieb Andreas Gruenbacher:
>> On Wednesday, 08 March 2006 16:28, Frank Seidel wrote:
>> > ...
>> > Kurzum, es w=FCrde mir weniger Bauchschmerzen bereiten, wenn wir sagen
>> > k=F6nnten, einen Aufruf je Arch. ... Es sei denn nat=FCrlich, Du h=E4ls=
>t das
>> > wirklich f=FCr essentiell wichtig.
>>
>> Vor mir aus, wir k=F6nnen auch abbrechen, wenn Architecturen gemischt sin=
>d.
>Ja, genau so hatte ich mir das vorgestellt.
>
>> Trotzdem sollten wir die Architektur automatisch erkennen.
>=46reilich, das sowieso. Sorry, wenn das falsch r=C3=BCbergekommen ist.
>
>> > > # Define sort order, etc.
>> > > export LC_ALL=3DPOSIX
>> > > ...
>> > > Der modinfo - Teil ist uns wichtig: Wir bekommen dar=FCber ein paar
>> > > Zusatzinformationen die uns m=F6glicherweise helfen werden Probleme
>> > > leichter zu finden, und wir bekommen mit, welche Hardware-IDs (PCI,
>> > > USB, usw.) die Module unterst=FCtzen.
>> > >
>> > > Wir wollen hier sortieren, damit wir in svn-Diffs besser sehen was si=
>ch
>> > > ge=E4ndert hat, soweit das geht.
>> >
>> > Uh, grunds=E4tzlich stimme ich zu, aber durch das ge=E4nderte
>> > Ausgabeformat/die zus=E4tzlichen Infos oben sehe ich das Problem, dass =
>das
>> > viele viele =C4nderungen in den Test-Skripten nachsich ziehen wird.
>> > Wie w=E4rs, wenn ich die zus=E4tzlichen Infos in ein separates File abl=
>ege?
>>
>> Da bin ich dagegen: das f=FChrt mit Sicherheit dazu, dass die Files
>> irgendwann nicht mehr zusammenpassen, und damit ist das ganze dann ziemli=
>ch
>> wertlos. Die Kommentare wegzufiltern sollte nicht schwer sein.
>Von schwierig war nicht die Rede. Ich habe blos Angst vor Seiteneffekten, w=
>eil
>der Zugriff im Augenblick nicht an einer Stelle zusammenl=C3=A4uft (wo man =
>dass=20
>perfekt regeln k=C3=B6nnte), sondern fast jedes Skript selbst irgendwo auf =
>diese
>=46iles zugreift.=20
>Aber ok, dann mach ich das so.
>
>> > > Empf=E4ngerseite auch versuchen, mehrere Attachments zu erkennen. Dort
>> > > muss man nat=FCrlich etwas aufpassen dass das Script nichts tut, was =
>es
>> > > nicht soll, damit Partner keine b=F6sen Dinge tun k=F6nnen. Das w=FCr=
>de
>> > > ich dadurch versuchen zu erleichtern, dass wir von den Partnern
>> > > GPG-Signaturen verlangen. Dann sehen wir in Mail-Clients ob das alles
>> > > passt, und in einem weiteren Schritt k=F6nnen wir dann von der
>> > > Kommandozeile die Signaturen und die erlaubten Absender =FCberpr=FCfe=
>n.
>> >
>> > Mh, grunds=E4tzlich stimme ich hier auch zu, aber das noch f=FCr das er=
>ste
>> > Release mit einzubauen... ich werd' mir ansehen, wie bzw. mit welchem
>> > Aufwand ich das vern=FCnftig einbauen k=F6nnte.
>>
>> Das kommt nach all den anderen =C4nderungen, schon klar.
>>
>> Andreas
>Ok, ich denke, dann haben wir alles gekl=C3=A4rt. :)
>
>Viele Gr=C3=BC=C3=9Fe,
> Frank
>=2D---------------------------------------------------------------
>Dipl.-Inf. (FH) Frank Seidel - Engineer Quality Assurance
>SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
>Tel.: =C2=A0+49 (0) 911 / 74053 - 468   Email: fseidel@suse.de
>=2D---------------------------------------------------------------
>
>--nextPart1617569.dgHat14P3H
>Content-Type: application/pgp-signature
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.2 (GNU/Linux)
>
>iD8DBQBEDwCtlizSENHXK2gRAsZuAJ960qoRGzPBJB/PZGgxpHstpSIz2QCfVJro
>mwMFBTscJs8B1G2ajuMa2jc=
>=hpvC
>-----END PGP SIGNATURE-----
>
>--nextPart1617569.dgHat14P3H--
>

Actions: View

Attachments on bug 156154: 71815 | 71816