Re: [Gnu-arch-users] Re: named patches, patch order, patch queue manager

[Stephen J. Turnbull]

>>>>> "Davide" == Davide Libenzi <address@hidden> writes:

    Davide> Named patches and virtual patches enable you to work on
    Davide> the same branch with multiple independent logical patches,
    Davide> w/out switching continuosly branches.

>From my standpoint, you're already into implementation.  Remember that
arch branches are very lightweight; switching branches may be
relatively effortless (eg, handled by a front-end tool) compared to
what you're thinking.

Do you know the arch jargon of "clean changeset" (it's used elsewhere,
but past discussions on this list suggest that usages vary)?  Briefly,
it's a patch (with multiple-file scope) intended to accomplish a
single conceptual change.  While AFAIK no arch users branch for every
clean changeset yet, I suspect that this would make a lot of sense for
the lk environment, where a single patch may live for many months before
being blessed.

It seems to me that if you implement such a long-lived clean changeset
as a branch from the trunk, then you do have a virtual patch.  Clearly
you can trivially generate the appropriate patch against any official
version.  It can contain many small patches as bugs are fixed or the
maintainer's requirements change.  It is named.  It can even have
versions (in current arch implementation these couldn't be
conveniently named; you'd have to either use numbers or have a
branch-naming convention).  It can be lazily updated simply by running
replay against the trunk.

What else does your idea of "virtual patch" contain?

    Davide> Virtual patches enable you to create a virtual group of
    Davide> patches dynamically, [IMPLEMENTATION DELETED] [without
    Davide> conflicting with] other virtual patches. And those virtual
    Davide> patches could be fetched by name and trigger the replay of
    Davide> all real (or even virtual) patches that are part of the
    Davide> group.

But these are all basically single-step operations with arch, except
on branches---which are already named.

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

Of course.  But that worthy goal doesn't automatically make the
suggestions themselves good ones.  There often may be more arch-y ways
of accomplishing the same goal, so it is preferable to specify the
behavior that (say) Linus sees and will find useful or annoying,
_before_ suggesting an implementation, however easy.

    Davide> But if you say that it's not true, then I'm feeling better
    Davide> already :-)

I won't say it's not true.  First, I'm not Tom, and second, I don't
really understand what you and Andrea are asking for, because you jump
ahead to implementations which is very confusing.  (Especially with
Andrea, who often jumps from the implementation to something else it
might do well.)

I do think that there are ways of using arch that will give the same
effect, and the current tendency for tla to acquire more and more
cruft (IMHO) is something that I don't like at all (IMHO again, YMMV,
and ITTSIWBO[1]).

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

Oh, there's plenty of open source software I'd be happy to relegate to
bk or Perforce.  But for anything I depend on, I want as much open
source in the support chain as possible.



Footnotes: 
[1]  I Trust Tom, So It Will Be OK.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.