| 1 |
Diego 'Flameeyes' Pettenò wrote: |
| 2 |
> In amaroK's case, anyway, there's no problem to know if it has relesed: |
| 3 |
> upstream releases always in time, providing packagers with candidates to |
| 4 |
> release, allowing to prepare stuff before actual release.. the release is |
| 5 |
> also broadcasted in their homepage, on #amarok@freenode, on KDE-Apps, on |
| 6 |
> kde-extra-gear mailing list, usually on Planet KDE, too.... |
| 7 |
> Really, I don't need bugs to remember me to bump it. |
| 8 |
> |
| 9 |
> Mostly the same for k3b.. it's released and then announced on kde-extra-gear, |
| 10 |
> KDE-Apps, SourceForge, .. |
| 11 |
> |
| 12 |
> I can be very thankful if someone would let me know when ALSA gets released as |
| 13 |
> the upstream send mail to -announce once in a blue moon instead.. |
| 14 |
|
| 15 |
After contributing to the suggestions on -core I forgot to explain |
| 16 |
myself very clearly on this point. |
| 17 |
|
| 18 |
I'm not suggesting a mechanism for handling or encouraging "0-day" bump |
| 19 |
requests - I'm giving a suggestion which I believe will help *reduce* |
| 20 |
those requests. |
| 21 |
|
| 22 |
By leaving a nice comment (asking that they give us a little more room |
| 23 |
to breathe in future) *and* crediting the user, maybe they will take |
| 24 |
your advice to heart. |
| 25 |
|
| 26 |
It's not up to the user to know how closely the maintainer tracks the |
| 27 |
upstream release (or even who the maintainer is in the first place), but |
| 28 |
in general we prefer to be left for a week or so before being notified |
| 29 |
via Gentoo bugzilla, right? |
| 30 |
|
| 31 |
> I try to explain why I did some changes before committing or why I didn't use |
| 32 |
> a given fix usually, I also try to provide documentation of what I do and why |
| 33 |
> I do it that way (see maintainers' guides, that nobody else seems to want). |
| 34 |
|
| 35 |
OK - thats a good compromise if you can't afford to spend the full |
| 36 |
amount of time guiding the user through it. I have never heard of your |
| 37 |
maintainer guides before but will check them out now. |
| 38 |
|
| 39 |
> If I start thinking "this bug I'll fix later and provide just pointers to |
| 40 |
> users, I'm sure I'm going to forget about it. I actually did that already :) |
| 41 |
|
| 42 |
Fair enough - I guess it depends on your workflow. Perhaps you could |
| 43 |
just try this for a couple of bugs: reassign them to yourself and leave |
| 44 |
the appropriate comments,then observing the users reaction. That way the |
| 45 |
bug is hard to lose since it is on your "My Bugs" list. |
| 46 |
|
| 47 |
Daniel |
| 48 |
-- |
| 49 |
gentoo-dev@g.o mailing list |
Archives