[LinuxBIOS] Using trac

[Segher Boessenkool]

>> 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