1 |
On Mon, Aug 15, 2016 at 3:55 AM, Brian Dolbec <dolsen@g.o> wrote: |
2 |
> |
3 |
> I have some trouble with not being able to close bugs as resolved when |
4 |
> the fixes have been released. But I do see that the majority of what is |
5 |
> being discussed relates to pkg ebuilds more than it does to coding |
6 |
> projects. In that sense it sounds reasonable. But for me, most of my |
7 |
> work is project coding, so it overlaps with making releases which |
8 |
> involves the ebuild. As a project coder, I want to be able to close a |
9 |
> bug when a release has been made that contains the fix. In some cases |
10 |
> that release might not get stabilized, but another one later does. |
11 |
> |
12 |
|
13 |
I'd suggest that we agree early-on that the scope of this is around |
14 |
ebuild work. Not "upstream" work where the upstream is Gentoo. |
15 |
|
16 |
Of course, there could be overlap. portage-1.23.ebuild might have a |
17 |
bug, and that gets fixed in the portage dev git, and later gets |
18 |
released to portage-1.24, and then ends up in stable sometime later. |
19 |
Those could be two separate bugs (the gentoo repo ebuild bug vs the |
20 |
portage "upstream" bug), but I'm not sure that makes life easier. If |
21 |
they were two separate bugs (as they would be if Gentoo weren't the |
22 |
upstream) then the scope of this effort is focused on the Gentoo |
23 |
ebuild repo bug. |
24 |
|
25 |
-- |
26 |
Rich |