| 1 |
On 06/17/2016 06:41 PM, Rich Freeman wrote: |
| 2 |
> On Fri, Jun 17, 2016 at 12:00 PM, Kristian Fiskerstrand <k_f@g.o> wrote: |
| 3 |
>> On 06/17/2016 03:58 PM, Rich Freeman wrote: |
| 4 |
>>> |
| 5 |
>>> That could actually be generalized. I could see many types of bugs |
| 6 |
>>> where the issue is with upstream, and we might want to track the |
| 7 |
>>> progress as upstream implements a fix, releases it, and then it is |
| 8 |
>>> stabilized on Gentoo. So, maybe we need another state to track in |
| 9 |
>>> upstream's VCS vs the Gentoo repo. |
| 10 |
>> |
| 11 |
>> For a great deal of this we have UPSTREAM keyword, and also combination |
| 12 |
>> with PATCH keyword if we've submitted an own patch. |
| 13 |
> |
| 14 |
> Usually we mean UPSTEAM to mean that the issue is an upstream issue, |
| 15 |
> and should be pursued there. Usually we don't use it to mean that the |
| 16 |
> issue IS resolved upstream but we're waiting for a release/etc. I'm |
| 17 |
|
| 18 |
Well, the issue is still upstream in that case, so I don't see that |
| 19 |
necessarily being different, we're still waiting for a release upstream |
| 20 |
to make a new downstream ebuild and stabilize it, so it fits with UPSTREAM |
| 21 |
|
| 22 |
> not sure how important the distinction is in practice. The portage |
| 23 |
> team could of course use it differently. |
| 24 |
|
| 25 |
Yeah, I'm talking ebuilds here, not portage and similar bugs, I think |
| 26 |
your point of having own keyword for portage and the likes makes sense |
| 27 |
to distinguish it. |
| 28 |
|
| 29 |
|
| 30 |
-- |
| 31 |
Kristian Fiskerstrand |
| 32 |
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net |
| 33 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives