1 |
On Wed, 2020-09-16 at 10:26 +0200, Ulrich Mueller wrote: |
2 |
> > > > > > On Wed, 16 Sep 2020, Michał Górny wrote: |
3 |
> > It has two advantages: |
4 |
> > 1. It reduces the risk of accidentally leaving it in the stable ebuild. |
5 |
> |
6 |
> Huh, you mean you would remove the PROPERTIES token again, after the |
7 |
> version has been stabilised? Why? |
8 |
|
9 |
No, I mean removing it when bumping from version unsuitable to |
10 |
be a stable candidate to one that is suitable. What's really |
11 |
problematic is that this mistake will be easy to miss, especially if |
12 |
someone relies on pkgcheck entirely to determine when to stabilize |
13 |
stuff. |
14 |
|
15 |
> |
16 |
> Ebuilds could do conditionals like this (again, an example that would |
17 |
> work for app-editors/emacs): |
18 |
> |
19 |
> [[ ${PV//[0-9]} == "." ]] && PROPERTIES+="stablecandidate" |
20 |
|
21 |
Yes, provided that developers will actually do that. |
22 |
|
23 |
> > 2. It handles specifying multiple stabilization candidates on different |
24 |
> > branches. I don't see how ebuilds would do that. |
25 |
> |
26 |
> I don't understand. Why couldn't PROPERTIES be specified in different |
27 |
> slots? |
28 |
> |
29 |
|
30 |
How would you distinguish the ebuild group that represent the same |
31 |
upstream branch (i.e. expecting only one report from the group) from |
32 |
other upstream branches? |
33 |
|
34 |
-- |
35 |
Best regards, |
36 |
Michał Górny |