Date: Sat, 28 Nov 2009 17:00:17 -0600 From: Robert Noland <rnoland@FreeBSD.org> To: vehemens <vehemens@verizon.net> Cc: freebsd-x11@freebsd.org Subject: Re: xorg ports roadmap? Message-ID: <1259449217.2315.62.camel@balrog.2hip.net> In-Reply-To: <200911281544.31444.vehemens@verizon.net> References: <d873d5be0911091618s106d2a09ub4845e75cd5876a2@mail.gmail.com> <200911281326.35064.vehemens@verizon.net> <1259445565.2315.53.camel@balrog.2hip.net> <200911281544.31444.vehemens@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2009-11-28 at 15:44 -0800, vehemens wrote: > On Saturday 28 November 2009 13:59:25 Robert Noland wrote: > > 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@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. > > Could you publish the WIP? While I wouldn't mind sharing it... It is in no way usable yet, I'm not sure if my GEM branch is currently buildable even and the TTM branch is mostly just driver stubs at this point, since radeon and nouveau will need a GEM api + TTM. I know that I've mentioned it in some contexts... but I use git for the kernel tree with lots of branches... Lately, I've been working on ZFS boot issues and so have been a bit distracted from some of this. I do finally have via hardware of the appropriate vintage to use the via driver on the way, so hopefully I can wrap that up and import it soon. balrog% git branch chrome9 external gem intel master misc nouveau radeon * testing ttm via robert. -- Robert Noland <rnoland@FreeBSD.org> FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1259449217.2315.62.camel>