On Sun, 2008-07-27 at 01:48 +0200, Frédéric Moulins wrote: > It is not the case, but Trac remains a good system for tracking issues > (categories, search), visualizing (diff, browse), and linking things > together.
Then Trac is not a good system. I'm certainly no bugzilla fanboy but given your observations about Trac I can say that bugzilla does all of this. At my workplace we use Bugzilla exactly for this purpose. Customers file bugs, developers create patches as bugzilla attachments. Other engineers comment on such patches in the same bug. Patches come to resolution and then they land on branches. The bug even tracks which branches they land on. > Contributors should be advised to first submit patches in the issue > tracker. > > Then, > * if they have questions They being the patch submitters or the reviewers? > while submitting their patches, they should > be told to send patches to the mailing list by following the > established conventions (To and CC, formatting, Signed-off-by,...) *and* > with questions in order to get a review, nack, ack or "can't look at it > for the moment...". No. I disagree. Requiring contributors to post patches to more than one place is burdensome on the community you are trying to attract and confusing for new members. Choose one: a good tracking system or e-mail. Not both. > * if someone asks for it (by commenting the issue), they should know > they may have to re-submit the patch to the mailing list. Maybe in my case it's no great loss (but maybe for other contributors the loss would be greater and measurable) I would simply refuse to contribute patches if I knew the process were going to be so cumbersome. Your goal here is to keep the barrier low and encourage contribution, not to make it a PITA to contribute. > I think it could work this way because patches needing a review - > therefore a discussion, so emails - are either patch series or patches > from people not experts on what they are modifying (first time, > hack, not so much documentation...). In both case, patches are > accompagnied by questions (either call for review, or expression > of doubt) - therefore discussion... *But*, not so many submissions are > patch series or complex hacks that could'nt be commented in Trac : > think package updates, one liners. And people do not ask much questions > because they tend to think if it works it is ok (at least, I do, most > of the time). All of this tracking and questions and commenting, etc. can be carried out in a better tracker (on the assumption that your position that Trac doesn't do it well) and not have to be a bastardized process mishmash of half-Trac and half e-mail. Seriously, if a screwdriver isn't the right tool, adding a hammer to it doesn't make it right tool. > Is it possible to let the submitter modify ticket properties after > submission ? (like "component": quite frustrating when ticket created > with package instead of base system or else). It could help > classification to be done by more people. Like bugzilla lets one do? Seriously, again I'm no bugzilla fanboy, but it's a mature product that has been doing what it does for many many years -- enough to at least get the workflow aspects right. b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
