Re: [gentoo-dev] [PATCH] glep-0068: Add new element
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On 2020/09/16 11:39, Michał Górny wrote:
> On Wed, 2020-09-16 at 11:13 +0200, Jaco Kroon wrote:
>>
>>> +- at most one element containing
version
>>> + constraints used to determine stabilization candidates, as detailed
>>> + in `Stabilization candidates`_.
>>> +
>> At most one ...
>
> Do you mean capatilization? It's following suit with other items here.
Sorry, was unclear, this correlates with the second comment below.
>>> - zero or more elements, possibly restricted
>>> to specific package versions (at most one for each version) whose
presence
>>> indicates that the appropriate ebuilds are suitable for
simultaneously
>>> @@ -199,6 +203,25 @@ The element can contain the
following elements:
>>> - at most one element describing the role of
subslots (all
>>> of them) as text.
>>>
>>> +Stabilization candidates
>>> +
>>> +Each element describes version
>>
>> vs each (implies any number). I'd simply say, "If present, the
``
> Again, this follows suit with other descriptions.
If this is the standard, this is the standard, was just trying to point
out that this could be considered a conflict.
>>> +constraints used to determine package versions eligible
>>> +for stabilization. Should this element be missing, the tooling assumes
>>> +a default of any version with any keywords present (i.e. the equivalent
>>> +of ``>=0``).
>>> +
>>> +The element can contain the following
>>> +elements:
>>> +
>>> +- one or more elements, each containing a version
>>> + constraint in the format matching EAPI 0 dependency specification
>>> + with the package category and name parts omitted, e.g. ``<1.7``.
>>> + The tooling considers any ebuild version that satisfies the
constraint
>>> + and has any keywords. If multiple constraints are provided,
every one
>>> + of them is matched separately, and multiple stabilization candidates
>>> + can be reported.
>>
>> I think it's clear from context that there should be one or more, but
>> the language ("can contain" in the leading paragraph) implies all sub
>> elements are optional. Perhaps:
>>
>> The ... element:
>>
>> - must contain one or more ...
>>
>> Which also allows for future "may contain" sub elements.
>>
>
> To be honest, I'm not sure if we should permit or prohibit empty element
> in the spec.
pick one. But I'd use the word may (clearly optional) or must (clearly
compulsory) rather than can.
Kind Regards,
Jaco
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl9h9YMACgkQCC3Esa/3
7p5XtQf9H6kcStCzBz75rOVhoswzhIafZWXJnurAYHvEvM3vrWrMzh46Bc3aZZLo
fo2+lg7Z9lw0iBxJjub/nexBR9D8XwCa3aW/G75Hgd5XcC54LfKRFGqGKHS9Zu9z
GT96Ijqo4aS2PlepD0Qk8jVTnngzB5opasH3nNgR2u6WSEQHtkCE8lg2A1Z0hr3i
PmO/kzvHnZxsais9wp7kkZn+ftGbI1Wuq6Gus3Yy3qWp2k6KTwD49VdN3y7Skk3s
T3ULl/+ui/FqwGGDjlQw0MW8o2mJ76VrQoMTiMG7IErFz9BzJ3djf/bgXg8YjHc5
kjo/h1tLcj7WvLphz9gdhGt4Sk85Sw==
=WdPf
-END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH] glep-0068: Add new element
On Wed, 2020-09-16 at 11:13 +0200, Jaco Kroon wrote:
> Hi Michał,
>
> Thanks for your efforts. This looks interesting at the very least, and
> whilst in many cases on posts on this ML I'm on the "don't care" stance,
> this one looks like it could solve some problems for me.
> net-misc/asterisk + friends will definitely make use of this.
>
> Two nitpicks below that doesn't really carry significant meaning.
>
> On 2020/09/16 07:48, Michał Górny wrote:
>
> > Signed-off-by: Michał Górny
> > ---
> > glep-0068.rst | 62 ---
> > 1 file changed, 59 insertions(+), 3 deletions(-)
> >
> > diff --git a/glep-0068.rst b/glep-0068.rst
> > index d8fc379..5b7e2b9 100644
> > --- a/glep-0068.rst
> > +++ b/glep-0068.rst
> > @@ -4,10 +4,10 @@ Title: Package and category metadata
> > Author: Michał Górny
> > Type: Standards Track
> > Status: Final
> > -Version: 1.1
> > +Version: 1.2
> > Created: 2016-03-14
> > -Last-Modified: 2020-05-06
> > -Post-History: 2016-03-16, 2018-02-20
> > +Last-Modified: 2020-09-16
> > +Post-History: 2016-03-16, 2018-02-20, 2020-09-16
> > Content-Type: text/x-rst
> > Requires: 67
> > Replaces: 34, 46, 56
> > @@ -149,6 +149,10 @@ element can contain, in any order:
> >languages (at most one for each language), as detailed
> >in `Slot descriptions`_.
> >
> > +- at most one element containing version
> > + constraints used to determine stabilization candidates, as detailed
> > + in `Stabilization candidates`_.
> > +
> At most one ...
Do you mean capatilization? It's following suit with other items here.
> > - zero or more elements, possibly restricted
> >to specific package versions (at most one for each version) whose
> > presence
> >indicates that the appropriate ebuilds are suitable for simultaneously
> > @@ -199,6 +203,25 @@ The element can contain the following
> > elements:
> > - at most one element describing the role of subslots (all
> >of them) as text.
> >
> > +Stabilization candidates
> > +
> > +Each element describes version
>
> vs each (implies any number). I'd simply say, "If present, the ``
> > +constraints used to determine package versions eligible
> > +for stabilization. Should this element be missing, the tooling assumes
> > +a default of any version with any keywords present (i.e. the equivalent
> > +of ``>=0``).
> > +
> > +The element can contain the following
> > +elements:
> > +
> > +- one or more elements, each containing a version
> > + constraint in the format matching EAPI 0 dependency specification
> > + with the package category and name parts omitted, e.g. ``<1.7``.
> > + The tooling considers any ebuild version that satisfies the constraint
> > + and has any keywords. If multiple constraints are provided, every one
> > + of them is matched separately, and multiple stabilization candidates
> > + can be reported.
>
> I think it's clear from context that there should be one or more, but
> the language ("can contain" in the leading paragraph) implies all sub
> elements are optional. Perhaps:
>
> The ... element:
>
> - must contain one or more ...
>
> Which also allows for future "may contain" sub elements.
>
To be honest, I'm not sure if we should permit or prohibit empty element
in the spec.
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] glep-0068: Add new element
Hi Michał,
Thanks for your efforts. This looks interesting at the very least, and
whilst in many cases on posts on this ML I'm on the "don't care" stance,
this one looks like it could solve some problems for me.
net-misc/asterisk + friends will definitely make use of this.
Two nitpicks below that doesn't really carry significant meaning.
On 2020/09/16 07:48, Michał Górny wrote:
> Signed-off-by: Michał Górny
> ---
> glep-0068.rst | 62 ---
> 1 file changed, 59 insertions(+), 3 deletions(-)
>
> diff --git a/glep-0068.rst b/glep-0068.rst
> index d8fc379..5b7e2b9 100644
> --- a/glep-0068.rst
> +++ b/glep-0068.rst
> @@ -4,10 +4,10 @@ Title: Package and category metadata
> Author: Michał Górny
> Type: Standards Track
> Status: Final
> -Version: 1.1
> +Version: 1.2
> Created: 2016-03-14
> -Last-Modified: 2020-05-06
> -Post-History: 2016-03-16, 2018-02-20
> +Last-Modified: 2020-09-16
> +Post-History: 2016-03-16, 2018-02-20, 2020-09-16
> Content-Type: text/x-rst
> Requires: 67
> Replaces: 34, 46, 56
> @@ -149,6 +149,10 @@ element can contain, in any order:
>languages (at most one for each language), as detailed
>in `Slot descriptions`_.
>
> +- at most one element containing version
> + constraints used to determine stabilization candidates, as detailed
> + in `Stabilization candidates`_.
> +
At most one ...
> - zero or more elements, possibly restricted
>to specific package versions (at most one for each version) whose presence
>indicates that the appropriate ebuilds are suitable for simultaneously
> @@ -199,6 +203,25 @@ The element can contain the following
> elements:
> - at most one element describing the role of subslots (all
>of them) as text.
>
> +Stabilization candidates
> +
> +Each element describes version
vs each (implies any number). I'd simply say, "If present, the `` +constraints used to determine package versions eligible
> +for stabilization. Should this element be missing, the tooling assumes
> +a default of any version with any keywords present (i.e. the equivalent
> +of ``>=0``).
> +
> +The element can contain the following
> +elements:
> +
> +- one or more elements, each containing a version
> + constraint in the format matching EAPI 0 dependency specification
> + with the package category and name parts omitted, e.g. ``<1.7``.
> + The tooling considers any ebuild version that satisfies the constraint
> + and has any keywords. If multiple constraints are provided, every one
> + of them is matched separately, and multiple stabilization candidates
> + can be reported.
I think it's clear from context that there should be one or more, but
the language ("can contain" in the leading paragraph) implies all sub
elements are optional. Perhaps:
The ... element:
- must contain one or more ...
Which also allows for future "may contain" sub elements.
Kind Regards,
Jaco
Re: [gentoo-dev] [PATCH] glep-0068: Add new element
On Wed, 2020-09-16 at 10:26 +0200, Ulrich Mueller wrote:
> > > > > > On Wed, 16 Sep 2020, Michał Górny wrote:
> > It has two advantages:
> > 1. It reduces the risk of accidentally leaving it in the stable ebuild.
>
> Huh, you mean you would remove the PROPERTIES token again, after the
> version has been stabilised? Why?
No, I mean removing it when bumping from version unsuitable to
be a stable candidate to one that is suitable. What's really
problematic is that this mistake will be easy to miss, especially if
someone relies on pkgcheck entirely to determine when to stabilize
stuff.
>
> Ebuilds could do conditionals like this (again, an example that would
> work for app-editors/emacs):
>
> [[ ${PV//[0-9]} == "." ]] && PROPERTIES+="stablecandidate"
Yes, provided that developers will actually do that.
> > 2. It handles specifying multiple stabilization candidates on different
> > branches. I don't see how ebuilds would do that.
>
> I don't understand. Why couldn't PROPERTIES be specified in different
> slots?
>
How would you distinguish the ebuild group that represent the same
upstream branch (i.e. expecting only one report from the group) from
other upstream branches?
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] glep-0068: Add new element
> On Wed, 16 Sep 2020, Michał Górny wrote:
> It has two advantages:
> 1. It reduces the risk of accidentally leaving it in the stable ebuild.
Huh, you mean you would remove the PROPERTIES token again, after the
version has been stabilised? Why?
Ebuilds could do conditionals like this (again, an example that would
work for app-editors/emacs):
[[ ${PV//[0-9]} == "." ]] && PROPERTIES+="stablecandidate"
> 2. It handles specifying multiple stabilization candidates on different
> branches. I don't see how ebuilds would do that.
I don't understand. Why couldn't PROPERTIES be specified in different
slots?
Ulrich
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] glep-0068: Add new element
On Wed, 2020-09-16 at 08:18 +0200, Ulrich Mueller wrote: > > > > > > On Wed, 16 Sep 2020, Michał Górny wrote: > > > +- one or more elements, each containing a version > > + constraint in the format matching EAPI 0 dependency specification > > + with the package category and name parts omitted, e.g. ``<1.7``. > > That's not a very powerful syntax, so unless I miss something, > metadata.xml would have to be updated for almost every stable candidate. > > To give an example, released versions of app-editors/emacs have exactly > two numerical components, while prereleases and release candidates have > three components or are marked _rc. Both would be impossible to match > with the proposed syntax. It's not 'one size fits all'. It will work for a number of packages, e.g. XFCE without too frequent updates. In the end, it's primarily designed around 'silencing' StableRequest results once they are reported, i.e. for packages that have long-ish RC periods. > So IMHO this has no advantage over keeping the information in the ebuild > (e.g. as a PROPERTIES token). > It has two advantages: 1. It reduces the risk of accidentally leaving it in the stable ebuild. 2. It handles specifying multiple stabilization candidates on different branches. I don't see how ebuilds would do that. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] glep-0068: Add new element
> On Wed, 16 Sep 2020, Michał Górny wrote: > +- one or more elements, each containing a version > + constraint in the format matching EAPI 0 dependency specification > + with the package category and name parts omitted, e.g. ``<1.7``. That's not a very powerful syntax, so unless I miss something, metadata.xml would have to be updated for almost every stable candidate. To give an example, released versions of app-editors/emacs have exactly two numerical components, while prereleases and release candidates have three components or are marked _rc. Both would be impossible to match with the proposed syntax. So IMHO this has no advantage over keeping the information in the ebuild (e.g. as a PROPERTIES token). Ulrich signature.asc Description: PGP signature
[gentoo-dev] [PATCH] glep-0068: Add new element
Signed-off-by: Michał Górny --- glep-0068.rst | 62 --- 1 file changed, 59 insertions(+), 3 deletions(-) diff --git a/glep-0068.rst b/glep-0068.rst index d8fc379..5b7e2b9 100644 --- a/glep-0068.rst +++ b/glep-0068.rst @@ -4,10 +4,10 @@ Title: Package and category metadata Author: Michał Górny Type: Standards Track Status: Final -Version: 1.1 +Version: 1.2 Created: 2016-03-14 -Last-Modified: 2020-05-06 -Post-History: 2016-03-16, 2018-02-20 +Last-Modified: 2020-09-16 +Post-History: 2016-03-16, 2018-02-20, 2020-09-16 Content-Type: text/x-rst Requires: 67 Replaces: 34, 46, 56 @@ -149,6 +149,10 @@ element can contain, in any order: languages (at most one for each language), as detailed in `Slot descriptions`_. +- at most one element containing version + constraints used to determine stabilization candidates, as detailed + in `Stabilization candidates`_. + - zero or more elements, possibly restricted to specific package versions (at most one for each version) whose presence indicates that the appropriate ebuilds are suitable for simultaneously @@ -199,6 +203,25 @@ The element can contain the following elements: - at most one element describing the role of subslots (all of them) as text. +Stabilization candidates + +Each element describes version +constraints used to determine package versions eligible +for stabilization. Should this element be missing, the tooling assumes +a default of any version with any keywords present (i.e. the equivalent +of ``>=0``). + +The element can contain the following +elements: + +- one or more elements, each containing a version + constraint in the format matching EAPI 0 dependency specification + with the package category and name parts omitted, e.g. ``<1.7``. + The tooling considers any ebuild version that satisfies the constraint + and has any keywords. If multiple constraints are provided, every one + of them is matched separately, and multiple stabilization candidates + can be reported. + USE flag descriptions ~ Each element describes USE flags of a package (in specific @@ -378,6 +401,39 @@ package version restrictions and maintainer descriptions were also implicitly allowed on them. Since neither of the two was allowed by GLEP 46, this specification disallows them. +Stabilization candidates + +Version 1.2 of the specification adds stabilization candidate versions. +The primary goal of this is to provide a more fine-grained control +of tooling reporting stabilization candidates. Previously, pkgcheck +reported only the newest keyworded version that was eligible for +stabilization according to the 30-day testing period. This had two +limitations. + +Firstly, it did not account for development branches properly +and reported them as stabilization candidates. While we could +technically blacklist ``_alpha``, ``_beta``, ``_rc`` versions, +this would not work for all packages. Some GNOME and XFCE packages use +odd numbers in minor version to indicate development branch. +On the other hand, there are stagnant packages that stay in pre-release +state for months, and stabilizing these versions also makes sense. + +Secondly, it did not account for software maintaining multiple parallel +stable branches. As soon as the newer version became eligible +for stabilization, new releases of the older branches were not reported. +In some cases, users are bound to old versions because of dependencies +(e.g. on Python 2.7). + +The proposed ‘whitelist-override’ syntax aims to help with both cases. +The default preserves current behavior. A single override such +as ``<1.7`` can be used to explicitly ignore development branch, +and request stabilization candidates from earlier versions. Multiple +version constraints (say, ``<5.9`` and ``<5.5``) can be used to request +monitoring multiple upstream branches. + +This information can also be consumed by users to opt-out of development +versions and keep their systems running potential stable candidates. + Backwards Compatibility === -- 2.28.0
