On Sat, 26 Jul 2008 22:51:33 -0400 "Brian J. Murrell" <[EMAIL PROTECTED]> wrote:
> 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. It is clearly possible with Trac and it happens, look at : https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/2788 https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3035 https://dev.openwrt.org/cgi-bin/trac.fcgi/ticket/3353 > The bug even tracks which branches they land on. Yes, Bugzilla is very capable. Custom fields are something missing (I think) in Trac for example. > > > 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? They being submitters. > > > 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. I didn't express myself well. The only _required_ way should be posting contributions in the issue tracking system. Then, if contributors feel the need of a discussion about a patch they could be _advised_ to post it on the mailing-list (following the formatting). I found exactly what I mean in the madwifi contribution guide : " Once your patch is ready for prime-time attach it to a ticket. These instructions(*) explain the details. In case you feel the need to discuss your patch, we suggest you start a new thread for that on the madwifi-devel mailing list and refer to the ticket that has the patch attached. Don't forget to explain what your patch is intended to do. " (*) "These instructions" linking to a page explaining where to click and what to fill in. http://madwifi.org/wiki/DevDocs/PreparePatches > > > * 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. I agree, even if personally, I don't care about posting twice. When I submit something, I really want it to be integrated or that someone tells me "no, that's stupid". > > Your goal here is to keep the barrier low and encourage contribution, > not to make it a PITA to contribute. *And* to give devs/maintainers an easy way to keep track and review patches. That's why I insist on the mailing-list part but without making it a requirement, only an eventuality. > > > 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. I don't know any tracking system (except review-board) offering what the devs want: inline review of patches. So there is no right tool to satisfy them. (And I repeat, IMO, the only reason for the SubmittingPatches-byEmail guideline is inline review of patches) I agree most of the patch submissions can be commented in an issue tracker whith patches attached. > > > 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? This is a matter of configuration. A choice have been made to not let people register to get some reporters rights. Maybe to avoid a maintainance overhead (Kaloz? devs?). > > 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. I don't think it's worth the migration and configuration cost. Regards, fred _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
