RE: Community government, new developers, release cycle

Eric raises a number of important issues, one
of which hits home.  XFree86 has done a very
poor job of communication with the open
source community and XFree86 users as a
whole.

Thanks Eric for taking the time to force us
to dive deeper into these issues.

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Eric Anholt
> Sent: Thursday, March 20, 2003 3:41 PM
> To: [email protected]
> Subject: [forum] Community government, new developers, release cycle
> 
> 
> The most basic problems I see with the XFree86 project are 
> the lack of community government, resistance to new 
> developers, and a slow release cycle.


The XFree86 core team makes all the real
decisions.  The community that writes the
code actually does the governing.

Perhaps David Dawes could influence decisions
or make executive decisions but he rarely
does, and never does so without consensus.
Still as release engineer, he is responsible
for pushing core to set release dates and
feature freeze dates.

Developers are admitted on the basis of
amount and quality of code they have
contributed - strictly sweat equity.  As a
result of this core has consistent level of
practical experience in what works and
doesn't work in implementation or
architecture.  This has been essential to the
effectiveness of the core team.


> The slow release cycle is a straightforward problem.  
> Distributions (FreeBSD for example) end up shipping the 
> year-old X releases and lacking support for significant new 
> hardware.  We have the option of backporting drivers, of 
> course, but then that work would be duplicated across many 
> distributions, and most of us don't have the time and often 
> the hardware and experience necessary to do it.

 
The release cycles are highly dependent on
the amount of free time the core team members
have.

To give you an idea of how much David Dawes
contributes, look at the rate of progress and
the positions that David Dawes has held. You
will find a very strong correlation between
the amount of time his employer dedicated to
XFree86 work and the rate of the releases.

David picks up the brunt of the release
engineering, XFree86.org maintenance, CVS
maintenance and as a consequence and now team
leadership.  So, his influence on cycles is
quite understandable.  If someone had stepped
up to the plate for all these thankless
tasks, the picture might be different.  But
the truth is he has been a catch-all for much
of the project for many, many years.

The loadable driver model was motivated
specifically by the issues you are raising.
It was intended to separate release
engineering for drivers vs. the server.

>  The solution 
> I think would be optimal is running development in two 
> branches, one being HEAD, which would be targeted now at 
> XFree86 5.0, and a stable branch, which would continue 
> releasing 4.x and backporting tested fixes and updates until 
> it's been acceptably replaced by 5.x.  Yes, this would 
> require more work by the committers, but that could be 
> alleviated by allowing more committers.


What works for FreeBSD doesn't necessarily
work for XFree86.  Keep in mind that XFree86
runs on about a dozen OSes.  Multiply that by
the number of versions of OSes, times the
number of hardware platforms....

Now multiply it by the number of video cards
and new models.

The code base is large, number of test
platforms is large and number of binary
distributions is large.  Perhaps someone will
come along some day and begin to maintain a
stable branch.  However, given the talent of
the core team, that wouldn't be the best use
of their time as it stands.

> Community government: I was able to find BOD bylaws through 
> google cache, but nothing about core.  I know exactly one 
> member of BOD, and 6 out of 15 of core.  None are elected, 
> that I know of.  What decisions that are made are done in 
> private and little is known of how they came about.  I think 
> FreeBSD core handles this well: They conduct discussions in 
> private, but release monthly minutes to the developers of the 
> key points of discussions and the votes that occurred, minus 
> anything that was explicitly requested to be private.  The 
> nine members are elected every two years by the developers 
> (anyone with cvs access, currently somewhere around 330 I 
> think). If there is going to be a core/BOD team running 
> XFree86, I think they should be elected by those who have a 
> stake in developing XFree86 (current committers, driver maintainers, 
> contributors, distro maintainers, DRI developers, GATOS 
> developers, ???).

The decisions that are made by XFree86 are
made almost exclusively by the core team.
This is exactly how FreeBSD operated till
recently.  Many organizational and process
ideas were borrowed from FreeBSD.

FreeBSD's elections are a relatively recent
development, and the minutes are even more
recent.  The minutes have provided
transparency, not the elections.


Perhaps XFree86 needs a secretary and monthly minutes.


Much of the public misconception is due to
lack of communication.  I might never have
thought about this if you hadn't made the
comparison to FreeBSD.

Still, it's not clear that popularity is a good
measure of effectiveness as a core team
member.

On the other hand, sweat equity (in the form
of code and quality) is a great measure of
effectiveness as a team player.  The
accumulated investment of code often becomes
a further motivation for ongoing commitment.
If one has a lot of time and code invested,
it motivates one to want to see the project
as a whole succeed.


> Resistance to new new developers (in terms of access to CVS): 
>  I think this is the primary problem most people see with the 
> project as it currently exists.  It has resulted in the 
> forks, including GATOS and DRI, which make it difficult to 
> track new development of XFree86.  I don't see this being 
> solved until there is community government of the project, though.

Join devel, write code, join core.  That's how it works.

That's how FreeBSD got here.

I don't see a more effective solution than that.

> -- 
> Eric Anholt                                [email protected]          
> http://people.freebsd.org/~anholt/         [email protected]
> 
> _______________________________________________
> Forum mailing list
> [email protected]
> http://XFree86.Org/mailman/listinfo/forum
> 
> 
>