From owner-freebsd-x11@FreeBSD.ORG Sat Nov 28 21:59:38 2009 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04074106566B for ; Sat, 28 Nov 2009 21:59:38 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id BD82E8FC12 for ; Sat, 28 Nov 2009 21:59:37 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-218-170.ard.bellsouth.net [72.154.218.170]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id nASLxV4w019164 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 28 Nov 2009 16:59:33 -0500 (EST) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: vehemens In-Reply-To: <200911281326.35064.vehemens@verizon.net> References: <200911271601.47677.vehemens@verizon.net> <1259431324.2315.14.camel@balrog.2hip.net> <200911281326.35064.vehemens@verizon.net> Content-Type: text/plain Organization: FreeBSD Date: Sat, 28 Nov 2009 15:59:25 -0600 Message-Id: <1259445565.2315.53.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-x11@freebsd.org Subject: Re: xorg ports roadmap? X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 21:59:38 -0000 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 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 FreeBSD