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

[Kristian Fiskerstrand]

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



signature.asc
Description: OpenPGP digital signature

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

[M. J. Everitt]

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



signature.asc
Description: OpenPGP digital signature

[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

[Rich Freeman]

On Tue, Jan 3, 2017 at 6:28 PM, Kent Fredric  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] Re: The changes about the stabilization process

[Kent Fredric]

On Mon, 2 Jan 2017 12:49:59 -0500
Rich Freeman  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.



pgpm4inpuSDyM.pgp
Description: OpenPGP digital signature

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 
> wrote:
> > 
> > On 02/01/17 17:49, Rich Freeman wrote:
> > > 
> > > On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric 
> > > wrote:
> > > > 
> > > > On Thu, 29 Dec 2016 17:23:58 +
> > > > Ciaran McCreesh  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 "" 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

[Rich Freeman]

On Mon, Jan 2, 2017 at 12:59 PM, M. J. Everitt  wrote:
> On 02/01/17 17:49, Rich Freeman wrote:
>> On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric  wrote:
>>> On Thu, 29 Dec 2016 17:23:58 +
>>> Ciaran McCreesh  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

[Ciaran McCreesh]

On Tue, 3 Jan 2017 05:56:56 +1300
Kent Fredric  wrote:
> On Thu, 29 Dec 2016 17:23:58 +
> Ciaran McCreesh  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

[M. J. Everitt]

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



signature.asc
Description: OpenPGP digital signature

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

[Rich Freeman]

On Mon, Jan 2, 2017 at 11:56 AM, Kent Fredric  wrote:
> On Thu, 29 Dec 2016 17:23:58 +
> Ciaran McCreesh  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]

On 02/01/17 16:51, Kent Fredric wrote:
> On Wed, 28 Dec 2016 21:11:43 +0100
> Ulrich Mueller  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)



signature.asc
Description: OpenPGP digital signature

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

[Kent Fredric]

On Thu, 29 Dec 2016 17:23:58 +
Ciaran McCreesh  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.


pgpqtCEMgbd16.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Wed, 28 Dec 2016 21:11:43 +0100
Ulrich Mueller  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.




pgp7A7v4uIFir.pgp
Description: OpenPGP digital signature

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

[Marc Schiffbauer]

* Ciaran McCreesh schrieb am 29.12.16 um 18:23 Uhr:
> On Thu, 29 Dec 2016 13:28:12 +0100
> Marc Schiffbauer  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


signature.asc
Description: PGP signature

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

[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.

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

-Marc

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


signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

On Thu, 29 Dec 2016 13:28:12 +0100
Marc Schiffbauer  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

[Ciaran McCreesh]

On Thu, 29 Dec 2016 16:44:12 +0100
Jeroen Roovers  wrote:
> On Wed, 28 Dec 2016 22:31:19 +
> Ciaran McCreesh  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

[Ulrich Mueller]

> 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


pgpPFAUVWZSRj.pgp
Description: PGP signature

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

[Jeroen Roovers]

On Wed, 28 Dec 2016 22:31:19 +
Ciaran McCreesh  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

[Marc Schiffbauer]

* 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


signature.asc
Description: PGP signature

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

[Kristian Fiskerstrand]

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



signature.asc
Description: OpenPGP digital signature

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

[Ulrich Mueller]

> 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


pgpIjsCkY6tbn.pgp
Description: PGP signature

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

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

[Ulrich Mueller]

> 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


pgpfIi2fUZzYu.pgp
Description: PGP signature

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

[Ciaran McCreesh]

On Wed, 28 Dec 2016 23:21:51 +0100
Jeroen Roovers  wrote:
> On Thu, 29 Dec 2016 03:49:30 +1100
> Michael Palimaka  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

[Jeroen Roovers]

On Thu, 29 Dec 2016 03:49:30 +1100
Michael Palimaka  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

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

[Ulrich Mueller]

> 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


pgpmnuTmlJynS.pgp
Description: PGP signature

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

[Michał Górny]

On Thu, 29 Dec 2016 03:49:30 +1100
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.

How about: package versions?

-- 
Best regards,
Michał Górny



pgpNboKaf4YmM.pgp
Description: OpenPGP digital signature

[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.