1 |
On Wed, Apr 2, 2014 at 3:55 PM, Mike Gilbert <floppym@g.o> wrote: |
2 |
> On the packages I maintain, I tend to use the latest unstable version |
3 |
> of the software. Stabilizing them rarely crosses my mind. |
4 |
> |
5 |
> I rather like the semi-automated reminders. They come in handy for my |
6 |
> own packages, as well as the large, uncoordinated mess of libraries |
7 |
> that the python team is tasked with maintaining. |
8 |
> |
9 |
|
10 |
++ |
11 |
|
12 |
I see no harm in people filing STABLEREQs when software has been |
13 |
around for a while. If it is inappropriate to stabilize a package |
14 |
without further coordination, just close the bug INVALID or such with |
15 |
a brief explanation. If a non-dev contributor wants to do the |
16 |
necessary coordination to file a better bug more power to them, and if |
17 |
not it is up to the maintainer. |
18 |
|
19 |
The bugs should be going to the maintainer first, and they should be |
20 |
responding one way or another in any case. If Arch teams are getting |
21 |
bugged with invalid STABLEREQs I'd say the problem is that the package |
22 |
should be maintainer-wanted. |
23 |
|
24 |
Another option might be to have a tag in metadata.xml that flags |
25 |
packages as never-stable or indicating that stabilization requires |
26 |
coordination, which might help with triage or getting bug filters to |
27 |
check first. |
28 |
|
29 |
Rich |