[forum] XFree86's Future and thoughts and suggestions

[Stuart Anderson]

On Tue, 1 Apr 2003, Shawn Starr wrote:

> The problem is this, its not just about commit access it's about the will of
> the core members to allow contributions into XFree86 so everyone can test it
> out instead of blowing the patch out of the water.

The "core members" aren't trying to keep anything out, as long as it isn't
obviously buggy, or just implemented wrong. Usually, in these cases, it is
rejected with an explanation, and a request to fix the problems so it can
be accepted on the next submission. Isn't this pretty much what Linus does?

> I feel the whole core membership idea is a blockage to XFree86 development.
>
> User develops patch, gives it to Xpert@ it may get some criticisism and may go
> into the CVS tree or it may die silently.

Sending it to Xpert is the wrong place. Patches should be submitted to the
XFree86 bugzilla, where is can be properly tracked. Before the recent addition
of the bugzilla, patches should be sent to patches@xfree86.org or
fixes@xfree86.org. That is where the people committing changes are looking
for stuff.

If something just dies or falls in a crack somewhere never to be heard from
again, that's a bad thing. The bugzilla was set up to reduce the chances of
that happening.

> If you really want XFree86 to change you need to decide if you're willing to
> let the community, any by community I mean all kinds of developers input into
> XFree86.

There shouldn't be a question of wether the community has any input, or the
willingness to accept such input. They do.

The only thing XFree86 is likely to resist is anything that causes the overall
code quality to turn to crap. If we blindly applied every single patch that
was submitted, this is what would happen. The same thing would happen to the
Linux kernel, which is why Linus rejects somethings that don't meet his
quality guidelines.

Things don't get accepted into XFree86 not because of any egotistical or
political motivations, but because either they will break something else,
which the original contributors probably didn't realize or intend, or
otherwise reduce the long term supportability of the code pool. The only other
situation that can occur is when it just falls thorugh the cracks, but we
have tried to solve that with the use of a bugzilla.

Ask any software engineer with some project mangment experience about this,
and they will agree, you can't just let every one change everything and
expect it to work. This isn't about a catherdal or bazaar comparison, but
the real world requirement so keep the product stable and maintainable. In
order to increase the number of peopel that have commit access, some rules
need to be written down so everyone can follow them. This is one of the things
being worked on, and I believe that every other project out there has a
similar set of rules, written or unwritten.


                                Stuart

Stuart R. Anderson                               anderson@netsweng.com
Network & Software Engineering                   http://www.netsweng.com/
1024D/37A79149:                                  0791 D3B8 9A4C 2CDC A31F
                                                 BD03 0A62 E534 37A7 9149