[gentoo-dev] The changes about the stabilization process

[gentoo-dev] The changes about the stabilization process

[Agostino Sarubbo]

Hello all.

with the great and awesome work of Michael Palimaka (kensington) and the 
support of the wg-stable, for the stabilization process, some changes on our 
bugzilla have been done.

We have two new components:
- Stabilization
- Keywording

When you will choose one of those, you will see two new fields:
- Atoms to stabilize
- Runtime testing required


Atoms to stabilize needs to be filled in the following way:
=CATEGORY/PACKAGE-VERSION
so for example:
=app-portage/eix-0.31.10
In this way all arches in CC need to stabilize the specified atom.

When you have multiple atoms with different targets you need to do:
=app-portage/eix-0.31.10 amd64 x86
=app-portage/portage-utils ppc
In the following way, amd64 and x86 will stabilize only eix and ppc will 
stabilize only portage-utils.


Runtime testing required (which is not mandatory) needs to be filled in the 
following way:
- Yes, you are asking to run a package after have compiled/installed it.
- No, you don't need runtime testing (e.g. packages that install only some 
files).


Unfortunately there isn't an automated way to port all current stablereqs to 
those changes, so I will port them to the stabilization component and ask to 
fill properly the "Atoms to stabilize" and "Runtime testing required" fields 
in the next days.

In the near future, we will produce a wiki page which describes how to 
properly request the stabilizations to ensure that they will be processed 
correctly.


NOTE: I'm intending this message as a sort of announcement to invite everyone 
to port their stable requests. I guess there isn't much to discuss here. If 
you don't like some of the changes that have been done, please open a specific 
thread about.

Thanks.


-- 
Agostino Sarubbo
Gentoo Linux Developer

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

On Sun, 25 Dec 2016 13:41:29 +0100
Agostino Sarubbo <ago@gentoo.org> wrote:

> NOTE: I'm intending this message as a sort of announcement to invite everyone 
> to port their stable requests. I guess there isn't much to discuss here. If 
> you don't like some of the changes that have been done, please open a specific 
> thread about.
> 
> Thanks.

A quick rundown on attaching stabilization lists as files might be helpful,
especially in regards to that flag having three states, the "undefined" state (ie: no such flag)
, and both "-" and "+" states.

Also steps to take in regards to getting a "Flags: sanitycheck-" report should be clarified.

( I assume these will all be in the wiki, I'm just jotting them here under the 
presumption that the content of this email and its replies will be used as a baseline
for the wiki )

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Aaron Bauman]

On December 25, 2016 9:49:02 PM GMT+09:00, Kent Fredric <kentnl@gentoo.org> wrote:
>On Sun, 25 Dec 2016 13:41:29 +0100
>Agostino Sarubbo <ago@gentoo.org> wrote:
>
>> NOTE: I'm intending this message as a sort of announcement to invite
>everyone 
>> to port their stable requests. I guess there isn't much to discuss
>here. If 
>> you don't like some of the changes that have been done, please open a
>specific 
>> thread about.
>> 
>> Thanks.
>
>A quick rundown on attaching stabilization lists as files might be
>helpful,
>especially in regards to that flag having three states, the "undefined"
>state (ie: no such flag)
>, and both "-" and "+" states.
>

It is not necessary to use a file now.  Just put the list in the "Atoms to stabilize" as described.


>Also steps to take in regards to getting a "Flags: sanitycheck-" report
>should be clarified.
>
>( I assume these will all be in the wiki, I'm just jotting them here
>under the 
>presumption that the content of this email and its replies will be used
>as a baseline
>for the wiki )

Not an expert and Michael can clarify, but sanity check basically means repoman does not check out. That is, the developer did not provide a proper stable list or target and potentially breaks the stable tree.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]

Hi,

On Sun, 25 Dec 2016 13:41:29 +0100 Agostino Sarubbo wrote:
> Runtime testing required (which is not mandatory) needs to be filled in the 
> following way:
> - Yes, you are asking to run a package after have compiled/installed it.
> - No, you don't need runtime testing (e.g. packages that install only some 
> files).

What is a recommended way to describe how runtime testing should be
done? Some packages are quite complex and it is desired not only to
run them, but to run with some args or do some actions.

Some ideas:

- copying description from one stablereq to another doesn't seem
very practical to me;
- adding comment inside ebuild is possible, but likely be missed
during testing, especially for large ebuilds; also it looks like
somewhat misused of ebuild;
- maybe add new metadata tag like:
<testing>
  Description how to test this package...
</testing>
?

Another question: do we steel need to set STABLEREQ keyword for
stabilization bugs? Since we now have a dedicated Stabilization
component, STABLEREQ looks redundant.

And thank you all for an awesome change :)

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Michael Orlitzky]

On 12/25/2016 02:55 PM, Andrew Savchenko wrote:
> 
> What is a recommended way to describe how runtime testing should be
> done? Some packages are quite complex and it is desired not only to
> run them, but to run with some args or do some actions.
> 
> Some ideas:
> 
> ...

The Emacs team came up with this

  https://wiki.gentoo.org/wiki/Project:Emacs/Test_plans

and I tried to copy it, mostly for my own reference:

  https://wiki.gentoo.org/wiki/Project:Haskell/Test_plans

We could easily extend that idea to individual packages.

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

On Sun, 25 Dec 2016 22:55:27 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:

> <testing>
>   Description how to test this package...
> </testing>

Alternatively, why not have a metatag that just
permits a valid URL that points to testing instructions?

Benefits:

* Multiple packages can share instructions without redundancy
* Edits to the testing instructions can be made without causing commit churn
* Editorial powers for testing instructions can be centralised to a wiki page
  instead of requiring commit powers.
* Can theoretically support URLs such as:
    filesdir://instructions.txt 
  which resolve to ${FILESDIR}

( And similar )

Potential Downsides: 
* Not integrated with portage, meaning you can't just set a feature
  like FEATURES="Show testing instructions" which unifies all <testing> section
  and prints them at the end of the emerge run for you to complete.
  ( And this expands to future things that might be useful to do here, like checklists
    and having a tool that helps guide you through the test plan to make sure all steps are
    performed )




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Mon, 26 Dec 2016 20:49:02 +1300 Kent Fredric wrote:
> On Sun, 25 Dec 2016 22:55:27 +0300
> Andrew Savchenko <bircoph@gentoo.org> wrote:
> 
> > <testing>
> >   Description how to test this package...
> > </testing>
> 
> Alternatively, why not have a metatag that just
> permits a valid URL that points to testing instructions?

Sounds good, as long as it is not mandatory, so if dev wants to put
instructions in this block (e.g. they are small or can't be shared
with other packages).

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Rich Freeman]

On Mon, Dec 26, 2016 at 5:05 AM, Andrew Savchenko <bircoph@gentoo.org> wrote:
> On Mon, 26 Dec 2016 20:49:02 +1300 Kent Fredric wrote:
>> On Sun, 25 Dec 2016 22:55:27 +0300
>> Andrew Savchenko <bircoph@gentoo.org> wrote:
>>
>> > <testing>
>> >   Description how to test this package...
>> > </testing>
>>
>> Alternatively, why not have a metatag that just
>> permits a valid URL that points to testing instructions?
>
> Sounds good, as long as it is not mandatory, so if dev wants to put
> instructions in this block (e.g. they are small or can't be shared
> with other packages).
>

Well, test instructions would never be mandatory, and if you wanted to
recycle them I think the best move is to put them on the wiki and just
post the URL in metadata.

The advantage here would be that automated tools would know where to
find them.  Maybe one day they could be auto-linked in bugs,
integrated into some keywording non-bugzilla tool, into portage/gatt,
and so on.

-- 
Rich

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Sun, 25 Dec 2016 23:32:56 +0900
Aaron Bauman <bman@gentoo.org> wrote:

> It is not necessary to use a file now.  Just put the list in the "Atoms to stabilize" as described.

Well, to an extent it was more a problem I feel the *need* to use this feature already ;)

Because I have some stuff that bumps into utterly crazy lengths that become entirely unreadable
if you have them in the atoms panel.

( working on a keywording list atm that's gonna be 30 lines long easily )

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

>>>>> On Sun, 25 Dec 2016, Agostino Sarubbo wrote:

> with the great and awesome work of Michael Palimaka (kensington) and
> the support of the wg-stable, for the stabilization process, some
> changes on our bugzilla have been done.

Thank you for the great work.

> [...]

> When you will choose one of those, you will see two new fields:
> - Atoms to stabilize

Can you please avoid reintroducing the term "atom" there, when we are
trying to get rid of it elsewhere [1]? Note that PMS doesn't define
the term [2].

Ulrich

[1] https://projects.gentoo.org/council/meeting-logs/20151213-summary.txt
[2] https://bugs.gentoo.org/174322

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michael Palimaka]

On 28/12/16 20:57, Ulrich Mueller wrote:
>>>>>> On Sun, 25 Dec 2016, Agostino Sarubbo wrote:
> 
>> with the great and awesome work of Michael Palimaka (kensington) and
>> the support of the wg-stable, for the stabilization process, some
>> changes on our bugzilla have been done.
> 
> Thank you for the great work.
> 
>> [...]
> 
>> When you will choose one of those, you will see two new fields:
>> - Atoms to stabilize
> 
> Can you please avoid reintroducing the term "atom" there, when we are
> trying to get rid of it elsewhere [1]? Note that PMS doesn't define
> the term [2].

Any suggestions for improved text? Ideally it would be
stabilisation/keywording agnostic as the same field is used in both
components.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On Thu, 29 Dec 2016 03:49:30 +1100
Michael Palimaka <kensington@gentoo.org> wrote:

> On 28/12/16 20:57, Ulrich Mueller wrote:
> >>>>>> On Sun, 25 Dec 2016, Agostino Sarubbo wrote:  
> >   
> >> with the great and awesome work of Michael Palimaka (kensington) and
> >> the support of the wg-stable, for the stabilization process, some
> >> changes on our bugzilla have been done.  
> > 
> > Thank you for the great work.
> >   
> >> [...]  
> >   
> >> When you will choose one of those, you will see two new fields:
> >> - Atoms to stabilize  
> > 
> > Can you please avoid reintroducing the term "atom" there, when we are
> > trying to get rid of it elsewhere [1]? Note that PMS doesn't define
> > the term [2].  
> 
> Any suggestions for improved text? Ideally it would be
> stabilisation/keywording agnostic as the same field is used in both
> components.

How about: package versions?

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

>>>>> On Thu, 29 Dec 2016, Michael Palimaka wrote:

> On 28/12/16 20:57, Ulrich Mueller wrote:
>> Can you please avoid reintroducing the term "atom" there, when we
>> are trying to get rid of it elsewhere [1]? Note that PMS doesn't
>> define the term [2].

> Any suggestions for improved text? Ideally it would be
> stabilisation/keywording agnostic as the same field is used in both
> components.

PMS uses "package dependency specification", but that may be too long
for the name of the field. How about "ebuilds to stabilise"?

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Jeroen Roovers]

On Thu, 29 Dec 2016 03:49:30 +1100
Michael Palimaka <kensington@gentoo.org> wrote:

> > Can you please avoid reintroducing the term "atom" there, when we
> > are trying to get rid of it elsewhere [1]? Note that PMS doesn't
> > define the term [2].  
> 
> Any suggestions for improved text? Ideally it would be
> stabilisation/keywording agnostic as the same field is used in both
> components.

How about "atoms". We've been using that for ages (regardless of what
PMS authors think) so why change it now? Alternatively, I would propose
to call them "bikesheds" as that will work just as well as any other
label and will succinctly refer to the creative process that made it
a replacement for "atoms".


     jer

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

[Ciaran McCreesh]

On Wed, 28 Dec 2016 23:21:51 +0100
Jeroen Roovers <jer@gentoo.org> wrote:
> On Thu, 29 Dec 2016 03:49:30 +1100
> Michael Palimaka <kensington@gentoo.org> wrote:
> > > Can you please avoid reintroducing the term "atom" there, when we
> > > are trying to get rid of it elsewhere [1]? Note that PMS doesn't
> > > define the term [2].    
> > 
> > Any suggestions for improved text? Ideally it would be
> > stabilisation/keywording agnostic as the same field is used in both
> > components.  
> 
> How about "atoms". We've been using that for ages (regardless of what
> PMS authors think) so why change it now? Alternatively, I would
> propose to call them "bikesheds" as that will work just as well as
> any other label and will succinctly refer to the creative process
> that made it a replacement for "atoms".

We made a deliberate decision not to use the word "atom" in PMS because
it means subtly different things in different contexts.

-- 
Ciaran McCreesh

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]

>>>>> On Wed, 28 Dec 2016, Jeroen Roovers wrote:

> How about "atoms". We've been using that for ages (regardless of
> what PMS authors think) so why change it now?

The best definition I could find for "atom" is in ebuild(5):

   A depend atom is simply a dependency that is used by portage when
   calculating relationships between packages.  Please note that if
   the atom has not already been emerged, then the latest version
   available is matched.

The point is that the syntax to be used in a keyword request is not
a general package dependency specification (aka "atom"). You neither
want only CATEGORY/PN there, nor any operators or use dependencies,
nor do you want to match the latest version available. What you want
is a list of CATEGORY/PF each specifying exactly one ebuild. Also,
arch testers keyword ebuilds but not "atoms".

> Alternatively, I would propose to call them "bikesheds" as that will
> work just as well as any other label and will succinctly refer to
> the creative process that made it a replacement for "atoms".

Well, I am just suggesting to use a precise term there, because IMHO
it would help to avoid confusion.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michael Palimaka]

On 29/12/16 03:49, Michael Palimaka wrote:
> On 28/12/16 20:57, Ulrich Mueller wrote:
>>>>>>> On Sun, 25 Dec 2016, Agostino Sarubbo wrote:
>>
>>> with the great and awesome work of Michael Palimaka (kensington) and
>>> the support of the wg-stable, for the stabilization process, some
>>> changes on our bugzilla have been done.
>>
>> Thank you for the great work.
>>
>>> [...]
>>
>>> When you will choose one of those, you will see two new fields:
>>> - Atoms to stabilize
>>
>> Can you please avoid reintroducing the term "atom" there, when we are
>> trying to get rid of it elsewhere [1]? Note that PMS doesn't define
>> the term [2].
> 
> Any suggestions for improved text? Ideally it would be
> stabilisation/keywording agnostic as the same field is used in both
> components.
> 
> 

ago suggested "Packages list" or "Package list" - thoughts?

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]

>>>>> On Thu, 29 Dec 2016, Michael Palimaka wrote:

>> Any suggestions for improved text? Ideally it would be
>> stabilisation/keywording agnostic as the same field is used in both
>> components.

> ago suggested "Packages list" or "Package list" - thoughts?

Isn't it rather a list of "ebuilds" or "package versions"? That's the
term which https://devmanual.gentoo.org/keywording/index.html uses.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 638 bytes --]

On 12/29/2016 01:08 PM, Ulrich Mueller wrote:
>>>>>> On Thu, 29 Dec 2016, Michael Palimaka wrote:
> 
>>> Any suggestions for improved text? Ideally it would be
>>> stabilisation/keywording agnostic as the same field is used in both
>>> components.
> 
>> ago suggested "Packages list" or "Package list" - thoughts?
> 
> Isn't it rather a list of "ebuilds" or "package versions"? That's the
> term which https://devmanual.gentoo.org/keywording/index.html uses.

${PF}-list? :)


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

* Ulrich Mueller schrieb am 29.12.16 um 13:08 Uhr:
> >>>>> On Thu, 29 Dec 2016, Michael Palimaka wrote:
> 
> >> Any suggestions for improved text? Ideally it would be
> >> stabilisation/keywording agnostic as the same field is used in both
> >> components.
> 
> > ago suggested "Packages list" or "Package list" - thoughts?
> 
> Isn't it rather a list of "ebuilds" or "package versions"? That's the
> term which https://devmanual.gentoo.org/keywording/index.html uses.

I'd prefer "package versions" but the people will come up with 
"sys-apps/eix-1.2.3" or just "1.2.3", not the desired 
"=sys-apps/eix-1.2.3". 

"atom" is a well defined term in the gentoo world, so why not use it?

If we really expect something in the field what used to be an "atom" we 
should use the new term for it like "package dependency spec".

But for me "atom" really works best here...


-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
                     6E9E CA3E 7BF6 7F97 9BE5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Jeroen Roovers]

On Wed, 28 Dec 2016 22:31:19 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> We made a deliberate decision not to use the word "atom" in PMS
> because it means subtly different things in different contexts.

You're doing it again! You're not citing any decisions on actual
mailing lists, chat logs or in documentation, and you use qualifications
like "subtl[e]" to denote some deeper rationale that is apparently very
difficult to explain to the "uninitiated". Good job, if your job was to
deter the "uninitiated".

Where was that decision recorded? What subtle differences did you
perceive? Which contexts lead to those different meanings, and why did
you not keep "atom" and qualify it according to context? Did you
document the history, present and future of the term "atom" so you
could point out why it was rejected for future use? Even, what
real-world problem were you trying to solve in rejecting "atom"?


     jer

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 253 bytes --]

>>>>> On Thu, 29 Dec 2016, Marc Schiffbauer wrote:

> I'd prefer "package versions" but the people will come up with 
> "sys-apps/eix-1.2.3" or just "1.2.3", not the desired 
> "=sys-apps/eix-1.2.3". 

Why would the equals sign be needed there?

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Ciaran McCreesh]

On Thu, 29 Dec 2016 16:44:12 +0100
Jeroen Roovers <jer@gentoo.org> wrote:
> On Wed, 28 Dec 2016 22:31:19 +0000
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > We made a deliberate decision not to use the word "atom" in PMS
> > because it means subtly different things in different contexts.  
> 
> You're doing it again! You're not citing any decisions on actual
> mailing lists, chat logs or in documentation, and you use
> qualifications like "subtl[e]" to denote some deeper rationale that
> is apparently very difficult to explain to the "uninitiated". Good
> job, if your job was to deter the "uninitiated".
> 
> Where was that decision recorded? What subtle differences did you
> perceive? Which contexts lead to those different meanings, and why did
> you not keep "atom" and qualify it according to context? Did you
> document the history, present and future of the term "atom" so you
> could point out why it was rejected for future use? Even, what
> real-world problem were you trying to solve in rejecting "atom"?

Unfortunately we had a team of three when writing PMS to begin with,
and the emphasis was on producing a definitive spec, not a history book.
We did not have a volunteer archivist at the time. If you'd like to
volunteer to start, I'm sure you'd be welcome to produce an annotated
PMS for people who are interested in that kind of thing -- the
annotated C++ reference manual was a lovely read, back when it was
maintained.

-- 
Ciaran McCreesh

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

[Ciaran McCreesh]

On Thu, 29 Dec 2016 13:28:12 +0100
Marc Schiffbauer <mschiff@gentoo.org> wrote:
> "atom" is a well defined term in the gentoo world, so why not use it?

Because it isn't... Are set names atoms? Are package names without an
associated category atoms?

-- 
Ciaran McCreesh

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

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

* Ulrich Mueller schrieb am 29.12.16 um 16:52 Uhr:
> >>>>> On Thu, 29 Dec 2016, Marc Schiffbauer wrote:
> 
> > I'd prefer "package versions" but the people will come up with 
> > "sys-apps/eix-1.2.3" or just "1.2.3", not the desired 
> > "=sys-apps/eix-1.2.3". 
> 
> Why would the equals sign be needed there?

I supposed it to do because I assumed that we are not going to change 
the expected values.

But yes, propably only listing the PV would be enough.

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
                     6E9E CA3E 7BF6 7F97 9BE5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

* Ciaran McCreesh schrieb am 29.12.16 um 18:23 Uhr:
> On Thu, 29 Dec 2016 13:28:12 +0100
> Marc Schiffbauer <mschiff@gentoo.org> wrote:
> > "atom" is a well defined term in the gentoo world, so why not use it?
> 
> Because it isn't... Are set names atoms? Are package names without an
> associated category atoms?

That would be subject to extend it, right?

-Marc

-- 
0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07
                     6E9E CA3E 7BF6 7F97 9BE5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Mart Raudsepp]

Ühel kenal päeval, N, 29.12.2016 kell 20:51, kirjutas Marc Schiffbauer:
> * Ulrich Mueller schrieb am 29.12.16 um 16:52 Uhr:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > On Thu, 29 Dec 2016, Marc Schiffbauer wrote:
> > 
> > > 
> > > I'd prefer "package versions" but the people will come up with 
> > > "sys-apps/eix-1.2.3" or just "1.2.3", not the desired 
> > > "=sys-apps/eix-1.2.3". 
> > 
> > Why would the equals sign be needed there?
> 
> I supposed it to do because I assumed that we are not going to
> change 
> the expected values.

To my knowledge the sanity checking tool doesn't care either way.
I've been adding the = in front for now just in case it helps arch
teams to more directly copy-paste the list to their
package.accept_keywords or whatnot.
I'm sure any further tooling like "app-portage/tatt" can or will be
able to handle it either way for the arch dev too.

> But yes, propably only listing the PV would be enough.

You mean PVR, or rather $CATEGORY/$PF.


As my own worthless 2 dimes on the field naming bikeshed, I'd suggest
"Package revisions" (as opposed to just versions).


Additionally I would like such a package revision list or in this case
even ranges to be used outside stabling/keywording as well. For marking
up which package and revision fixes a given bug, as to do independent
semi-automatic tracking of bugs that still affect the stable tree. But
that's a bikeshed and discussion for next year, once the tooling that
could make good use of that gets further along and into this area of
topics. Initial thought was to have it as a separate field anyways
then, sort of like the one that shows up for RESOLVED DUPLICATE closing
of bugs, but for RESOLVED FIXED or some such. Anyways, that's for
another thread, another year :)


Mart

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

On Wed, 28 Dec 2016 21:11:43 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> PMS uses "package dependency specification", but that may be too long
> for the name of the field. How about "ebuilds to stabilise"?
> 
> Ulrich

Reading "man 5 ebuild" 

  Atom Bases
              The base atom is just a full category/packagename.

              Examples:
                   >sys-apps/sed<
                   >sys-libs/zlib<
                   >net-misc/dhcp<

       Atom Versions
              It is nice to be more specific and say that only certain versions of atoms are acceptable.  Note that versions  must  be  combined
              with a prefix (see below).  Hence you may add a version number as a postfix to the base.

              Examples:
                   sys-apps/sed->4.0.5<
                   sys-libs/zlib->1.1.4-r1<
                   net-misc/dhcp->3.0_p2<

This makes me think that: 

1. "Atom" is the term we use for a broad collection of dependency types.
2. Atoms have parts.
3. The parts we want are the "Base name" and "Version" elements.
4. Thus, we want a succinct sub-specifier of atom.

So, Can "atom base-versions" be a thing?

Its much less "Omg" than having to write '$CAT/$PF' or "package dependency specifications"

Especially as the latter is also vague and doesn't actually solve the problem of ambiguity
stating the specific narrow range required.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Thu, 29 Dec 2016 17:23:58 +0000
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> Because it isn't... Are set names atoms? Are package names without an
> associated category atoms?

If I use the content of man 5 ebuild as a guide, I'd say no, sets can't be atoms.

Because sets can't have "base name" and "version" sub components.

sets can't have range specifiers.

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1590 bytes --]

On 02/01/17 16:51, Kent Fredric wrote:
> On Wed, 28 Dec 2016 21:11:43 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>
>> PMS uses "package dependency specification", but that may be too long
>> for the name of the field. How about "ebuilds to stabilise"?
>>
>> Ulrich
> Reading "man 5 ebuild" 
>
>   Atom Bases
>               The base atom is just a full category/packagename.
>
>               Examples:
>                    >sys-apps/sed<
>                    >sys-libs/zlib<
>                    >net-misc/dhcp<
>
>        Atom Versions
>               It is nice to be more specific and say that only certain versions of atoms are acceptable.  Note that versions  must  be  combined
>               with a prefix (see below).  Hence you may add a version number as a postfix to the base.
>
>               Examples:
>                    sys-apps/sed->4.0.5<
>                    sys-libs/zlib->1.1.4-r1<
>                    net-misc/dhcp->3.0_p2<
>
> This makes me think that: 
>
> 1. "Atom" is the term we use for a broad collection of dependency types.
> 2. Atoms have parts.
> 3. The parts we want are the "Base name" and "Version" elements.
> 4. Thus, we want a succinct sub-specifier of atom.
>
> So, Can "atom base-versions" be a thing?
>
> Its much less "Omg" than having to write '$CAT/$PF' or "package dependency specifications"
>
> Especially as the latter is also vague and doesn't actually solve the problem of ambiguity
> stating the specific narrow range required.
>
>
"atom version" should work no? (minus pre-/suffix ofc)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Rich Freeman]

On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric <kentnl@gentoo.org> wrote:
> On Thu, 29 Dec 2016 17:23:58 +0000
> Ciaran McCreesh <ciaran.mccreesh@googlemail.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.

-- 
Rich

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1786 bytes --]

On 02/01/17 17:49, Rich Freeman wrote:
> On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric <kentnl@gentoo.org> wrote:
>> On Thu, 29 Dec 2016 17:23:58 +0000
>> Ciaran McCreesh <ciaran.mccreesh@googlemail.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 ...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Ciaran McCreesh]

On Tue, 3 Jan 2017 05:56:56 +1300
Kent Fredric <kentnl@gentoo.org> wrote:
> On Thu, 29 Dec 2016 17:23:58 +0000
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
> > Because it isn't... Are set names atoms? Are package names without
> > an associated category atoms?  
> 
> If I use the content of man 5 ebuild as a guide, I'd say no, sets
> can't be atoms.

What about if you read the user-oriented documentation, which has a
different semi-definition?

-- 
Ciaran McCreesh

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

[Rich Freeman]

On Mon, Jan 2, 2017 at 12:59 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> On 02/01/17 17:49, Rich Freeman wrote:
>> On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric <kentnl@gentoo.org> wrote:
>>> On Thu, 29 Dec 2016 17:23:58 +0000
>>> Ciaran McCreesh <ciaran.mccreesh@googlemail.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.

-- 
Rich

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@iee.org>
> wrote:
> > 
> > On 02/01/17 17:49, Rich Freeman wrote:
> > > 
> > > On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric <kentnl@gentoo.org>
> > > wrote:
> > > > 
> > > > On Thu, 29 Dec 2016 17:23:58 +0000
> > > > Ciaran McCreesh <ciaran.mccreesh@googlemail.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

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]

On Mon, 2 Jan 2017 12:49:59 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> 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?

That rather complicates validation.

Mostly, because if you declare a list of dependencies, if any of them is a range,
the subgraph of that specific atom becomes variable, not constant.

Which means you may have omitted one of the possible dependencies from one of the possible
subgraphs that an AT/Keyworder will see.

This IMO would mostly negate the utility of submitter defined lists of specifications.

In that, by making the submitter resolve it all, its either "good" or "bad"

Instead of leaving the person doing the testing in a confused state about which packages
are expected to be used.

The sets as defined should either work, and the person doing them should get each and every one
working as expected, or none of them should, and it should be pushed back to the submitter to
fix their specification.

Levity in tester interpretation is likely to introduce side effects.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Rich Freeman]

On Tue, Jan 3, 2017 at 6:28 PM, Kent Fredric <kentnl@gentoo.org> wrote:
>
> In that, by making the submitter resolve it all, its either "good" or "bad"
>
> Instead of leaving the person doing the testing in a confused state about which packages
> are expected to be used.
>

Well, assuming that a human is actually the one figuring it out.

But, yes, I agree with your general point the way we do things today...

-- 
Rich

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

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 302 bytes --]

Hi all,

On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
[...]
> Another question: do we steel need to set STABLEREQ keyword for
> stabilization bugs? Since we now have a dedicated Stabilization
> component, STABLEREQ looks redundant.

Ping here.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

[Michael Palimaka]

On 04/01/17 12:57, Andrew Savchenko wrote:
> Hi all,
> 
> On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
> [...]
>> Another question: do we steel need to set STABLEREQ keyword for
>> stabilization bugs? Since we now have a dedicated Stabilization
>> component, STABLEREQ looks redundant.
> 
> Ping here.
> 
> Best regards,
> Andrew Savchenko
> 

With the changes, STABLEREQ and KEYWORDREQ indeed become redundant.

That said, it's entirely possible some arch team members are relying on
these keywords for old saved searches etc. With so many people working
in isolation, it's difficult to know who is doing what.

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 791 bytes --]

On 04/01/17 07:09, Michael Palimaka wrote:
> On 04/01/17 12:57, Andrew Savchenko wrote:
>> Hi all,
>>
>> On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
>> [...]
>>> Another question: do we steel need to set STABLEREQ keyword for
>>> stabilization bugs? Since we now have a dedicated Stabilization
>>> component, STABLEREQ looks redundant.
>> Ping here.
>>
>> Best regards,
>> Andrew Savchenko
>>
> With the changes, STABLEREQ and KEYWORDREQ indeed become redundant.
>
> That said, it's entirely possible some arch team members are relying on
> these keywords for old saved searches etc. With so many people working
> in isolation, it's difficult to know who is doing what.
>
If in any doubt .. set *everything* Lol .. you maximise your chances
then !! :D


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1099 bytes --]

On 01/04/2017 08:09 AM, Michael Palimaka wrote:
> On 04/01/17 12:57, Andrew Savchenko wrote:
>> Hi all,
>>
>> On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
>> [...]
>>> Another question: do we steel need to set STABLEREQ keyword for
>>> stabilization bugs? Since we now have a dedicated Stabilization
>>> component, STABLEREQ looks redundant.
>>
>> Ping here.
>>
>> Best regards,
>> Andrew Savchenko
>>
> 
> With the changes, STABLEREQ and KEYWORDREQ indeed become redundant.
> 
> That said, it's entirely possible some arch team members are relying on
> these keywords for old saved searches etc. With so many people working
> in isolation, it's difficult to know who is doing what.
> 

Not sure if I like this, isn't it anyways still required for security
vulnerabilities bumping etc, so now we have a branching of processes
depending on project/category selections that needs to be taken into
consideration?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]