New Release Manager (Was: Status of xserver/debrix/modular tree?)

[Shawn Starr]

Bernardo, it takes time.  I plan on helping to work on the debrix tree now 
because it's were we're moving towards.

We got the wiki updated cause I asked Daniel about the steps on IRC (you 
should come online if you're not on already to discuss things real time).

Release Management is nice, but DebriX needs people to actively help get it up 
to date.

Though I agree, knowing what X server components debrix needs would be nice. 
We know Xprint is outta here! 

ajax: Care you mention what else needs to be ripped out? :)

Shawn.

On February 20, 2005 19:18, Daniel Stone wrote:
> On Mon, Feb 21, 2005 at 12:57:52AM +0100, Bernardo Innocenti wrote:
> > Daniel Stone wrote:
> > >What specifically do you want to find out that's not already avaialble,
> > >given the general consensus that 7.0 will be a fully modular release?
> >
> > Well, a good release plan should say which components willR
> > be present in the modular tree, list the tasks that needs
> > to be done and assign people to specific tasks.
> >
> > Developers would then know better what they should do.
> > Collecting feedback would help the RM sketching a
> > somewhat realistic schedule.
> >
> > By the way, has the RM issue been discussed at the Xdevcon?
> > There's no discussion here in the list.  The only thing I
> > know is that Adam Jackson volunteered and Michel daenzer
> > supported him.  Nobody else replied.
>
> The people who would work on the modular tree are, by and large, already
> working on the modular tree.
>
> > >Again, a lot of this has to do with the fact that we're woefully
> > >undermanned, so the loss of one contributor can totally cripple an
> > >entire portion of the project.  If we lost Roland Mainz, Xprint would
> > >fall apart.  If we lost Egbert Eich, I get the feeling int10 would
> > >disintegrate.  The nVidia driver is done entirely by Mark Vojkovitch,
> > >with Alan Coopersmith constantly playing with merges there.  The
> > >Radeon display detection stuff depends almost entirely on Ben
> > >Herrenschmidt.  And so on, and so forth.
> > >
> > >The problem is that if one person disappears or gets unavoidably busy,
> > >then entire chunks of the project can just fall off in terms of
> > >development.  Witness the current situation with debrix, where the code
> > >is lagging badly behind.
> >
> > That's sad.  A project as visible and critical as Xorg should
> > have hackers lining up to join.
>
> You keep telling us this, but we already know it.
>
> > Have you read this Slashdot story?
> >
> > 
> > http://linux.slashdot.org/article.pl?sid=05/02/16/1916250&tid=104&tid=189
> >&tid=106&threshold=5
>
> I read Seth's blog; I assume that's what the story is about.
>
> > Sounds like Seth Nickell and other Red Hat hackers are
> > working on interesting stuff.  Maybe we should get in contact
> > with them to see if their ongoing efforts could be coordinated
> > here in the xorg mailing-list?
>
> Er, you do realise that krh, Søren, and others are active on this list,
> and that krh, Owen, Søren and Diana gave a presentation on this at XDC?
>
> > >Maybe it already works, but my understanding that even accelerated
> > >direct was not possible if you built the monolithic tree without
> > >any of the Mesa bits, and then built Mesa out-of-tree.
> >
> > I've built Xorg with the in-tree copy of Mesa (it doesn't build
> > with the current CVS version).
> >
> > Then I've built Mesa and installed it over the old libraries
> > (libGL, libGLU, r200_dri.so).  Works great.
>
> Right.  If you compiled Xorg *without* Mesa being built at the same
> time, this would be useless.