| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
Hi, |
| 5 |
|
| 6 |
On 2020/09/16 11:39, Michał Górny wrote: |
| 7 |
|
| 8 |
> On Wed, 2020-09-16 at 11:13 +0200, Jaco Kroon wrote: |
| 9 |
>> |
| 10 |
>>> +- at most one ``<stabilization-candidates/>`` element containing |
| 11 |
version |
| 12 |
>>> + constraints used to determine stabilization candidates, as detailed |
| 13 |
>>> + in `Stabilization candidates`_. |
| 14 |
>>> + |
| 15 |
>> At most one ... |
| 16 |
> |
| 17 |
> Do you mean capatilization? It's following suit with other items here. |
| 18 |
Sorry, was unclear, this correlates with the second comment below. |
| 19 |
>>> - zero or more ``<stabilize-allarches/>`` elements, possibly restricted |
| 20 |
>>> to specific package versions (at most one for each version) whose |
| 21 |
presence |
| 22 |
>>> indicates that the appropriate ebuilds are suitable for |
| 23 |
simultaneously |
| 24 |
>>> @@ -199,6 +203,25 @@ The ``<slots/>`` element can contain the |
| 25 |
following elements: |
| 26 |
>>> - at most one ``<subslots/>`` element describing the role of |
| 27 |
subslots (all |
| 28 |
>>> of them) as text. |
| 29 |
>>> |
| 30 |
>>> +Stabilization candidates |
| 31 |
>>> +~~~~~~~~~~~~~~~~~~~~~~~~ |
| 32 |
>>> +Each ``<stabilization-candidates/>`` element describes version |
| 33 |
>> |
| 34 |
>> vs each (implies any number). I'd simply say, "If present, the |
| 35 |
``<stab..." |
| 36 |
> |
| 37 |
> Again, this follows suit with other descriptions. |
| 38 |
|
| 39 |
If this is the standard, this is the standard, was just trying to point |
| 40 |
out that this could be considered a conflict. |
| 41 |
|
| 42 |
>>> +constraints used to determine package versions eligible |
| 43 |
>>> +for stabilization. Should this element be missing, the tooling assumes |
| 44 |
>>> +a default of any version with any keywords present (i.e. the equivalent |
| 45 |
>>> +of ``>=0``). |
| 46 |
>>> + |
| 47 |
>>> +The ``<stabilization-candidates/>`` element can contain the following |
| 48 |
>>> +elements: |
| 49 |
>>> + |
| 50 |
>>> +- one or more ``<version/>`` elements, each containing a version |
| 51 |
>>> + constraint in the format matching EAPI 0 dependency specification |
| 52 |
>>> + with the package category and name parts omitted, e.g. ``<1.7``. |
| 53 |
>>> + The tooling considers any ebuild version that satisfies the |
| 54 |
constraint |
| 55 |
>>> + and has any keywords. If multiple constraints are provided, |
| 56 |
every one |
| 57 |
>>> + of them is matched separately, and multiple stabilization candidates |
| 58 |
>>> + can be reported. |
| 59 |
>> |
| 60 |
>> I think it's clear from context that there should be one or more, but |
| 61 |
>> the language ("can contain" in the leading paragraph) implies all sub |
| 62 |
>> elements are optional. Perhaps: |
| 63 |
>> |
| 64 |
>> The ... element: |
| 65 |
>> |
| 66 |
>> - must contain one or more ... |
| 67 |
>> |
| 68 |
>> Which also allows for future "may contain" sub elements. |
| 69 |
>> |
| 70 |
> |
| 71 |
> To be honest, I'm not sure if we should permit or prohibit empty element |
| 72 |
> in the spec. |
| 73 |
|
| 74 |
pick one. But I'd use the word may (clearly optional) or must (clearly |
| 75 |
compulsory) rather than can. |
| 76 |
|
| 77 |
Kind Regards, |
| 78 |
Jaco |
| 79 |
|
| 80 |
|
| 81 |
-----BEGIN PGP SIGNATURE----- |
| 82 |
|
| 83 |
iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl9h9YMACgkQCC3Esa/3 |
| 84 |
7p5XtQf9H6kcStCzBz75rOVhoswzhIafZWXJnurAYHvEvM3vrWrMzh46Bc3aZZLo |
| 85 |
fo2+lg7Z9lw0iBxJjub/nexBR9D8XwCa3aW/G75Hgd5XcC54LfKRFGqGKHS9Zu9z |
| 86 |
GT96Ijqo4aS2PlepD0Qk8jVTnngzB5opasH3nNgR2u6WSEQHtkCE8lg2A1Z0hr3i |
| 87 |
PmO/kzvHnZxsais9wp7kkZn+ftGbI1Wuq6Gus3Yy3qWp2k6KTwD49VdN3y7Skk3s |
| 88 |
T3ULl/+ui/FqwGGDjlQw0MW8o2mJ76VrQoMTiMG7IErFz9BzJ3djf/bgXg8YjHc5 |
| 89 |
kjo/h1tLcj7WvLphz9gdhGt4Sk85Sw== |
| 90 |
=WdPf |
| 91 |
-----END PGP SIGNATURE----- |
Archives