Re: [Gnu-arch-users] Re: give us a hand with arch

[Davide Libenzi]

On Sun, 28 Sep 2003, Robert Collins wrote:

> On Sun, 2003-09-28 at 19:38, Andrea Arcangeli wrote:
>
>
> > I already made the point that to be universal and to work with all sorts
> > of languages and binary formats, you *can't* mix data with metadata. The
> > default mode should be changed to be explicit, then if you want to leave
> > tagline for backwards compatibility or for smaller projects that's
> > certainly fine with me.
>
> Bah, I started to answer your email point by point.
>
> Lets just say:
>
> taglines are an advance over explicit, not suitable for all projects,
> but shortly, when per dir regexs exist, they will be suitable for all
> projects. They handle binary and textual data *just fine* (especially
> when combined with some explicit tagging). There is little interest
> *here* that I've observed in removing the tagline concept. I'm a
> hardened explicit mode user BTW, so this isn't 'biased cause I like it'
> talk.
>
> May I suggest:
> * If you don't want to use taglines thats fine: they are optional.
> * If you trust the folk here who have been using arch for more than a
> few days ;) then please set your tagging-method to tagline (even though
> you plan to use explicit everywhere). We aren't *ignorant*.
> * Your arguments about pollution are quite specious, and not backed up
> by any empirical evidence I'm aware of. You might want to review your
> assumptions before you discard the concepts out of hand. Given that
> users can grab source via arch, it's not resonable to handwave that
> users 'find it worthless' when, if the tools are easy, they may well
> find it *invaluable*.
> * Whilst I'm positive that arch will be improved to meet kernel hackers
> needs, dropping or even deprecating tagline would not be an improvement.
> I think you need to really *test* tagline behaviour and facilities - for
> example exports *through* another RCS system without data loss - before
> dismissing them out of hand.

Personally I do see some of Andrea points. I'm using explicit tagging
because, like Andrea, I do want to commit strictly. I do not see any
reason of using tagline with the unrecognized trick, that in my case will
loop back to the explicit behaviour. I see others willing to use tagline,
and this is perfectly fine if this fit their needs. No one is asking to
drop the tagline thingy. I also, like Andrea, do not like data<->metadata
mixtures. Another thing that maybe it has been already noted is the
ability to have a unique patch-id instead of patch-1..N. The uinque id
like sched-fix-starvation-H1 describe the summary and enable you to index
the patch set w/out a lookup patch-summay--->patch-N. The order can be
simply accomplished with a :

$ ls -l
sched-fix-starvation-H1
vm-drop-oom-killer
fix-acpi-int-table
...

$ cat ++patch-order
fix-acpi-int-table
sched-fix-starvation-H1
vm-drop-oom-killer
...

It is also cleaner for a maintainer to say "your patch
sched-fix-starvation-H1 is crap" instad of "your patch-243 is crap". I
also believe that patch names should be preserved across branch<->branch
syncs, likely with a prefix of the project/branch name from where they
come from. Also a sync from another branch should not generate a single
patch, but it should report 1:1 mapping with merged patches. This will
help the multiple cross-merging between different tree/branches, by
letting arch to figure out what has been already merged. The problem
reported at page 108-112 of the fine-manual would have a more easy
solution if patch-4 inside mainline--0.1 would have been the explosion of
candice--0.1--patch-1 and candice--0.1--patch-3. So if the brances would
have been :

mainline--0.1                        candice--0.1
----------------------------------------------------------------------
base-0                               base-0 (tag of mainline--0.1--patch-1)
patch-1                              patch-1
patch-2                              mainline--0.1--patch-2
patch-3                              mainline--0.1--patch-3
candice--0.1--patch-1                patch-3
candice--0.1--patch-3                patch-4
patch-5
patch-6

It'd have been easier to figure out what's missing w/out complex
algorithms. Performance can be improved, and the rest looks great ! :)



- Davide