Gentoo Archives: gentoo-project

From: Kristian Fiskerstrand <k_f@g.o>
To: gentoo-project@l.g.o, "Michał Górny" <mgorny@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: Fri, 29 Sep 2017 13:11:10
In Reply to: Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC) by "Michał Górny"
1 On 09/28/2017 09:46 PM, Michał Górny wrote:
2 > As far as I'm concerned, one indicator for all bugs is enough,
3 > especially that in some cases projects have Gentoo upstream which blur
4 > the line between upstream and downstream bugs.
6 I don't buy this argument. The Gentoo Package repository is different
7 from the upstream software repository, so there needs to be a separation
8 between how to manage these situations. The guidelines (or requirements,
9 depending on how we decide on things) in this case only has the package
10 repository in scope and we shouldn't differentiate between gentoo as
11 upstream and external upstreams for the purpose of the package repository.
13 For this to be an issue would be a new patch release / revbump that only
14 happens in the Gentoo Package Repository but is not part of upstream,
15 which would be odd, in particular given we have a specific section in
16 the Gentoo social contract on:
17 ###
18 We will give back to the free software community
20 We will establish relationships with Free Software authors and
21 collaborate with them when possible. We will submit bug-fixes,
22 improvements, user requests, etc. to the “upstream” authors of software
23 included in our system. We will also clearly document our contributions
24 to Gentoo as well as any improvements or changes we make to external
25 sources used by Gentoo (whether in the form of patches, “sed tweaks” or
26 some other form). We acknowledge that our improvements and changes are
27 much more meaningful to the larger Free Software community if they are
28 clearly documented and explained, since not everyone has the time or
29 ability to understand the literal changes contained in the patches or
30 tweaks themselves.
31 ###
33 Further, for things to be an issue it would requires that automatic
34 tools touches bugs based on data. I can see that for Closes, which is an
35 explicit action, but not really for Gentoo-Bug, as a commit could be a
36 partial solution referencing it, e.g a stabilization, so the most an
37 automated tool would do is likely post a comment that the bug was
38 referenced in commit XYZ.
40 For Closes it brings up the question on whether only a specific list of
41 categories should be considered for such automated tooling, e.g for
42 specification of to it will only
43 influence "Gentoo Linux" product and reject action from the Gentoo
44 Package Repository for the others, then the root cause of the upstream
45 issue is handled, as bugs for that is in Gentoo Hosted Projects.
47 --
48 Kristian Fiskerstrand
49 OpenPGP keyblock reachable at hkp://
50 fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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