[gentoo-dev] Re: Improving the stabilisation process - part 1

[Michael Palimaka]

On 25/11/16 17:40, Jason Zaman wrote:
> On Fri, Nov 25, 2016 at 05:54:41PM +1300, Kent Fredric wrote:
>> On Fri, 25 Nov 2016 06:41:20 +1100
>> Michael Palimaka <kensington@g.o> wrote:
>>
>>> Example atom list from a bug with amd64, arm, and x86 in CC:
>>>
>>> =app-foo/bar-1.2.3           # will be stabilised on amd64, arm, and x86
>>> =app-foo/baz-2.3.4 amd64 x86 # will be stabilised on only amd64 and x86
>>
>> I was doing this in the past, but there's a reason I stopped:
>>
>> Bugzilla-enforced wordwrap ( at least, this is very strict on the bugzilla-email relay )
>>
>>> =app-foo/bar-1.2.3           # will be stabilised on amd64, arm, and x86
>>
>> Could become more like
>>
>>> =app-foo/bar-1.2.3           # will be stabilised on amd64,
>>> arm, and x86
>
> One way would be to use a plain text attachment with a standardized
> filename. If there are updates to the list then the new should obsolete
> the old and the script can pull non-obsoleted ones.
> The problem then is how do you search for them properly? put them all
> in the title anyway? then its duplicated.

While I personally think the additional field is adequate, I'm more than
happy to support attachments as well. Suggestions for the standardised
filename? Alternatively, it would easy to add a flag to the interface to
mark an attachment as a stabilisation list.

> When i do big lists of packages the title is eg "XFCE Stabilization for
> Nov 2016" which is not duplicated and okay.
> For single packages the title is just "cat/pkg-1.2.3 stablereq" so then
> we duplicate anyway?

Yes, every atom should be referenced either in the special field (or as
per above in an attachment), even if that means duplicating the title.
It's a very minor effort on the part of the person filing the bug, but
it will guarantee that we can always find the atom list in the same
place every time.

Of course, we can't *force* anyone to use the new field if they don't
want to. They might find themselves wondering why their request ends up
on the bottom of the queue however. :-)