| 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. |
| 5 |
|
| 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. |
| 12 |
|
| 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 |
| 19 |
|
| 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 |
### |
| 32 |
|
| 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. |
| 39 |
|
| 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 https://bugs.gentoo.org/NNNNNN 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. |
| 46 |
|
| 47 |
-- |
| 48 |
Kristian Fiskerstrand |
| 49 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
| 50 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives