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
-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
