[forum] XFree86's Future and thoughts and suggestions

[Shawn Starr]

On Tue, 1 Apr 2003, Stuart Anderson wrote:

>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?

Exactly, ugly code just doesn't go into the Linux Kernel, that said there is 
some sloppyness in it but its not dramatic enough to cause alot of work to 
fix.

>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.

I'm pleased to see a central location now to submit patches. I used to see 
them head to Xpert so I'm out of the loop on that.

>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.

I appaud the XFree86 team for implementing this.

>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.

Right, but we don't even know what those quality guidelines are really. 
CVS-HEAD by definition isn't supposed to work, I'm amazed that it really does 
:-)

>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.

Thats fair enough, We should have some sort of QA much like Mozilla does to 
test out things no?

>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.

This is true, I surely wouldn't want everyone to be able to commit to the 
tree, this would cause poor code and degrade XFree86.

Perhaps we should delegate who owns what and then work from there on?

I know some drivers are written by XFree86 people so they should automatically 
be the maintainer of the drivers.

But, I don't know who maintains the X11 library etc, someone should be 
delegated -- should they wish to do it -- the component so we can split tasks 
up easier.

Ideas?

-- 
Shawn Starr
UNIX Systems Administrator, Operations
Datawire Communication Networks Inc.
10 Carlson Court, Suite 300
Toronto, ON, M9W 6L2
T: 416-213-2001 ext 179  F: 416-213-2008
shawn.starr@datawire.net
"The power to Transact" - http://www.datawire.net