Re: [gentoo-dev] Re: The changes about the stabilization process

[Mart Raudsepp]

Ühel kenal päeval, E, 02.01.2017 kell 14:01, kirjutas Rich Freeman:
> On Mon, Jan 2, 2017 at 12:59 PM, M. J. Everitt <m.j.everitt@×××.org>
> wrote:
> >
> > On 02/01/17 17:49, Rich Freeman wrote:
> > >
> > > On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric <kentnl@g.o>
> > > wrote:
> > > >
> > > > On Thu, 29 Dec 2016 17:23:58 +0000
> > > > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote:
> > > >
> > > > >
> > > > > Because it isn't... Are set names atoms? Are package names
> > > > > without an
> > > > > associated category atoms?
> > > > Sets /are/ still dependency specifications, in that reading,
> > > > just like
> > > > >
> > > > > >
> > > > > > ( ) groups are dependency specifications, and lists of
> > > > > > atoms are dependency specifications.
> > > >
> > > > Hence, this is an example of in my mind why "atom" is a
> > > > *better* descriptor than "dependency specification"
> > > >
> > > > Because it rules out sets and all the other shenanigans.
> > > However, in this case why would we want to rule out sets, "and
> > > all the
> > > other shenanigans?"  We've already established that a single
> > > stable
> > > request bug can apply to multiple package-versions, so why not
> > > allow
> > > full dependency specifications?  If there is a set that describes
> > > what
> > > needs to be stabilized in an atomic operation, then what is the
> > > value
> > > in breaking it down into a million separate =-only atoms?
> > >
> > > If the process becomes further aided by automated tools then
> > > using the
> > > same dependency specifications as PMS/etc would allow the same
> > > code to
> > > be used to identify candidate PVs to stabilize.
> > >
> > > Of course in the most typical case you're stabilizing exactly one
> > > PV,
> > > but I'm not sure we need to limit the syntax simply because that
> > > is
> > > all that is required in the most common case.
> > >
> > I don't think we're writing new tools to do this, we're simply
> > using the
> > existing ones better. So, a list of explicit ebuilds by
> > Category/Package-Version is what's desired (I believe). But I'll
> > defer
> > to kensington/ago who are the ones really using this system in
> > anger ...
> >
>
> Even if you don't write new tools, I don't see how sets would cause a
> problem.  A set is just a list of dependency specifications, which is
> what we're otherwise storing.  There is no rule against putting 100
> specific package versions in either.  If you have a set that
> describes
> something like a KDE stabilization I'd think that this would be
> preferable to listing all the KDE packages in the box.
>
> But, if somebody can see a problem this would cause I'm all ears.

Don't overengineer. You can't stable sets. This is a list of things to
stabilize. A list you pretty much copy paste to package.accept_keywords
as the architecture developer. You don't do that with sets. You don't
want to do that with ranges, as you want a concrete list of what to
stabilize - this is the WHOLE point of this exercise - non-vague list
of things in a concrete place, not having to search for it from
comments and whatnot.
It takes a list of package revisions with category, optionally with a =
in front (but it is not necessary), and tools like tatt will be able to
auto-generate a package.accept_keywords and make testing scripts.
https://wiki.gentoo.org/wiki/Package_testing#getatoms can get this list
from bugzilla for you.
https://wiki.gentoo.org/wiki/Package_testing#tatt git version can help
further.

If you don't want to use the box due to too huge list, there is already
the option of leaving the box empty, and marking a single attachment
with stabilisation list flag instead.

Name it how you want, but ultimately this is not important to the
functionality. I suggest "Atom Versions" or "Package revisions".
The documentation will just say to put it in the field named "<whatever
it's named>" and that's it.
Such a documentation is located at
https://wiki.gentoo.org/wiki/Stable_request

It doesn't matter what users name it, maintainers are the ones who
should fill out this field. Or verify it at the time of CCing arches.


Mart