On Thu, Mar 20, 2003 at 04:08:06 +0000, Keith Whitwell wrote: > 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. Right, it's definately a 'spin thing'.
> >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? Not really. We met in New York, as it was convienient for all. We had decided to talk about what to do for 5.0 but only to get the ball rolling. It doesn't mean that excludes others. In a project such as this, it's sometimes easier to get some preliminary information about what others are thinking to do to spark ideas with the rest of the community. Keith Packard was at that meeting to discuss his ideas from the people he'd been talking to. So it was more of a bringing together of what the individuals on the Core Team had heard about what is needed by the X world. And I'd of still posted the document - but probably to devel@ rather than the new forum@ list. > >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. Money matters, incorporating the 'free' company in the US etc. More managerial stuff is what it means to me. > >>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? I'd welcome comments from Keith Packard here. I'm sure we'd love to get back on track and avoid a split as much as possible. > >>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. I'll leave the BOD to answer this one. > >> - 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. O.k. > >> - 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? I believe David has sent emails recently to a few. David may be able to comment more on their acceptance or rejection. I will say though, that there are certain areas of X that go completely untouched, like XInput. I'm sure if someone showed prowess in this field, they'd definately get commit access. > 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? Wow, this is a sore point, I'll try to be diplomatic, but Mike - I'm not trying to upset you, it's just the way I currently see it. Here goes.... I know Mike would love to have CVS access, but his reviewing of patches in the past have been somewhat questionable as to their fitting for the purpose as to be the 'correct' way to fix the problem. It's a two way street. If Mike spends more time reviewing the patch that he sends in, rather than blind copying from the devel@ lists then he may be seen as taking a more investigative approach into fixing issues and given CVS access. Yes, I understand we all make mistakes, but a more detailed review would be nice. And Mike, yes, some of your patches are o.k. too, but the percentage could be higher. > >> - 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. Right. That process probably needs to be made more clear. > That said, there is a definite perception of these groups as closed and > entrenched. Then we need to dissolve that perception then. > 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... Never. > 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. Right, and we're back to the Core Team. The people currently on it, have been around for quite a few years and have stuck like glue to the project. That's invaluable. > >>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. Indeed. Alan. ------------------------------------------------------- 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
