[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Improving the stabilisation process - part 1
From:       Kent Fredric <kentnl () gentoo ! org>
Date:       2016-11-28 2:27:28
Message-ID: 20161128152728.77def3cd () katipo2 ! lan
[Download RAW message or body]


On Sat, 26 Nov 2016 17:32:02 -0600
William Hubbs <williamh@gentoo.org> wrote:

> Listing the architectures seems redundant if they are also in the cc:
> field. In your example above, why would you need arm in the cc: field
>  for app-foo/bas-2.3.4?

Often, the required work for "lists of keywords/stabilizations" has inconsistency.

e.g: Often you'll have only a few packages that need actioned on one arch
and you'll need a dozen or so that need actioned on others.

Hence, breaking them down to have keywords on the atom lines allows for a quick
grep of what's affected.

For example, https://bugs.gentoo.org/show_bug.cgi?id=599550#c0

Where I sorted everything to minimise how tall each list would be.

Only 3 packages needed actioned to satisfy ~arm, ~hppa and ~ppc

7 packages needed action for ~alpha

10 packages needed action for ~ppc64

and 14 packages needed action for ~ia64 and ~sparc

People who process such lists of course are free to ignore this metadata.

But I'd imagine having a short checklist of "tweak these and it should work" 
to be helpful.

*especially* given the current default behaviour of `ekeyword`, where calling

  ekeyword ~foo

Will unintentionally downgrade stable to ~arch, even though the point was to
change from unkeyworded to ~arch.

Surely though, we could fix that?

   ekeyword --as-needed ~foo PKGHERE

Plz? 


[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]