[Xorg] Re: CVS access policy, branching/tagging, code review, etc.
Kaleb S. KEITHLEY
kaleb at shiman.com
Tue Mar 2 12:56:15 PST 2004
Keith Packard wrote:
> Around 15 o'clock on Mar 2, "Kaleb S. KEITHLEY" wrote:
>
>
>>Maybe in some organizations. The way this tree was originally set up it
>>is intended that HEAD be the release vehicle.
>
>
> I'd really rather see "normal" development done on HEAD with releases done
> on branches; the expectation is that the release branch will provide a
> place for back-porting of security fixes with future minor releases. How
> is that done in the CURRENT-STABLE-HEAD world?
>
You'll have to define "normal" then because as I indicated this is
normal for *BSD.
But nothing is graven in stone. As you can see, Egbert has created his
-RELEASE-1 branch and there's nothing saying that a release can't be
made from that.
As for how it works in a -CURRENT-STABLE-HEAD world, stable bits make it
to the HEAD. After you merge to HEAD you can create a branch from HEAD
for security fixes and minor releases.
(In the -CURRENT-STABLE-HEAD release, released sources have two digit
versions in the RCSID string, versus If all your work happens on HEAD
and you make a branch for a release, released sources have four (or
more) digit versions. Not that it matters how many digits are in a
file's RCSID string.)
<ascii art>
- -CURRENT ----+---------------+------->
/ \ MFC \ MFC
- -STABLE-------------------+---+-----------+---+--->
/ \ r1 \ r2
HEAD------------------------------------+---+-----------+------>
\ \- r2 branch ->
\
\- r1 branch ->
</ascii art>
The tree is there to be used. If people don't want to use this style of
tree, there's nothing that says they have to. It happens to be a
mechansism that I have more than a passing familiarity with that I think
works well. It is upside down from the way a lot of people work, but
then I liked my RPN calculator too. :-)
--
Kaleb
More information about the xorg
mailing list