Re: A strawman proposal for X.org & XFree86.org

HAvoc!

Thanks for taking the time to give us a solid response. You'll get a 
thoughtful answer.

Leon


On Fri, 28 Mar 2003 15:09:11 -0500 Havoc Pennington 
>
>Hi,
>
>Thanks for getting this started. If we can come up with a good
>proposal for a healthy combined XFree86/X.org organization, I'd like
>to offer to bring the software and draft specs at freedesktop.org to
>the table, as something we'd initially import into this organization.
>This is subject to agreement from freedesktop.org participants of
>course.
>
>On Thu, Mar 27, 2003 at 11:06:17PM -0800, Alan Coopersmith wrote: 
>> X.org members may:
>>    - Participate in the creation or modification of X Window
>>      System standards and X.org steering committees.
>>    - Vote in X.org elections or run for office.
>
>One thing that I consider important is to have the same
>membership/elections/governance for the implementation project and the
>bulk of specification-development/communication work.  Ideally, we
>would not institutionalize a split between those as it just encourages
>snafus.
>
>On the other hand, a split between the project where most of the work
>goes on, and a body that does rubber-stamp standardization and
>certification, may well make sense.
>
>===
>Let me clarify "rubber-stamp." By this I mean essentially what free
>standards group does for the LSB. They create clear documentation and
>test suites for existing de facto design/implementation, fixing the
>implementation only if it is clearly not right. e.g. if the big
>picture of the spec says that you have to be POSIX compliant, you
>would fix the implementation rather than making the spec require
>POSIX-violating behavior. But no really significant changes are made
>on the LSB level, and any changes made on the LSB level effectively
>have to be signed off on by the maintainers of the involved software.
>
>"rubber-stamp" does not mean doing nothing. Rigorous docs are needed,
>agreement on what to include in a spec at all is needed (what is ready
>to set in stone, vs. what is still in flux), test suites are needed,
>and a certification process and logo are needed. A formal standards
>body should provide those things. However, the formal standards body
>should not be changing the technology in significant ways, or making 
>big-picture decisions prior to de facto consensus.
>
>So I'm saying the bulk of what a technical working group would do
>should go on inside the implementation organization. The formal
>standards organization should only kick in once things are pretty well
>ready to be set in concrete.
>
>> Membership is free, and open to any individual who has contributed
>> to the development & adoption of the X Window System standards
>> or to a recognized open source implementation.
>
>Perfect.
>
>> X.org sponsors may:
>>    - Submit hardware and/or software products to the X.org
>>      laboratory for compliance & interoperability testing.
>>    - Access the X.org lab to debug interoperability problems with
>>      the equipment provided there.
>>    - Participate in X.org publicity campaigns.
>
>These are definitely consistent with a "rubber-stamp" standards body.
>
>>    - Provide a representative to the executive board
>
>If the executive board is the board of directors of the corporation, I
>believe it should be elected by the membership. If companies can buy a
>seat, they can effectively buy control of the whole organization.
>
>The other problem is that this effectively grows the board without
>bound, right? An effective board is going to be maybe 9 people, maybe
>14 at most, something like that. Which is a reason to elect a fixed
>number instead of having guaranteed seats.
>
>> Sponsors may contribute a portion of their sponsorship fee by
>> donating services to X.org or the open source implementation.
>
>Good feature.
> 
>> XFree86:
>> --------
>... 
>>   - Maintainer: A developer who has been granted access to commit changes 
to
>> 	a specific part or parts of the XFree86 software.
>> 
>>   - Core Team Member: A developer who has a consistent record of 
contributing
>> 	to technical discussions on the developer lists and/or contributing
>> 	code changes that enhance XFree86.
>
>I don't really see the reason for the core team vs. developer
>distinction.  The structure you want in order to scale can be
>described as a "confederation of module maintainers." For example, we
>might import the D-BUS project into this new X CVS. Then those of us
>working on D-BUS would own that CVS module and participate as the
>maintainers of it.
>
>Similarly, we might create modules for current bits of the X tree that
>have active developers. For example, we might have a module for xterm,
>since lots of people hack on that and it effectively has its own
>maintainers. We might have a module for Keith's font libraries. 
>We might have a separate module for certain drivers. etc.
>
>Module maintainers basically have final say over their modules, except
>when we need to coordinate the big picture, such as to make a release
>and set release schedules. And when you need to coordinate the big
>picture, you need everyone to feel like they're on a level playing
>field and their module is equally represented.
>
>===
>Where I would make a distinction is not on the level of maintainers
>vs. core maintainers, but instead on the level of modules included in
>a particular release, vs. those not included. You can have multiple
>releases; for example, there might be a "drivers release" including
>driver modules, and there can be releases of just individual modules.
>The really big global technical decisions to make are about what
>modules to include in the release of "The X Window System" as a whole,
>right.
>
>When we have these large coordinated releases, decisions about them
>should stem from the group of module maintainers involved, though they
>can and probably have to delegate to a release manager or team.
>
>Experimental modules can definitely exist that aren't in any release
>group yet. 
>
>
>=== 
>Commit access isn't the only thing; all module maintainers need at
>least some access to full hosting services, such as a web site,
>bugzilla, mailing lists, etc. for their modules as they see fit, and
>basic ownership of their usage of those services. So I would not
>define CVS commit access as the only developer vs. maintainer
>distinction.
> 
>> Upon the release of X11R6.7, XFree86 shall integrate the X11R6.7 code
>> into their code management system as the base of the "X.org Standards
>> Sample Implementation" (SSI) branch.
>
>OK, this is where I think the strawman is really off-base. It means we
>have an external organization doing a *lot* more than just formal
>standardization in "rubber-stamp" mode.
>
>We should all get in the same boat, assign the best people to the
>right roles, and work together to keep it above water and moving
>forward.
>
>The XFree86 project should absolutely be producing a good and
>reasonable stable branch on a regular schedule and maintaining it
>according to rigorous policies. There's no reason it can't; many open
>source groups do. Having a separate stable branch maintained by an
>X.org committee is just really strange and will encourage ongoing
>fragmentation and encourage people to take their toys and go home
>instead of creating a unified X community.
>
>If specific vendors have special needs, they can create a special
>vendor branch, or a patch set (such as "sun-patches" on
>cvs.gnome.org). But this shouldn't be institutionalized in the
>structure of the organization, and large divergence between vendor
>branches and the mainline should not be encouraged.
>
>The standard, unpatched XFree86 stable branch should be completely
>usable and shippable by vendors that choose to do so.
>
>It's like the Linux kernel; there are many forks, but ultimately they
>are all feeding back into Linus's tree, and once it's clear some code
>won't make it into Linus's tree that code typically dies.  Similarly,
>we should have a canonical tree, and stuff that doesn't make it into
>that tree should be counted as a dead end.
>
>>  Changes that would change an existing standard or require the
>> adoption of a new standard will not be incorporated into the SSI
>> tree until approved by the X.org Architecture committee.
>
>This is part of why this branch is broken; things should be deployed
>first and rubber-stamped second. Otherwise you standardize broken
>stuff that hasn't seen real-world testing.
>
>> User Fox is convinced that the truth is out there and that everyone 
should be
>> helping in the search for alien intelligence.  To do this, he wants to 
add
>> a new extension to X, the "Force Idle Loops to Execute SETI@Home" 
extension
>> (X-FILES), which he wants to become a recognized X standard.  There will 
be
>> two paths to doing this:
>
>Groan! ;-)
>
>> Path B (Uniform Standards allow easier cross-platform development):
>>   1) Fox creates a spec and submits to the X.org Architecture committee.
>>      They decide to create a working group to study this.
>>   2) All interested parties join the working group and discuss the 
proposed
>>      spec.
>>   3) A sample implementation is written to implement the spec in XFree86.
>>   4) Fox submits his changes via the XFree86 bug tracking system, where 
they
>>      are reviewed by a maintainer.  Since these changes introduce a new
>>      extension & API, the maintainer asks the Core Team for their 
opinion.
>>      The Core Team either agrees to accept the extension into XFree86, or
>>      to allow it only into the X.org SSI branch but not into the XFree86
>>      branch.
>
>Path B should not exist, especially point 4) of it. The whole point
>here is to have, as the GNOME/KDE statement phrases it, "a single
>source of X innovations."  If we can have ongoing disagreement on
>whether a standard is official, or worse, long-term divergence in
>which solution is chosen for a particular problem, then we haven't
>achieved that goal.
>
>But on a larger scale, Path B encourages and institutionalizes broken
>behavior. Devel teams used to the proprietary model need to be
>carrot-and-sticked into learning to do things in a way that enables
>effective cross-company/globally-interesting development progress.
>
>I think it's been made abundantly clear over the past 5 years that the
>open source model has crushed the CDE/X.org model in overall results.
>Encouraging people to stay stuck in the model that doesn't work is a
>bad idea.
>
>If you went down Path B, what would happen is that all the module
>maintainers doing active work would ignore you until you had the
>sample implementation. And then they'd say "well you're going to have
>to rework and iterate this in light of our feedback, or we won't
>accept it." And people won't have been expecting that. They'll then
>expect to be in the SSI branch, but the primary branch would reject
>them. And we'd get long-term divergence.
>
>So Path B is a trap for the unwary. It needs to be clear up front,
>that if you want to develop a feature to be used by the toolkits, you
>need to go iteratively work with the GTK+ and Qt and Swing
>maintainers, *not* only talk to Sun, HP, and IBM.
>
>If you want a concrete example: fontconfig/Xft went via Path A, and 
>STSF is going via Path B. Now we have a huge mess. By having only one
>path, you avoid that, because the same people would have been involved 
>in both projects and could have said "hang on, let's unscrew this."
>
>===
>
>The most important point is probably that the X.org branch and the
>XFree86 branch should be unified, there shouldn't be one stable branch
>maintained by X.org and one by XFree86, we need to create a single
>community. We need to all take the leap into the same boat and then we
>will be motivated to fix what needs fixing.
>
>I don't believe the open source X community has anything to gain by
>acknowledging the legitimacy of a second source of X innovation.  If
>there are two, I believe GNOME and KDE and other open source projects
>should make a formal joint statement that we support the open one and
>will use its innovations to the exclusion of the closed one's
>innovations.
>
>Avoiding this conflict hurts too many people and slows progress; the
>hard decision should be made.  People need to know where to go to
>develop an innovation.
>
>So summary of my feedback:
>
> - only one official shared stable branch.
> - no way to buy a board seat.
> - if there are two organizations, one should be rubber stamp.
>   and certification only, not development of either code or specs.
> - no Path B for development of innovations. One standard path.
> - modularization of the code (and resulting modularization 
>   of authority) is key to scaling the project.
>
>Thanks for your time, as always I apologize for email lengthiness.
>
>Havoc
>_______________________________________________
>Forum mailing list
>[email protected]
>http://XFree86.Org/mailman/listinfo/forum