[forum] XFree86's Future and thoughts and suggestions

[David Dawes]

On Tue, Apr 01, 2003 at 04:29:10PM -0500, Mark Vojkovich wrote:
>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.  

I think that there are lots of parts of the tree for which there
are no people that have the three necessary things to be maintainers:

   1. they are very knowledgable in the area
   2. they can make the time/resources commitment to be effective
   3. they are committed to the general goals and integrity of XFree86

Some of these areas are probably stable enough that they don't need
dedicated maintainers.  Others do.  You mentioned input devices
before.  That's an area that could use an expert with a lot of
spare time.  If there's someone with experience in the broad input
handling area, and the necessary spare time who'd like to take this
on, then they should step forward.

As it stands now, we have maintainers for some areas that have all
but the second requirement.  The result is that there are those
who are dissatisfied with how quickly submissions for those areas
are handled.  That's why that requirement is essential to really
deal with the problem of getting stuff reviewed and integrated
quickly and correctly.

Anyway, I'd like to see a breakdown of the source tree, with
prospective maintainer's names attached, and preferably buy-in from
those nominated.  I've contacted a range of people recently, and
in the past.  Some have accepted the responsibility, some have
declined either because of lack of time, or because they don't want
to be the target of "community" negativity if they don't live up to
the vocal minority's expectations.  Yet others have said that they
would accept only on the condition that they have free reign
thoughout the source tree.  I guess the Linux kernel's system
short-circuits the last response by having a three level system
rather than the two level system being proposed here.

The only alternatives to the maintainer system that I can see are
the current system (with a more active set of committers) which is
effectively a partial maintainer system, and a fully open system.
I think the trade-offs should be obvious.

Speaking for myself.

David