Date: Sat, 28 Nov 2009 15:44:31 -0800 From: vehemens <vehemens@verizon.net> To: Robert Noland <rnoland@freebsd.org> Cc: freebsd-x11@freebsd.org Subject: Re: xorg ports roadmap? Message-ID: <200911281544.31444.vehemens@verizon.net> In-Reply-To: <1259445565.2315.53.camel@balrog.2hip.net> References: <d873d5be0911091618s106d2a09ub4845e75cd5876a2@mail.gmail.com> <200911281326.35064.vehemens@verizon.net> <1259445565.2315.53.camel@balrog.2hip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200911281544.31444.vehemens>