against paranoia Re: [Gnu-arch-users] Arch Roadmap Draft (the anticipated part 3)

[Tom Lord]

[Andrew, please note the stuff below about the relationship between
 merge request formats and browsers (and other tools).   Also towards
 the (pre "-t") end -- the stuff about simple merge requests and 
 projects that are perpetually multi-forked.]

    > From: address@hidden (James Blackwell)

    > >     > I've tried "submission branches" and in my experience they're a 
pain in
    > >     > the rear. I personally suspect that you're pushing "submission 
branches"
    > >     > as a political tool to discourage diverging (and eventually 
forking)
    > >     > branches. What better way to control development, then to 
encourage
    > >     > submitters to keep their patches scattered around in different 
branches?
    > >     > That way, patches aren't concentrated into development trees that 
pose a
    > >     > potential threat to tla (a.k.a. "Tom Lord's Arch"). 

    > > You are wrong and are being rude.

    > No, I am not wrong. That is exactly what I suspect. I also don't think
    > I'm being rude. 

Yes, you are (one presumes) correct that you have accurately stated
your suspicians.  Your suspicians are incorrect and they seem to be
based on rude assumptions about me.

However, you did say:

    > I would be more than willing to listen to any rational argument
    > that proves my suspicions are unfounded.

I am not sure I can "prove" anything to you at the moment but I can at
least explain:

We were discussing a specific technical problem that arises in the
kind of PQM that Andrew is working on for the GNU Arch project.

As you'll recall from the off-list discussions (and I'll forward the
key message here for your benefit and others') the purpose of setting
up this PQM is to create a multi-committer stable mainline into which
a set of co-maintainers are able to directly commit simple changes
without having to wait for me.  The reasons to do that are to speed up
merging throughput for the project and to test out, on ourselves, a
variation on the kind of arrangement that seems to make sense for
projects like GCC or the Linux kernel.

The system we're working on will let people send [MERGE REQUEST] mail
to gnu-arch-users (hence to Bug Goo).  There will be a visible queue
of pending patches.  Roughly speaking, whenever two co-maintaners
approve a patch, an automatic merge will be attempted.  Automatic
testing will watch for regressions.  There are "escape hatches" in the
system to flag any changes not trivial enough to slip into the
mainline this way but generally it should speed things up a lot and be
quite a pleasure to use.

A technical problem arises about those merge requests: they have to
drive initially one and ultimately many automated processes.
Initially, they have to drive the automatic merge step.  Eventually,
the merge requests will drive things like automatic caching and a web
interface for browsing requested merges.

One idea is to make the format of a merge request as general as
possible: to make it possible to request even quite unusual merges
(such your example of cherry-picking a set of non-contiguous changes
but also even hairier examples).  This idea has the problems that it
makes the merge processor more complicated and that it makes other
processes (like a pending-merge browser) much more complicated.

For example, if each merge request is available as a single changeset, 
then a browser can display any merge request without doing anything
more than unpacking a changeset .tar.gz.   On the other hand, with
arbitrary merge requests, a browser would have to actually build the
candidate tree in order to show the changes whose merger is proposed.

Another idea is to make the format of a merge request very simple
and support only the most basic kinds of merge.   For example, it
would be nice if the pending-merge browser could show the changeset
for a merge request without having to actually perform the merge
first (i.e., just by unpacking and displaying a changeset).

Keeping the merge request format simple solves the problems with a
general merge request format, but, as you've noted,
_absent_any_other_arch_features_ increases the burden on contributors.

In and of itself, that's arguably ok.  _Somebody_ has to do the
equivalent work of creating a submission branch for each merge
request.   By asking submitters to do that work we would be, as I
said, implementing a scalable process.

But as it turns out (and I've advertised) I'll also be adding some
other features such as support for automatically maintained submission
branches.  In other words, the features that are coming will relieve
developers of any onerous burden in preparing their (limited format)
merge requests.

In the limit, a processor for the kind of merge request processor you
have in mind _might_ make great sense in this scheme, but as a
client-side tool from which the streamlined merge requests I'm
proposing for the PQM are automatically generated.   Client-side, not
server-side computation.

You seem to have some theory that, by limiting the range of allowable
merge requests, I'm somehow forcing people to "keep their patches
scattered around in different branches."   No, not at all.   Rather, 
all that this does is push the work of preparing an isolated changeset
for a merge from a server-side to a client-side computation.   Users
can develop changes on their own branches, in whatever arrangement
they like.   When they identify a subset of changes they want to
merge, all that the limited-merge-request approach does is have them
run a program to prepare a candidate merged tree client side and, from
that, generate a simple changeset.   If we do this right, user's won't
even have to care about the names of the submission branches that
are created for their merge requests!

You seem to have some theory that somehow this arrangement is meant to
discourage forks.  Nope again.  I go back and forth on whether or not
forks are desirable, undesirable, or neutral but, when I think they
are undesirable, I conduct my Machiavellian maneuvering to counter
them in just one way: by talking openly about why I think it's a bad
idea.  (Conversely, when I think they are desirable, I talk about
that.)

The limited merge request format wouldn't _hurt_ the prospects of
forks: it would _help_ the prospect of forks.  In fact, that's an
important property of it and one reason to do it this way.  The work
needed to make a limited-format-merge-request is the very same work
needed to express a change in a way that it's easily portable to other
forks!

And that's a good thing.   After all, projects like the linux kernel
consist of almost _nothing_but_ forks with changes submitted for one
fork showing up on the others, sometimes ahead of the time they show
up on their intended target.   A limited merge request format
facilitates, not hinders that process.

    > >> Pardon? Are you telling me what to think when?

    > Then Tom Lord replied:
    > > Um...  no.  I'm saying that if you want me to consider those points in
    > > detail you should remember them until it's closer to the time to work
    > > on those details.

    > Sure, I'd like for you to consider them, as you're the current arch
    > project lead. After all, my post was in direct response to _your_ post!

Right and I'll still be here tomorrow and the day after and all I'm
saying is that there are now many, many points that might be worth
discussing and so it makes sense to take them one at a time,
considering each in its due time.


-t