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

[Kristian Fiskerstrand <k_f@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2423 bytes --]

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.

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?

(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). If so (c) is there
a benefit in using a full URI for Bug; or should this be reduced to only
the number, (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)

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.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]