Gentoo Archives: gentoo-dev

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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies