Re: [forum] A strawman proposal for X.org & XFree86.org

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




On Fri, Mar 28, 2003 at 01:48:19PM -0800, Alan Coopersmith wrote: 
> The most common solution to this problem seems to be maintaining seperate
> branches for seperate needs - Current vs Stable in many projects, 2.2 vs. 2.4 vs 2.5
> in the Linux kernel world, etc.  The proposed "standard" branch vs XFree86 branch
> is just another way of naming them, and a slightly different way of managing them.
> Perhaps simply doing stable, current, and maybe experimental branches is a simpler
> path.

Here are some differences between the usual solution and the
SSI-maintained branch:

 - In the usual model, maintainers of a module own that module on both
   stable and devel branches of said module.

 - Stable branches are bugfixes-only. Feature backports are evil,
   because they keep you from leaving a stable version alone and
   moving on to the next release. This stagnates the devel branch and
   destabilizes the stable branch. It also sucks up a lot of time.

 - Stable branches branch from the development branch on a regular
   schedule, and have exactly the set of features that were in the
   development branch at the branchpoint.

I would do "experimental" as feature-specific branches. e.g. a branch
to add RENDER, or a branch to refactor XYZ, or whatever.

> Stuart Anderson <anderson@netsweng.com> wrote:
>  > We are currently trying to _reduce_ the number of branches of the
>  > X tree, and prevent the creation of a new one. Having a seperate
>  > branch doesn't contribute to this at all.
> 
> I'm not sure I agree with that.  We are trying to reduce/prevent forks
> in the projects, but I don't think everyone agrees branches are necessarily
> a bad thing.  With branches everyone is still working together and conflicts
> have to be resolved.  With forks, people can go in different and incompatible
> directions and commonality may be lost.

The reason the SSI-maintained branch would be a fork rather than a
stable branch is that it might add/remove features vs. the development
branch. While a branch would keep the feature set and API/ABI found in
the development branch at the time of branching and focus on
incorporating fairly safe/nonpervasive bugfixes.

In other words, the stable branch would be a periodic stabilization
and release of the trunk, followed by bugfix-only maintenance for some
period.

The trunk shouldn't be a free-for-all either; it has to remain
compilable and basically usable, or developers can't work on their
section of the code - if the X server doesn't start up and run, I
can't work on my extension or whatever. And you need dogfoodability to
be able to stabilize and release in a reliably short timeframe.

You need to branch-and-release the trunk reasonably often, so that
feature work is made available on a regular basis. i.e. if I write a
new extension, it should land in a shippable stable release within 6-9
months, without having to do a backport. Otherwise, vendors and other
people with deadlines can't realistically focus their efforts on the
trunk, they get stuck on stable, only dreamers work on the trunk, the
trunk becomes more and more broken, there is heavy pressure to
destabilize the stable branch with backports, the next release of
trunk gets further and further away, and you get a downward doom
spiral. Yes I am speaking from bad past experiences. ;-)


What I'm describing here works OK for a 300-developer project with 3
heavily involved companies, and a lot of stuff we tried before that
didn't work, sometimes failing in impressive ways.  We're still
refining the details, of course. ;-)

Havoc



[X.Org]     [XFree86]     [XFree86 Discussion]     [XFree86 Newbie]     [IETF Annouce]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Samba]     [Linux Security]     [Linux RAID]     [Linux Resources]


  Powered by Linux