[LinuxBIOS] Using trac
Segher Boessenkool
segher at kernel.crashing.org
Mon Nov 6 00:26:11 CET 2006
>> 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
More information about the coreboot
mailing list