Subject: Re: Tangent: Current-kernel revision naming...
To: Chris G. Demetriou <firstname.lastname@example.org>
From: Andrew Brown <email@example.com>
Date: 02/15/2000 21:03:13
>> certainly the big fixes will be different (in that sense, 1.4.1 and
>> 1.4.2 are merely more "mature" descendants of 1.4), but the features
>> will all be the same, no? and 1.4 won't have any features that 1.4L
>> lacks, will it?
>Depends on what you mean by features. Could well be that entire
>programs are removed from the source tree between 1.4 and 1.4L... 8-)
yeah...i know. or moved, as in the case of, for example, nfsd between
1.1 and 1.2H. :)
>> >As a matter of policy, things must be done -- possibly differently
>> >("the right way") -- on the trunk before they are done on the branch.
>> >Which means, in some sense, in terms of bugs and features, you could
>> >claim that "1.4A" is a descendent of the "1.4". However, if you're
>> >going to apply that metric, then similarly there is some revision x
>> >for which it can be said that 1.4x contains all of what is in 1.4.1,
>> >etc. (at worst, the value of x on the trunk when 1.4.1 is released).
>> sure. but i'd argue that 1.4.1 and 1.4F are siblings at best, or
>> perhaps, more properly put, cousins; no direct descendant relationship
>> is attachable (is that a word?).
>So, pick one.
>If you want to use features as a metric, you have to
>call 1.4x a descendeant of 1.4.1 if you call 1.4A a descendant of 1.4.
i'm obviously doing a very bad job of convincing you that i'm not
completely confused. perhaps what i'm searching for is that last
epsilon version of -current that was 1.3x from which 1.4A and
1.4-release sprang. if had a better name for it, i'd use that. but i
>If you want to use code branching as your metric, then neither are
true. the code-branching is always more complex. but it doesn't
always reflect what the world sees, which is generally "releases",
"patch releases" and "current". not everyone is entirely cognizant of
the nigh-infinite number of branches from -current (like the softdep
branch or the bounce buffers stuff).
>> if i was to draw a straight line
>> that was current, like this
>> where these are the -current source code (and they all have letters),
>> then 1.2-release would (in my mind) branch sideways (to the right) at
>> the same point that 1.2A was "created". 1.2.1 would go sideways from
>> that (1.2-release) and 1.2B would be further down the page.
>The correct representation of the relationship can be found, for
yeah, i've seen that, and referred people to it at times. i'm jsut
trying to simplify it a bit here. to no avail.
>(it's worth noting that, now that you can get things via cvs, of
>course, you can get to the trunk even as a release branch is being
>stablilized for actual final release.)
yep. that part i knew.
>Here's a riddle for you:
>if 1.4A is to be considered a descendant of 1.4, how is it that
>the revision 1.4A can appear to developers and even the public (e.g. in binary
>snapshots) before 1.4 is finalized? we even got to 1.4B before 1.4
>was final, this last time aroudn...
>You can't really be a descendant of somebody who came after you. 8-)
1.4-release was still "being born" at the time that 1.4A came "out".
it was a long, arduous labor and then it spent six weeks in the nicu.
1.4-release is less featureful than 1.4A, but they are definitely
>> >It is obviously wrong to claim that there's some revision 1.4x which
>> >is a descendant (by any metric which actually involves source code
>> >origin) of 1.4.1. The relationship between 1.4 and 1.4A isn't quite
>> >as obvious, but, in the same way, it is untrue to say that 1.4A is a
>> >descendant of 1.4.
>> that's true. i wasn't trying to claim that at all. merely that 1.4K
>> and 1.4.1 have some common ancestor. they are both, after all,
>> descended from, say, 1.3M, no? even if the features that 1.3M has
>> aren't *all* represented in 1.4-release.
>And, similarly, 1.4 and 1.4A have a common ancestor (1.3M, if that's
>the right letter, but more properly called netbsd-1-4-base).
>1.4A is netbsd-1-4-base + some set "X" of changes.
>1.4B is netbsd-1-4-base + some set "Y" of changes.
>1.4 is netbsd-1-4-base + some set "Z" of changes.
okay. then netbsd-1-4-base is the name i'm looking for, but never
actually used, since it's a cvs tag, and not a version tag (like 1.4,
1.4.1, and 1.4G are).
>X is a proper subset of Y.
>That is the only relationship between those sets of changes.
and Z? Z is a set of some members of X and some members of Y (albeit
retrofitted), and some other fixes. no?
>If you want to look at it from the "sets of changes to features/bugs"
>standpoint, then maybe you can make a stronger claim, but you've
>already discounted that in the 1.4.1 vs. current case.
i didn't mean to...really.
|-----< "CODE WARRIOR" >-----|
firstname.lastname@example.org * "ah! i see you have the internet
email@example.com (Andrew Brown) that goes *ping*!"
firstname.lastname@example.org * "information is power -- share the wealth."