Attachment 71815 Details for Bug 156154

MEssage

p (text/plain), 3.54 KB, created by Andreas Gruenbacher on 2006-03-08 17:14:00 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Andreas Gruenbacher

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

Size: 3.54 KB

patch

obsolete

>From agruen@suse.de Wed Mar  8 16:55:06 2006
>From: Andreas Gruenbacher <agruen@suse.de>
>Organization: Novell, SUSE Labs
>To: Frank Seidel <fseidel@suse.de>
>Subject: Re: kABI-Test-Erweiterung
>Date: Wed, 8 Mar 2006 16:55:06 +0100
>User-Agent: KMail/1.9.1
>Cc: Oliver Ries <ories@suse.de>
>References: <200602071515.58899.fseidel@suse.de> <200602200149.35101.agruen@suse.de> <200603081628.23350.fseidel@suse.de>
>In-Reply-To: <200603081628.23350.fseidel@suse.de>
>X-KMail-Link-Message: 112101
>X-KMail-Link-Type: reply
>MIME-Version: 1.0
>Content-Type: text/plain;
>  charset="iso-8859-15"
>Content-Transfer-Encoding: 8bit
>Content-Disposition: inline
>Message-Id: <200603081655.06417.agruen@suse.de>
>Status: RO
>X-Status: RSC
>X-KMail-EncryptionState:  
>X-KMail-SignatureState:  
>X-KMail-MDN-Sent:  
>
>On Wednesday, 08 March 2006 16:28, Frank Seidel wrote:
>> Mh, veto. Schicken können Sie von mir aus so viele (Tar-Balls) auf einmal
>> wie sie wollen, aber bitte jeweils nur eine Arch (je Skript-Lauf/Arch).
>> Das ist/wäre mir - allein schon zur Fehlererkennung - wesentlich lieber.
>> Wenn sich dann einzelne Module (aus Versehen etc.) aus einer anderen Arch
>> dazwischenmogeln kann ich das gut erkennen.
>> Wenn wir auf einen Lauf mehrere Architekturen erlauben, sehe ich - von
>> meinem jetzigen (vielleicht naiven) Standpunkt aus - das Problem, dass sie
>> evtl. bei einer der Architekturen ein Modul vergessen könnten bzw. jenes
>> aus irgendeinem Grund auf dieser Architektur nicht notwendig ist. Den
>> Unterschied zwischen den beiden Fällen zu erkennen sehe dabei als
>> eigentliches Problem (neben dem zusätzlichen Aufwand für die
>> Implementierung).
>> Kurzum, es würde mir weniger Bauchschmerzen bereiten, wenn wir sagen
>> könnten, einen Aufruf je Arch. ... Es sei denn natürlich, Du hälst das
>> wirklich für essentiell wichtig.
>
>Vor mir aus, wir können auch abbrechen, wenn Architecturen gemischt sind. 
>Trotzdem sollten wir die Architektur automatisch erkennen.
>
>> > # Define sort order, etc.
>> > export LC_ALL=POSIX
>> > ...
>> > Der modinfo - Teil ist uns wichtig: Wir bekommen darüber ein paar
>> > Zusatzinformationen die uns möglicherweise helfen werden Probleme
>> > leichter zu finden, und wir bekommen mit, welche Hardware-IDs (PCI, USB,
>> > usw.) die Module unterstützen.
>> >
>> > Wir wollen hier sortieren, damit wir in svn-Diffs besser sehen was sich
>> > geändert hat, soweit das geht.
>>
>> Uh, grundsätzlich stimme ich zu, aber durch das geänderte Ausgabeformat/die
>> zusätzlichen Infos oben sehe ich das Problem, dass das viele viele
>> Änderungen in den Test-Skripten nachsich ziehen wird.
>> Wie wärs, wenn ich die zusätzlichen Infos in ein separates File ablege?
>
>Da bin ich dagegen: das führt mit Sicherheit dazu, dass die Files irgendwann 
>nicht mehr zusammenpassen, und damit ist das ganze dann ziemlich wertlos. Die 
>Kommentare wegzufiltern sollte nicht schwer sein.
>
>> > Empfängerseite auch versuchen, mehrere Attachments zu erkennen. Dort muss
>> > man natürlich etwas aufpassen dass das Script nichts tut, was es nicht
>> > soll, damit Partner keine bösen Dinge tun können. Das würde 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önnen wir dann von der Kommandozeile die
>> > Signaturen und die erlaubten Absender überprüfen.
>>
>> Mh, grundsätzlich stimme ich hier auch zu, aber das noch für das erste
>> Release mit einzubauen... ich werd' mir ansehen, wie bzw. mit welchem
>> Aufwand ich das vernünftig einbauen könnte.
>
>Das kommt nach all den anderen Änderungen, schon klar.
>
>Andreas
>

Actions: View

Attachments on bug 156154: 71815 | 71816