[Gnu-arch-users] patch trackers (was the thread that shall be unnamed)

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>

    >     Tom> cscvs is a separate project and I'm not sure why you'd
    >     Tom> mention it in this context -- but from what I can see, the
    >     Tom> cscvs project uses an unholy marriage of private mail,
    >     Tom> gnu-arch-users mail, and #arch irc traffic as a crude
    >     Tom> approximation of a patch tracker.

    > Exactly.  Although cscvs is an important project to many arch users,
    > and can benefit from and be hindered by arch changes, it's not in the
    > arch patch tracker.

    > So what it comes down to is that the savannah bug tracker is about
    > access to Tom.  It reflects and probably encourages centralization of
    > decision-making in Tom, and does not help those parts of the community
    > which are doing something that Tom is not directly involved in.  It
    > encourages Tom to focus on the bug-tracker as the source of patches
    > and other arch development issues, possibly tending to exclude issues
    > that relate to third-party projects.

    > Whether these are good things or not, I don't know.  But they are not
    > decentralizing influences as currently implemented.

Sure.   I don't mean to impose "make a decentralizing influence" as
the primary design constraint.

It's interesting that you talk about two distinct but related projects
for which it'd be useful to have some kind of "cross linkage" of patch
tracking.   One obvious question is just what exactly kind of "cross
linkage" are we talking about?   That's an aspect of the the more
general question "What exactly does a patch tracker track"?

But leaving those questions aside and just assuming that a patch
tracker tracks _something_ worthwhile and that there is _some_form_ of
cross linking:

Presumably when we have multiple projects coordinated this way we have
to think about crossing administrative boundaries.   I'll have my
patch tracker, you'll have yours, but linkages and so forth have to
span the boundary between them.    Just as a general principle, that
suggests following the arch-like pattern (and usenet-like pattern) of
a location-independent global namespace with underlying distributed
storage management.



    >     > Making Linus and even the whole gatekeeper collection faster is a
    >     > worthy project.  But it seems you think something is going to make 
it
    >     > possible to get Linus off the critical path.  Don't hold your 
breath.

    >     Tom> I don't have to get Linus off the critical path.  That
    >     Tom> happened a few years ago (quite independently of bitkeeper,
    >     Tom> too).

    > Then why does it matter if Linus drops Miles's patches on the floor?
    > The fact that the project could continue without Linus is irrelevant
    > to whether Linus is on the critical path in the current organization.

I just think he's not on the critical path in the sense that
distributions tend to get ahead of him on this or that feature and
(don't they?) display features that propogate other than through him?
I think he's not on the critical path for short and medium term
distribution releases.

Thinking about it, though, he presumably _is_ on the critical path of
longer-term cross-cutting architectural issues and on the critical
path of getting everyone to more or less agree on "what the state of
the kernel is".

It doesn't, in my view, matter much that Linus himself drops Miles'
patches.  It matters that where a database could save Miles' a lot of
labor, there is no database, and Miles' labor is substituted to
compensate.  It's not so much Linus' efficiency I'm concerned with:
it's the efficiency of all the contributors.

Linus says: "Ok, here is 2.6" and everybody with pending patches has
to figure out whether they still apply, whether they're remembered or
dropped, etc.   A patch tracker can automate much more of that -- what
we currently have is a lot of people doing patch-tracker bookkeeping
by hand.


-t