On Sun, 2008-07-27 at 11:10 +0200, Frédéric Moulins wrote: > On Sat, 26 Jul 2008 22:51:33 -0400 > "Brian J. Murrell" <[EMAIL PROTECTED]> wrote: > > > > 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
Don't tell me, tell the OP. I was just saying "that if what he is
saying is true, then trac is not good enough". I have not really used
Trac for full bug solution workflow so I don't know.
> 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).
Again, that is completely wrong. If the patch needs discussion it
should happen all in one place. Otherwise you lose the context of the
evolution of a patch. If I post a patch and then a revision and another
revision, etc., people that come along after me might want to see why
the patch evolved as it does. They should not have to try to go find
that in the mailing list.
> 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
^^^
You. That means if the person posting the patch doesn't feel like it's
actually a complete work, he can get help on the list before posting
what should be a complete work to a tracking system. I agree with that.
But once the patch owner thinks it's complete, (if a tracking system is
desired -- and I'm not necessarily advocating that, just specifying the
reasonable boundaries to the OP's ideas about using both tracking system
and e-mail) and posts a patch to a tracking system, any peer review and
followup should be done in the tracking system. This is all about
workflow.
Trust me. Take it from somebody who has been working full-time for
years on an 10 year old open source project (so the processes are
mature). Workflow in a tracking system can work, but you have to commit
to it. No half-way efforts. (For patch review and tracking) Either use
e-mail 100% of the time or tracking 100% of the time. Not both.
> 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.
> "
> *And* to give devs/maintainers an easy way to keep track and review
> patches.
Of course. I would suggest having them have to use a tracking system
*and* e-mail for this process is overly cumbersome too. Rather than
simply starting to make comments on a patch posted, now they have to go
back to the patch owner and say "ok, now I need you to post that same
patch to the ML so that I can open it back up, try to remember what I
wanted to critique and start writing my response".
> That's why I insist on the mailing-list part but without
> making it a requirement, only an eventuality.
IMHO, it's all wrong. Choose one and commit to it.
Seriously, as a patch reviewer, if I had to stop my review and ask the
patch owner to post it again to the ML so that I can start my review all
over again, I simply wouldn't. I want less work, not more.
> I don't know any tracking system (except review-board) offering what the
> devs want: inline review of patches.
Bugzilla does it just fine. Patch owner attaches a patch to a ticket,
then the reviewer then "opens the attachment in a comment" (that's a
bugzilla feature) and goes about commenting, inline, on what he likes or
doesn't like, the result being a new comment in the bug.
> So there is no right tool to
> satisfy them.
I disagree.
> (And I repeat, IMO, the only reason for the SubmittingPatches-byEmail
> guideline is inline review of patches)
As I've said, BZ does inline review just fine.
> This is a matter of configuration.
Perhaps. I know BZ lets you do it. I don't know about Trac. But it
seems that Trac already fails the "review inline" requirement anyway, so
why bothering arguing about what else it doesn't do.
> I don't think it's worth the migration and configuration cost.
To get inline review, where the only alternative is this mish-mash of a
tracking system and e-mail that means more work for both posters and
reviewers? I guess that's a call for the owners of the project.
Whether they feel the migration effort is worth attracting and keeping
contributors or not. Certainly not my call.
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
