[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Process is no substitute for understanding



Some thoughts.

Maybe some of the problem is in how we use the BTS to manage proposals. It's
far from optimal.

For example, to see what the current problems with a proposal are,
and why it's being stalled, you more or less have to read the bug logs
in their entirety to work out the thread (and bug logs can't even be
displayed in threaded order).

Instead, it might be nice to be able to file bug reports against bugs
themselves. Something like:

	debian-policy
		[AMMENDMENT] Allow README.Debian.gz
			Bug: Instructions on building currently in copyright
			Bug: Don't need all build instructions just changed ones
			Resolved: Isn't README.gz already mentioned?

This sort of break up would allow you to track the open issues against
an ammendment really easily, which is definitely something lacking in
the current system. On the downside, making an extra bug report for each
flaw is likely to be painful and awkward. Possibly having some tags like:

	<bug title="Don't need all build instructions just changed ones">
	Another problem would be that...
	</bug>

..and a submit-partial@foo address that'll interpret them would make this
workable. Possibly, rather than just cc'ing bugs, using tags so your mail
looks like:

	<bug num=12345>
	> Another problem would be that...
	You're right, this is a problem. I'll ammend the proposal like so:
	--- blah.old
	+++ blah.new
	....
	Happy?
	<close>
	</bug>

or something?

Other problems are automation ones: seconds aren't easily findable, bugs
and ammendments and whatever aren't easily distinguishable. Ammendments
don't automatically expire when they get to old, they don't get
automatically retitled, and far more stuff is manual than seems really
necessary.

Then `consensus' would basically be having a few people who'll second it
(ie, have read it, are reasonably intelligent, see a point, and can't
see any problems), and having no open bugs after a period of discussion.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.

 ``The thing is: trying to be too generic is EVIL. It's stupid, it 
        results in slower code, and it results in more bugs.''
                                        -- Linus Torvalds

Attachment: pgpYffqQDmGou.pgp
Description: PGP signature


Reply to: