Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

["Michał Górny" <mgorny@gentoo.org>]

W dniu czw, 28.09.2017 o godzinie 11∶06 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 09/27/2017 09:24 PM, Michał Górny wrote:
> > W dniu wto, 26.09.2017 o godzinie 20∶58 +0200, użytkownik Michał Górny
> > napisał:
> > > W dniu pon, 25.09.2017 o godzinie 17∶08 +0200, użytkownik Andreas K.
> > > Huettel napisał:
> > > > Dear all, 
> > > > 
> > > > the next council meeting will be 8/October/2017 18:00 UTC in the
> > > > #gentoo-council channel on freenode.
> > > > 
> > > > Please reply to this message with any items you would like us to discuss
> > > > or vote on.
> > > > 
> > > > The agenda will be sent out in a week.
> > > > 
> > > 
> > > So, in order:
> > > 
> > 
> > [...]
> > 
> > 3. Also, if time permits we may take a look at the git pre-GLEP [3].
> 
> We can always look at it, but I don't necessarily believe it is ready
> for a vote at this point, I seem to recall the last email discussion on
> it ending without conclusion, so I'd suggest picking up on an email
> thread discussing it and trying to separate out a few explicit
> discussion points to have a better thread model.

If having a conclusion would be a requirement for doing anything, we'd
never have moved off EAPI 0.

> Some questions that immediately springs to mind re-reading this is
> (1) Is this an authoritative standard or a suggestion? if it is only a
> suggestion does it belong in devmanual or git workflow on wiki rather
> than in a GLEP to begin with? if it is authoritative, is it properly
> well defined?

Given the behavior of Gentoo developers, I think we have no other option
except making it authoritative standard. Otherwise, people will continue
using their own personal style even if it they knew it breaks our
tooling (compare: stable bot).

> (2)(a) Should Bug be a generic indicator for bug information, including
> upstream bugs, or; (b) do we want to separate upstream / other
> information in e.g a References: field that can be used for other bugs
> and descriptions (including security advisories etc).

As far as I'm concerned, one indicator for all bugs is enough,
especially that in some cases projects have Gentoo upstream which blur
the line between upstream and downstream bugs.

As for CVEs and other uncommon stuff, I don't have a strong opinion. If
you expect some specific machine action for them, it'd be better to have
a unique tag though.

>  If so (c) is there
> a benefit in using a full URI for Bug; or should this be reduced to only
> the number,

Only full URIs are acceptable. Numbers are ambiguous. The repository
and commits within it are mirrored to various sources, can be included
in external repositories and so on. We don't want to start closing
accidental bugs all over the place just because someone cherry-picked
a commit without escaping all references Gentoo developers left.

>  (d) How should multiple bugs be added, is this a comma or
> space separated list, or multiple Bug listings with single bug number?
> (I, personally, prefer the latter as it removes parsing semantics
> regarding potential linebreaks and max widths, so multiple Bug is likely
> needed anyways, so simplifying it to only one number seems like a good
> thing)

The spec already answers that. One URL per tag.

> For the other tags it seems like it is starting to start to be
> consistent now, in particular with regards to earlier overloading of
> same names for multiple purposes (e.g fixes), so thanks for that.
> 
> I'll have to review it more carefully when having some Gentoo time at home.

-- 
Best regards,
Michał Górny