[Gnu-arch-users] named patches and "Does Linus matter?"

[Tom Lord]

    > From: Davide Libenzi <address@hidden>

    > Named patches and virtual patches enable you to work on the same
    > branch with multiple independent logical patches, w/out
    > switching continuosly branches. Virtual patches enable you to
    > create a virtual group of patches dynamically, on the same
    > branch that hosts other virtual patches.

I suggest that we look a little bit at how the functionality of these
features is already there, today, at the cost of a little bit of "by
hand" bookkeeping -- and then, possibly, at how to further automate
that.  At least one person has been working on that for a while now.

It sounds as if what you are proposing here is a kind of structured
cherry-picking: a single version, containing a mix of changes, some
record keeping that labels the changes as being for this or that task,
and some tools for manipulating changes by task name.  That's all
pretty easy in arch, using existing functionality.  You could try, for
example, working that way for a while and doing the bookkeeping in
text files with a text editor.  Then based on that experience figure
out how best to automate it.

Cherry-picking like that has its drawbacks, of course.  If the various
"logical changes" overlap at all, then it takes some work (including
the possible need for human intervention) to tease them apart into
clean changes against a particular baseline.  Even if they don't
overlap, if you don't factor them out "early", then you aren't testing
them in isolation.  That's why we talk about practices like "prism
merging":

The prism merge technique gives you kind of a best-of-both worlds:
you have a main version in which you hack on all the logical tasks at
once, winding up with a single logical change that is spread out over
many different revisions.   At the same time, you incrementally and
proactively factor out those changes into branches that correspond to
each logical task.    So, it may very well be that the functionality
you want is simply a matter of figuring out how to better automate the
prism-merge technique.

Alternatively, perhaps what you want is a kind of "lazy prism merging"
in which the factoring step is postponed until you actually need the
changes against a particular baseline.   I believe it has been
previously suggested to have, in essense, a little warning bell that
goes off when you've accumlated too many unfactored change-fragments,
thus encouraging you to do some factoring.

And, of course, "lazy prism merging" seems like a technique that would
dovetail nicely with a batch process that can detect for you when
factoring out changes is going to require human intervention.



    > >     Davide> ... but adding code is always bad if there're other simple
    > >     Davide> ways to do the same thing.

    > > Good advice.  Consider it yourself.  :-)

    > Sarcasm apart, the reason of suggestions coming from myself and Andrea
    > (that knows better than me intrinsic problems of lk handling) is that we
    > both would like to see arch used by Linus.

Almost without exception, the best ideas for improvements come from
people who are worrying about their own needs or the needs of people
with whom they work very closely already.

"Linus", as you're using him here, is a pretty vague abstraction.


    > And this w/out arch being killed by LM or by the same
    > Linus/maintainers finding out that what they did in one step
    > with bk it takes four in arch.  But if you say that
    > it's not true, then I'm feeling better already :-)

It's not true that that's something important to worry about.   And
it's certainly not true that such a concern justifies blue-skying
about redesigning this or that.


    > (pls note that I have nothing personal against LM or bk, but I'd
    > just like to see open source software handled by open source
    > software)

Sure.  But such appeals to an "issue of the day" aren't going to
impress or intimidate us.  They are a red herring.  Mentioning them in
this context doesn't add any weight to your proposals -- just the
exact opposite because it suggests that you're thinking in vague,
speculative terms about the needs of someone else rather than about
needs that you've discovered in practice.

When you get pushback on an idea or encouragement to shift your
approach to working it out, and you reply with "Yeah, but I'm trying
to kill BK," what do you expect to happen?  Do you think I'll say,
"OH.... killing BK, well, in that case...."

Now, as it turns out, the functionality you're pointing towards is
something we've been aware of dealing with for quite a while.   Mostly
we're gaining actual experience to see where little bits of automation
will help.   Stephen has been designing some archivist features for
this purpose.   I've been doing prism merging by hand and thinking
about if/how to automate it further.   Rob has gained plenty 'o
practical experience living in "cherry-picking" hell and is now on his
second generation of tools to help with it.   A few contributors have
thrown merge requests at me that illustrate the issues.   I think it's
out of directions like _that_ that we'll see progress on features --
not out of chatting about Linus who isn't even here to contribute to
the discussion (I hear he's busy on some other project).

There's plenty of other projects and users from which we get solid,
real-life, experience-driven feedback.  That's worth a lot more than
speculative feedback about how Linus or anyone else might or might not
one day use arch or compare it to BK.

In some sense, the best way to prepare to help Linus use arch might be
to ignore him and BK, and stick to what we actually know, rather than
what we imagine.

Simply building the very best revision control system in the world is
the right way to open the door to pushing BK out of the free software
community.  A helpful kind of "operational arrogance" might be to
assume that, as a first approximation, the most efficient way to
produce the very best system is to simply ignore the mostly bad
example of BK.    It's not a universally true heuristic, but it's
starting to seem like its needed here.

-t