[forum] Re: [XFree86] Invitation for public discussion about the future of X

[Keith Whitwell]

Alan Hourihane wrote:
> On Thu, Mar 20, 2003 at 11:37:34 +0000, Keith Whitwell wrote:
> 
>>XFree86 BOD wrote:
>>
>>
>>>It has been brought to the attention of the XFree86 Core Team that one
>>>of its members, Keith Packard, has been actively (but privately) seeking
>>>out support for a fork of XFree86 that would be led by himself.  He is
>>>also in the process of forming a by-invitation-only group of vested
>>>interests to discuss privately concerns he has about XFree86 and the
>>>future of X.  He has consistently refused to even disclose these concerns
>>>within the context of the XFree86 Core Team, which makes his membership
>>>of that team unviable.  As a consequence, Keith Packard is no longer a
>>>member of the XFree86 Core Team.
>>
>>What specifically does the XFree86 bod see as being wrong with the idea of 
>>a 'by-invitation-only group' managing X server development?  Isn't that 
>>exactly what the core team & xfree86 BOD have been doing all along?
> 
>  
> Not exactly. Long ago, that was probably right, but these days you
> could probably see the Core Team as a bunch of committers to the CVS,
> obviously with their own areas of technical knowledge as well.
> And yes, we've met on occasion, but more in the reality of a coding
> frenzy to work on what we wanted to work on. 

It's a spin thing.  "Core team" sounds exclusionary, where as "Developers who 
have been granted CVS access" sounds pretty inclusive...  and even more 
inclusive if there is regular induction of developers into that group.

> More recently to talk about
> XFree86 5.0, of which I've sent what I wrote down to this list already.

Doesn't this contradict your assertion that you're just a bunch of committers? 
  Yes, I appreciate your post today, but would it (or the openness post) have 
happened if keithp was still a happy core teamer?

> As for the BOD list, the Core Team doesn't know what goes on within that
> list either, not that it bothers me at all.

I wonder what the BOD is for.  It could be clearer.

>>Maybe the core team & bod could explain what is being hinted as a new 
>>spirit of openness and how that is proposed to effect the XFree86 
>>development process and strategy?  Will it mean forinstance an end to the 
>>sort of behind-closed-doors discussions that appear to have lead to this 
>>announcement?
> 
> 
> You'd be surprised if you saw what is actually discussed on the Core Team
> lists. Not much at all, apart from recent events that led up to this email.
> I have to say, that a lot of the Core Team is still in the dark on why
> Keith decided to divert his attention away from XFree86 in the way that
> has transpired. We're as much in the dark as you Keith Whitwell (thought I'd
> better add your surname to avoid confusion).

It's hard to see that keithp was unhappy about cvs access as he obviously had 
it himself.  Similarly he would have been privy at least to the core team 
masonic plotting, so that wouldn't have been a big issue for him either.

I have to wonder if it was he who originated the idea of a split, or whether 
he was approached by the evil, frustrated "vested interests" and asked to lead 
a more responsive fork, that would allow them to expand the pool of committers 
more easily.  From mharris' diary, I wouldn't be suprised - although it 
doesn't seem like he personally had any knowledge of a coming fork.

It's hard to see what other issues there are: cvs access, maybe personality, 
what else?  The broad direction of the project, but what does that mean?


[snip]


> 
>>OK - some concrete proposals, with cynicism turned off:
>>	- Make BOD minutes public
> 
> 
> That would be good, if I knew there were any minutes, which I don't think
> there are.

There should be.  I believe it's mandatory for minutes to be kept of such 
meetings.

> 
>>	- Open all core team meetings to the public, and if feasible post 
>>	minutes, transcripts or even audio feeds.
> 
> 
> As for my 'XFree86 5.0 TODO' email, that's what was intentional.

I recognize the intention, and appreciate what you're doing.

> 
>>	- Extend CVS access to regular contributors.  Use scripts or 
>>	whatever to control access to subtrees if you want.
> 
> 
> This comes up from time to time, and I'm sure will get discussed even more.
> I know there have been offers to others for CVS commit access, and some
> have refused and some have accepted. The consensus of who gets commit
> access has always been - if they show competance at sending patches in,
> then after a period of time, no doubt they'll get it. It's the same as
> the DRI, but with more of a prolonged period of evaluating that persons
> patches. I guess this 'prolonged' period, is the stickling point for most.

Who and when were the last 5 or so members of the core team admitted?  Or 
should I say:  who & when were the last 5 people granted cvs access?  (It's so 
much less threatening that way).  Who decided?

To take an example from thin air...  mharris has been working on xfree for 
yonks - years, I'm sure - afaik dilligently & responsibly - when should he 
expect cvs access?   Will it still be useful to him by then?


> 
>>	- Consider dropping the BOD and core team ideas in favour of an 
>>	elected committee.  Examine recent trends in managing other large projects.
> 
> 
> As I mentioned above, think of the current Core Team, as a bunch of committers
> that review what comes into the various fixes/patches lists. Then extend
> the Core Team to specialized areas too in which they were forseen, and as
> such were granted CVS access. If the community see these teams as closed
> groups, then like you say, we disband these groups, or try and put out
> a better explanation of what they mean.

Well, there does have to be a finite group of people with commit access.  What 
it must boil down to is who decides who gets it & how easy it is is for a 
responsible developer to get it.

That said, there is a definite perception of these groups as closed and 
entrenched.

BOD elections and a much more open CVS access policy would be two excellent 
steps in the right direction.  I enjoyed reading a few of the debian policy 
papers -- even though I have nothing to do with debian & dont use it.

>>Just generally get down off your high horses and accept that the developers 
>>out there won't wreck xfree86 if you let them participate & accept them as 
>>equals...
> 
> 
> I understand this point, and it comes down to the fact that there still
> needs to be some level of control of who gets commit access, just like
> any other open source project. It's probably not moving quick enough for
> some though. 

Ah, Alan - you're very tactful, I definitely appreciate your not taking my 
flamebait as provocation...

Anyway - CVS access has to be timely to be useful.  There's no point offering 
it to someone who's given up on XFree & gone on to something else in frustration.


>>Of course, if xfree starts accepting more developers, it will make it 
>>harder for us in the dri tree as we tend to benefit from xfree's 
>>exclusionary practices -- developers find it easier to get cvs access for 
>>DRI than XFree86, so we pick up some talented developers that get fed up of 
>>waiting for patches to be applied to xfree cvs.  But then again, what is 
>>the dri tree but a friendly fork to workaround for xfree's closed 
>>development methodology?  If xfree really opened itself up, the first thing 
>>they'd do is extend an invitation to merge with the dri project, right?  
>>Maybe that's the acid test, or maybe it's whether we'd accept...
> 
> 
> Then shut up, if you don't want your DRI developers nicked :0) Only kidding.

 From my selfish point of view, an XFree fork will put the DRI tree in a bit 
of a difficult position - especially if the new fork gets significant distro 
support and we have to somehow track both trees or go through yet another 
merge step to get our code out to the world.

Keith