On Mon, Feb 26, 2007 at 01:51:25PM +0100, Loïc Minier wrote: > On Mon, Feb 26, 2007, cobaco (aka Bart Cornelis) wrote: > > 1) you don't want to leave people hanging (as an exercise in understanding > > the users point of view pretend it's an ftpmaster or other central > > project function that isn't showing any visible reaction to whatever > > information/action request you send) > > So, about this problem, most other bug trackers have a workflow with > bug /states/, for example: unconfirmed => new => fixed => confirmed > > We do have some support of the "confirmed to exist" concept with the > "confirmed" tag; I suppose the confirmed tag would be enough to encode > the fact that the bug has been seen and is confirmed to be a real bug, > but it might be more useful (as above) if changes of the confirmed tag > would trigger an email to the submitter.
This is indeed what I do. Instead of forging crappy excuses to say
every time I lack time to do this or that, which is with time,
frustrating and demotivating enough.
SO rather than sending excuses-templates, when I've had time to check
the bug is actually there, I do use the confirmed tag to:
* ack this is an actual bug ;
* ack that I've been able to reproduce it (hence implying that I've
read the report) ;
* remember that I already read that report.
And hell no I won't send "standard" mails to submitters, I hate to
receive such mails, I won't send such. I like to receive mail when there
is useful information. When I submit a bug, I know there is one, so the
"ack there is a bug" mail is somehow ... polluting my mailbox.
Though there is a lot of bugs that I do try to answer to, that is the
bugs with patches, as usually the submitter is able to share some work
on that bug, and that's efficient working on those (meaning that it
often needs really tiny time blocks to solve them, and that I can do
that during my paid work lunch pause.
Though, in this discussion we're talking a lot about the past. For
KDE, we (I say we as a habit, but I'm not really in the team anymore...)
struggle with the old antiquated bugs a lot, but I think we're able to
keep up with new bugs since bts-link exists.
bts-link improved our workflow a lot, because now, when a new bug
arrives, then you need to check its validity, and if it's verry annoying
or not. If it's not a major blocker, then you forward it upstream, and
mark the bug as forwarded. The improvement, is that thanks to bts-link,
we then can forget about that bug completely, as we will be notified
when upstreams made progress on this.
Obviously, for many reasons, the submitter is not really notified
about what is going on, but:
* looking at the BTS he can in one click read the upstream bug log,
and follow-up there if neede ;
* we never have bugs on the lose anymore, that we begun to deal with,
then forgot about because it wasn't solved before it was wiped out
from our deficient human memories.
It's really less frustrating for the maintainer as it's almost a
once-for-all effort, and I can say for sure it's really more enjoyable
to package huge things when you know that you can concentrate only of
the nastiest things, or the thing you care about for whichever reason,
without neglecting the other aspects/bugs/...
So please, when I read Bernhard saying that KDE or such packages
should not be in stable, I quite choke on his words, because I really
think KDE packaging workflow has never been better in the last 3 years.
It does not mean it can't be even better, but we're definitely working in
the good direction, and are not slugged either.
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpjT5adoGCyn.pgp
Description: PGP signature
