| 1 |
On Wed, Aug 7, 2013 at 8:07 AM, Alexis Ballier <aballier@g.o> wrote: |
| 2 |
> On Wed, 7 Aug 2013 11:04:28 +0200 |
| 3 |
> "Andreas K. Huettel" <dilfridge@g.o> wrote: |
| 4 |
>> That's fine, bug wranglers are doing a great job there. |
| 5 |
>> |
| 6 |
>> However, I'm also sick of getting bugmail because $RANDOM_DEV thinks |
| 7 |
>> * TRACKER is better than Tracker, |
| 8 |
>> * every atom needs a "=" in front, and |
| 9 |
> |
| 10 |
> This is wrong btw. Some people already closed some bugs like 'rekeyword |
| 11 |
> =cat/pkg-version' because said version was not in tree anymore. Heck, |
| 12 |
> this was months later and there was a newer version. Now I just fill |
| 13 |
> 'rekeyword latest cat/pkg' and expect people not to mess with summary. |
| 14 |
|
| 15 |
I think the proper workflow in a situation like this is: |
| 16 |
|
| 17 |
1. (Optional) Random interested party sends bug to maintainer asking |
| 18 |
for keywording. That one is not tagged with a version for the reasons |
| 19 |
you state. |
| 20 |
|
| 21 |
2. Maintainer agrees and picks a stable candidate, and modifies the |
| 22 |
subject to include a specific version. At the appropriate time archs |
| 23 |
are CC'ed. |
| 24 |
|
| 25 |
If you want to STABLEREQ a package you can't just target the "latest |
| 26 |
version" - maintainers should be picking stable targets and many |
| 27 |
maintainers bump packages weekly and drop the old version so that none |
| 28 |
of them hit the 30-day threshold. Maintainers should be cooperative |
| 29 |
in getting packages stabilized as long as it makes sense (some |
| 30 |
packages are inherently incompatible with the stable concept, such as |
| 31 |
ones dependent on some cloud API that changes without warning). |
| 32 |
|
| 33 |
Rich |
Archives