Gentoo Archives: gentoo-dev

From: Jaco Kroon <jaco@××××××.za>
To: gentoo-dev@l.g.o, "Michał Górny" <mgorny@g.o>
Subject: Re: [gentoo-dev] [PATCH] glep-0068: Add new <stabilization-candidates/> element
Date: Wed, 16 Sep 2020 09:13:23
Message-Id: 6d6e9b13-74d3-599e-6c46-6bf98d80a054@uls.co.za
In Reply to: [gentoo-dev] [PATCH] glep-0068: Add new element by "Michał Górny"
1 Hi Michał,
2
3 Thanks for your efforts.  This looks interesting at the very least, and
4 whilst in many cases on posts on this ML I'm on the "don't care" stance,
5 this one looks like it could solve some problems for me. 
6 net-misc/asterisk + friends will definitely make use of this.
7
8 Two nitpicks below that doesn't really carry significant meaning.
9
10 On 2020/09/16 07:48, Michał Górny wrote:
11
12 > Signed-off-by: Michał Górny <mgorny@g.o>
13 > ---
14 > glep-0068.rst | 62 ++++++++++++++++++++++++++++++++++++++++++++++++---
15 > 1 file changed, 59 insertions(+), 3 deletions(-)
16 >
17 > diff --git a/glep-0068.rst b/glep-0068.rst
18 > index d8fc379..5b7e2b9 100644
19 > --- a/glep-0068.rst
20 > +++ b/glep-0068.rst
21 > @@ -4,10 +4,10 @@ Title: Package and category metadata
22 > Author: Michał Górny <mgorny@g.o>
23 > Type: Standards Track
24 > Status: Final
25 > -Version: 1.1
26 > +Version: 1.2
27 > Created: 2016-03-14
28 > -Last-Modified: 2020-05-06
29 > -Post-History: 2016-03-16, 2018-02-20
30 > +Last-Modified: 2020-09-16
31 > +Post-History: 2016-03-16, 2018-02-20, 2020-09-16
32 > Content-Type: text/x-rst
33 > Requires: 67
34 > Replaces: 34, 46, 56
35 > @@ -149,6 +149,10 @@ element can contain, in any order:
36 > languages (at most one for each language), as detailed
37 > in `Slot descriptions`_.
38 >
39 > +- at most one ``<stabilization-candidates/>`` element containing version
40 > + constraints used to determine stabilization candidates, as detailed
41 > + in `Stabilization candidates`_.
42 > +
43 At most one ...
44 > - zero or more ``<stabilize-allarches/>`` elements, possibly restricted
45 > to specific package versions (at most one for each version) whose presence
46 > indicates that the appropriate ebuilds are suitable for simultaneously
47 > @@ -199,6 +203,25 @@ The ``<slots/>`` element can contain the following elements:
48 > - at most one ``<subslots/>`` element describing the role of subslots (all
49 > of them) as text.
50 >
51 > +Stabilization candidates
52 > +~~~~~~~~~~~~~~~~~~~~~~~~
53 > +Each ``<stabilization-candidates/>`` element describes version
54
55 vs each (implies any number).  I'd simply say, "If present, the ``<stab..."
56
57 > +constraints used to determine package versions eligible
58 > +for stabilization. Should this element be missing, the tooling assumes
59 > +a default of any version with any keywords present (i.e. the equivalent
60 > +of ``>=0``).
61 > +
62 > +The ``<stabilization-candidates/>`` element can contain the following
63 > +elements:
64 > +
65 > +- one or more ``<version/>`` elements, each containing a version
66 > + constraint in the format matching EAPI 0 dependency specification
67 > + with the package category and name parts omitted, e.g. ``<1.7``.
68 > + The tooling considers any ebuild version that satisfies the constraint
69 > + and has any keywords. If multiple constraints are provided, every one
70 > + of them is matched separately, and multiple stabilization candidates
71 > + can be reported.
72
73 I think it's clear from context that there should be one or more, but
74 the language ("can contain" in the leading paragraph) implies all sub
75 elements are optional.  Perhaps:
76
77 The ... element:
78
79 - must contain one or more ...
80
81 Which also allows for future "may contain" sub elements.
82
83 Kind Regards,
84 Jaco

Replies