[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stephen J. Turnbull
Subject: Re: [Gnu-arch-users] Re: named patches, patch order, patch queue manager
Date: Thu, 02 Oct 2003 11:47:08 +0900
User-agent: Gnus/5.1001 (Gnus v5.10.1) XEmacs/21.4 (Portable Code, linux)

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

    Davide> Nope, they're two different things.

Only because you've already put restrictions on the implementation,
and your proposed implementation is somewhat different from the
implementation of arch branches.

    Davide> It is very simple to implement (once you have named patches),

But arch does have named patches, except that they're called branches.

There's nothing that prevents you from having a one-patch branch.
There's nothing that prevents you from creating a branch and adding
only that patch to it later, thus giving the patch a name "ex post".

This scheme has all the properties you have so far specified (nb. this
is my opinion because you have drawn no dividing line between
specification and implementation, and there's far too much low-level
implementation in your posts) for a virtual patch.

    Davide> The other one (that is maybe simpler to implement since it
    Davide> plugs on the current implementation) is to have a file
    Davide> ++patch-names inside the patch revisions directory that
    Davide> lists:

But even simpler yet (in terms of new low-level arch code) is to
simply create a new branch (actually, probably at least two, a
"working" branch containing the purely numbered patches "patch-NNN"
and a "submission" branch containing the ordered named patches
"vm-fix-superflous-tlbflush-NN", where the submission branch will have
the name "vm-fix-superflous-tlbflush").

You just don't like the namespace that Tom chose; lots of us agree
with _that_ matter of taste, but (unfortunately) there is no agreement
on a better organization.  Maybe the ideas of virtual patches and
named patches point to something generally useful.

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

Good advice.  Consider it yourself.  :-)

Institute of Policy and Planning Sciences
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]