Re: [forum] A strawman proposal for X.org & XFree86.org
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Of course all this assumes that it makes real sense to have a separate SSI and XFree86 tree (I don't understand the issues enough to comment here).
In hindsight, yes, this was one of the unwritten assumptions of the proposal. The alternative is to get X.org out of the implementation management business altogether and make X11R6.7 the final release and make X.org a pure standards body.
I can't speak for all the other vendors, but I know at Sun we're currently tracking changes in both the X.org & XFree86 trees and bringing in bits from both when appropriate, so the current situation is double the work of dropping the X.org release and moving completely to XFree86.
The challenge in a complete merge of the source trees and only carrying one forward is in finding a good way for XFree86 to walk the line between the stability expected from the current X.org releases and the faster release schedule & expanded integration processes many people have been asking for here.
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.
Stuart Anderson <email@example.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.
-- -Alan Coopersmith- firstname.lastname@example.org Sun Microsystems, Inc. - Sun Software Group Quality, Integration, & Customer Success (QICS) Platform Globalization Engin. - X11 Engineering
[Photo] [Yosemite] [MIPS Linux] [ARM Linux] [Samba] [Linux Security] [Linux RAID] [Linux Resources]