Although it does keep things together its a much larger PITA to work with. And I find it cumbersome to find the stuff I'm looking for unless I just happen to remember the Trac ID#.
The search function is not worse than searching the mailing list..
Sure it is. I have my mail archive, nicely sorted and tagged, exactly as _I_ want it and I can easily drag out any mail I want. Having to use a separate application (and web-based too of all things) to access a fraction of the information universe I'm dealing with doesn't scale too well.
Finding/implementing some sort of trac<->mailing list gateway would be ideal.
Ok. So what should the gateway look like?
I am pretty unreligious about which system to use, but we should stay with what we decided to use at least until we find a better solution or we just fix the solution we have. But this is only possible if there's a common sense about the requirements.
Well here's some of my thoughts to kick this off then, please discuss:
1) All developers should be aware of all patches; they can just press delete if they don't like the subject ==> All patches should be sent to the mailing list.
2) It should be as easy as possible to discuss patches, in free form, mixing patch snippets with prose (and flames and general silliness). When a patch author thinks he's had enough comments, he sends a new patch with some fixes and/or changes and perhaps an Acked-by: line. ==> All patches should be discussed on the mailing list; patches should preferably be sent inline (or if you really can only send attachments without getting mangled or word-wrapped patches, at least make sure the attachments are type text/plain and hopefully not encoded with binhex or quoted-unreadable or whatever).
3) No patches should go into a SCM tree without agreement from the tree's maintainer. ==> When a maintainer thinks a patch is good enough (after waiting a bit for discussion, perhaps), he signs off on the patch and either commits it or tells the author it's okay to commit. People read the SCM reflector to know when things went in (there are smallish delays often), and also to see what patches went in that they themselves didn't read (or participate in) (all of) the discussion for, but might be interesting for them nevertheless ["reading the changelog"]; when people are caught checking in stuff unauthorised (and they _will_ be caught) we can scramble their ssh key or force them to work from dialup or whatnot.
3) There is no need to keep all proposed patches in a tracker of any kind: software archeologists can go dig in the mailing list archives; for everyone else, all that matters is _what did actually change_ in the master repository and _why_, and the actual patches and check-in comments in the SCM tell that story. For people with short-term memory loss, there is this wonderful invention called the "threading mailer". ==> A tracker is a very useful tool for combined SCM monitoring, problem report handling, keeping track of the road map, etc.; it is *not* a good tool to organise people's personal code development (I prefer git and quilt, thanks), and certainly not a good tool for cooperative development. We need to work _closer_ together, in a sometimes non-linear or slightly ad-hoc fashion; communicate, and communicate freely; we don't need to be forced to sort and organise every little piece of work we do into millions of little boxes. Use the tracker for what it's good for: keeping track of the end result (the SCM, the problem database, the "big picture" of the current state of affairs). We don't need some unrelated tool to ordain how we should conduct or day-to-day business processes.
4) For accountability or just a paper trail, we have the Signed-off-by: lines, and those should stay with the patches at all time or they become meaningless. ==> The tracker can _track_ the sign-offs, that's fine; but it shouldn't be the main repository of-em (the SCM is for merged patches; all patches proposed to be applied but still in flight carry them inline with the patch).
I hope this wasn't too long :-)
As always: He who sends a working patch usually wins.
Nah, whoever gets the Signed-off-by: stamp-of-approval on his patch wins :-)
Segher