>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Hi,
Man, talk about being talked down to.
Ian> DISPUTES BETWEEN DEVELOPERS
Ian> A *DRAFT* joint recommendation of the the Technical Committee, the
Ian> Project Leader and the Bug Tracking System Administrators.
Since this is not a technical issue, I do not think the
technical committee is the appropriate body to b doing this (though I
realize we can pontificate on anything we choose to.
Ian> If you really can't engage helpfully, for example because the other
Ian> Developer refuses constructive discussion, you can refer the question
Ian> to the Technical Committee (including, possibly, reassigning a bug
Ian> report to them) or the Project Leadership. If you do this, be
Ian> prepared to be told to go away and grow up !
If and only if the dispute is about technical issues. If it is
not, the technical committee has no jurisdiction.
Ian> If discussing the issue with all the relevant people hasn't produced a
Ian> conclusion and doesn't look like it will, the Technical Committee can
Ian> decide.
Can we, really?
Ian> 6. Bug report etiquette
Ian> Sometimes bugs are reported inappropriately; likewise, sometimes
Ian> maintainers close bug reports inappropriately. Bug reports are `todo
Ian> list' items for the whole Project; they should be closed when there is
Ian> rough consensus that the whole system is working as well as it could.
No. The BTS is a means of tracking problems with the package,
it is not a glorified PIM. There are better ways of keeping a TODO
list.
You are also discounting the fact that a package maintainer is
often the person closest to th software, next to th authors, and may
have a better idea about the real status of the problem report.
Having spurious and incorrect reports cluttering up the BTS
helps no on; and makes it harder for volunteers to target effort.
Ian> * The bug was reported; the maintainer felt immediately that it was a
Ian> spurious bug report of some kind, and closed it, but the submitter
Ian> disagrees with the explanation and has reopened the report for
Ian> discussion. The matter should be debated until both Developers are
Ian> happy.
Both developres? What if the reporter is not a developer? Is
it OK to close the bug then?
In any case, generalization like this are often unsuited to
specific cases; and the determination needs to b made on a case by
case basis if the maintainer is justified in managing the TODO list
for his package, neh?
Ian> While a situation is being discussed, any relevant bug report(s)
Ian> should remain open. If a package maintainer closes your bug report,
Ian> you may reopen it if you wish to continue the discussion.
Ropening spurious bug reports is unlikely to be helpful. The
maintainer often does know better; and it is suboptimal to ignore
that fact.
Ian> Note that while the Technical Committee is also happy to help resolve
Ian> disputes over individual bug reports,
Really? I recall we punted on th last such dispute.
manoj
--
I've finally figured out why airports make you walk so far out to get
to your plane. It's their way of giving your luggage a head start.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
