<<< Date Index >>>     <<< Thread Index >>>

BTS policy



[=- Alain Bench wrote on Wed 31.Aug'05 at 21:26:55 +0200 -=]

> >> I like more your crossref #nnn in keywords way.
> > I use(d) that for reports which were related, not identical.
> 
> Well, the Debbugs merge could cover both identical and related
> cases. Hum... At least I used merging like that.

In old interactions I noticed your lists of bts directives, I
guess they were automatically processed "sanely". Is there such a
"mass instructions" interface to gnats, too?

I'm sorry if I acted before acknowledging some bts policy or other
(more suitable) means of bts control, since I had no hint about it
when I was given access.
 I went straight for the web-interface and acted by what felt
fitting among the given alternatives.

> Hum... What about:
> 
> Keep all open, mark duplicate all but first, add crossrefs, and
> cross notifieds.
> 
> Well, a little bit overcomplicated, and we have much too many
> open bugs already. Let's do it with your closing method. At
> least until the bug list is more reasonable.

My thoughts about the need to cleanup.
Either way, I prefer to have a common (best) practice to work
with bts so that we all know how to do it "right" and don't waste
time with correcting each other's "mistakes" (or lose something).

Once we agree on it, we should have some link on the bts to it so
new people can find it easily.

For the record, my modus operandi so far:
- mistaken, fixed, no details given + no feedback possible => close
- duplicate => cross-ref, cross-notify, close
- feedback request unanswered for ~2 months => close.
        (can be re-opened if feedback later)

- a solution found/ given => analyzed, possibly tag "patch".

- related but not duplicate => cross-ref

- outdated (1y+) => feedback request with new version

- not reproducible + untouched => request for example
        msg (folder) to reproduce or other tests (other system) as
        appropriate for the reported problem.

Objections?
Once we frontsoldiers filter out the simple cases, some pro code
experts can take care of the hard cases left over.


[=- Alain Bench wrote on Thu  1.Sep'05 at  9:28:39 +0200 -=]

> > Let's cleanup (old) stuff a little to allow focussing on the
> > real stuff.
> 
> Age and closability of a report are not related, are they?

Not directly, but indirectly, since often old reports won't
provide new required feedback (eMail-addr not valid anymore,
reporter doesn't care, case fixed by new version). And "cleanup"
doesn't mean only "directly close", but also "get it moving" not
to keep zombies standing in the line of sight forever.
 We'll see by end of Sept. how many of my feedback requests will
be answered (or not and therefore be closed, ready to be re-
reported by more feedback- giving reporters :).

> Let's do at best with each report, one by one. And much thanks
> for your help, Rado!

Thank you likewise. :)
We must get rid of the backlog somehow to be free for new stuff.
More help welcome.
Maybe once we'll then be able to consider some wishes to make
people happy and have mutt suck even less. ;)

-- 
© Rado S. -- So much to do, but too little time to take care of it all.