Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: gentoo-project@l.g.o, gentoo dev announce <gentoo-dev-announce@l.g.o>
Cc: council@g.o
Subject: Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)
Date: Thu, 28 Sep 2017 19:46:43
Message-Id: 1506627995.15843.5.camel@gentoo.org
In Reply to: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC) by Kristian Fiskerstrand
1 W dniu czw, 28.09.2017 o godzinie 11∶06 +0200, użytkownik Kristian
2 Fiskerstrand napisał:
3 > On 09/27/2017 09:24 PM, Michał Górny wrote:
4 > > W dniu wto, 26.09.2017 o godzinie 20∶58 +0200, użytkownik Michał Górny
5 > > napisał:
6 > > > W dniu pon, 25.09.2017 o godzinie 17∶08 +0200, użytkownik Andreas K.
7 > > > Huettel napisał:
8 > > > > Dear all,
9 > > > >
10 > > > > the next council meeting will be 8/October/2017 18:00 UTC in the
11 > > > > #gentoo-council channel on freenode.
12 > > > >
13 > > > > Please reply to this message with any items you would like us to discuss
14 > > > > or vote on.
15 > > > >
16 > > > > The agenda will be sent out in a week.
17 > > > >
18 > > >
19 > > > So, in order:
20 > > >
21 > >
22 > > [...]
23 > >
24 > > 3. Also, if time permits we may take a look at the git pre-GLEP [3].
25 >
26 > We can always look at it, but I don't necessarily believe it is ready
27 > for a vote at this point, I seem to recall the last email discussion on
28 > it ending without conclusion, so I'd suggest picking up on an email
29 > thread discussing it and trying to separate out a few explicit
30 > discussion points to have a better thread model.
31
32 If having a conclusion would be a requirement for doing anything, we'd
33 never have moved off EAPI 0.
34
35 > Some questions that immediately springs to mind re-reading this is
36 > (1) Is this an authoritative standard or a suggestion? if it is only a
37 > suggestion does it belong in devmanual or git workflow on wiki rather
38 > than in a GLEP to begin with? if it is authoritative, is it properly
39 > well defined?
40
41 Given the behavior of Gentoo developers, I think we have no other option
42 except making it authoritative standard. Otherwise, people will continue
43 using their own personal style even if it they knew it breaks our
44 tooling (compare: stable bot).
45
46 > (2)(a) Should Bug be a generic indicator for bug information, including
47 > upstream bugs, or; (b) do we want to separate upstream / other
48 > information in e.g a References: field that can be used for other bugs
49 > and descriptions (including security advisories etc).
50
51 As far as I'm concerned, one indicator for all bugs is enough,
52 especially that in some cases projects have Gentoo upstream which blur
53 the line between upstream and downstream bugs.
54
55 As for CVEs and other uncommon stuff, I don't have a strong opinion. If
56 you expect some specific machine action for them, it'd be better to have
57 a unique tag though.
58
59 > If so (c) is there
60 > a benefit in using a full URI for Bug; or should this be reduced to only
61 > the number,
62
63 Only full URIs are acceptable. Numbers are ambiguous. The repository
64 and commits within it are mirrored to various sources, can be included
65 in external repositories and so on. We don't want to start closing
66 accidental bugs all over the place just because someone cherry-picked
67 a commit without escaping all references Gentoo developers left.
68
69 > (d) How should multiple bugs be added, is this a comma or
70 > space separated list, or multiple Bug listings with single bug number?
71 > (I, personally, prefer the latter as it removes parsing semantics
72 > regarding potential linebreaks and max widths, so multiple Bug is likely
73 > needed anyways, so simplifying it to only one number seems like a good
74 > thing)
75
76 The spec already answers that. One URL per tag.
77
78 > For the other tags it seems like it is starting to start to be
79 > consistent now, in particular with regards to earlier overloading of
80 > same names for multiple purposes (e.g fixes), so thanks for that.
81 >
82 > I'll have to review it more carefully when having some Gentoo time at home.
83
84 --
85 Best regards,
86 Michał Górny

Replies