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 08:34:43
Message-Id: d9f03ca50a699071a59a713aec4dd951284030b7.camel@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH] glep-0068: Add new element by Ulrich Mueller
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

Attachments

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