xorg ports roadmap?

[Robert Noland]

On Sat, 2009-11-28 at 13:26 -0800, vehemens wrote:
> On Saturday 28 November 2009 10:02:04 Robert Noland wrote:
> > On Fri, 2009-11-27 at 16:01 -0800, vehemens wrote:
> > > On Friday 27 November 2009 12:53:35 Peter Jeremy wrote:
> > > > On 2009-Nov-26 14:55:40 -0800, vehemens <vehemens at verizon.net> wrote:
> > > > >If your having so many problems with these updates, why not just split
> > > > > ports into current and stable branches?
> > > >
> > > > This isn't as easy as it sounds because there are interactions between
> > > > so many different pieces.  Back when X.org/XFree86 was a small number
> > > > of ports (basically server, libraries and base clients), it wouldn't
> > > > have been too hard.  X.org now comprises something like 250 pieces
> > > > with not-very-well documented interactions.
> > > >
> > > > It might help if X.org could be cleanly split into client ports and
> > > > server ports but even that's not possible because they both depend
> > > > on a number of X-related libraries.
> > >
> > > The suggestion was to have the entire ports tree as both a current and
> > > stable branch, then using the same (similar?) rules as used for the
> > > source branches.
> > >
> > > A ports freeze would mean that changes to the stable branch would be
> > > limited, but work could still go on in the current branch.
> > >
> > > The MFC process could be semi-automated.
> >
> > This is hard enough to manage in src for one -CURRENT and 2/3 stable
> > branches... Ports would be insanity and would in no way help to address
> > the current issues or reduce the amount of work needed to get things
> > done.
> 
> You stated in a several earlier emails that you are having problems such as: a 
> lengthy TODO list, complaints with ports breakage, coordination of multiple 
> efforts to name a few.
> 
> If you have a better suggestion, then please make it as we would all like to 
> hear it.

Attempting to maintain 2 branches, close to doubles the amount of work
needed to get things done.  Not only for me, but also for portmgr@ if it
existed in any sort of official capacity.  Having a repo setup which
would more readily allow others to work on major updates could help,
though I don't get a lot of offers in this regard other than people
willing to test.  The current difficulty with updating is due to Intel
and nouveau dropping support for kernel configurations without GEM/TTM.
GEM/TTM are non-trivial to port into the kernel, although I do have WIP
on both, there is no ETA.

For nouveau, that means that an older version of libdrm will be needed,
which will have to conflict with the current version.  That just kinda
makes my skin crawl, since I really despise conflicting ports to begin
with and the dependecy management gets overly complicated.

For Intel, going beyond the 2.7 DDX driver, doesn't support drm without
GEM.  The current 2.7.1 driver doesn't build against 1.7.1/2 server.
So, either the existing Intel driver has to be fixed to work with the
new server, or we import the 2.9 series and lose drm support.  Were we
to do both, again we have conflicts, but since the drivers are leaf
ports, the dependency management isn't such an issue.

On top of all of this... When I do merge updates into ports, I have to
be prepared for a few weeks of solid front line support issues, since
few people seem to be interested in stepping up to help others with
basic support issues.  (Adam Kirchoff and Warren Block come to mind, but
not many others)

robert.

> 
> 
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD