[forum] XFree86's Future and thoughts and suggestions

[Mark Vojkovich]

On Tue, 1 Apr 2003, Shawn Starr wrote:

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

   The patches list has been around for years and was the correct
place to send patches to.  Xpert never was.  Patches are likely to
get overlooked if sent to xpert.

> 
> >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 
> :-)

   Actually, I believe the unwritten rule for XFree86 CVS-HEAD is that
it's always supposed to work.  It always must build and you are
not allowed to check in stuff that you know breaks things.  And if
you do break things, you are expected to fix them or revert them
in a timely manner.  It's OK to check in code so that people can
test it, but only after you're fairly confident that it's not
broken in an obvious way.  I try very hard to avoid regressions.
CVS-HEAD was never a tree you were allowed to break. 

   If people want to break things, that belongs in another branch.


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

   I think most parts of the tree correspond to people who are obvious
experts.  Many of these people are the recognized maintainers, though
some of them don't have CVS access.  That, in my opinion, should
be remedied.  


			Mark.