From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5606 invoked by uid 1002); 3 Oct 2003 15:34:41 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 31318 invoked from network); 3 Oct 2003 15:34:40 -0000 From: Brian Jackson Organization: Gentoo Linux To: gentoo-dev@gentoo.org Date: Fri, 3 Oct 2003 10:34:38 -0500 User-Agent: KMail/1.5.9 References: <3F7D4315.1020900@gentoo.org> In-Reply-To: <3F7D4315.1020900@gentoo.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200310031034.39985.iggy@gentoo.org> Subject: Re: [gentoo-dev] Speaking of new kernels being added to the tree X-Archives-Salt: 3e7af71b-1523-4618-a97e-2af963f745ee X-Archives-Hash: 41a5fc7a57608323e13f9eff283a2c22 On Friday 03 October 2003 04:36 am, Brad Laue wrote: > Just reading the suse-sources thread - good idea, but I have a > suggestion first. > > I think we should wait on the inclusion of anything kernel related into > the CVS tree until some more thought is put into how we're managing our > kernel sources. That is the plan. > > The kernel team seems to be both the smallest and most behind the times, > and this is sad given that they're one of the most important teams > involved in the project. We're two kernel versions behind (and don't > justify that by claiming 2.4.21 or 2.4.22 had bugs, that doesn't fly), > and show no signs of making it to a 2.4.23 release. The team is behind the times or the releases are ;) Seriously though, we are definitely in need of more people, and things are likely to continue to be slow until there are mroe people working on stuff. > > The kernel team needs more people. It needs to drastically reduce the > number of kernels in the tree which are of a customized nature > (xfs-sources, gs-sources, wolk-sources) until it can manage > gentoo-sources in a timely fashion. The kernel team needs to build a > subset of patches which form the core of the gentoo kernel. They then > need to enable all the additional features provided by xfs-sources, > wolk-sources and gs-sources on a per-use-flag basis, rather than having > three kernels to manage, each with three different sets of incompatible > patches. There obviously aren't enough resources to manage this. There will probably be a few -sources removed. But the decision of what is not made yet. > > Optionalizing features through the use of USE flags only makes sense. > This is how all other things are done in Gentoo. I don't have nor do I > intend to create six mozilla ports based on all the different sets of > potentially incompatible USE flags present in the one ebuild, because to > do so would make it impossible to manage. Why is the kernel any > different? Why do many different people manage their own patchsets > without collaborating and sharing resources to keep our official one up > to date? USE flags is a bad way to do things, lets say you have 116 patches (the latest pfeifer-sources does). If the 32nd patch is optional based on a use flag, it could take away parts that a later patch relies on, which would make the entire patchset fail. Now obviously this has been working since the current gentoo-sources and older pfeifer-sources does this, but it only works because all the patches have to be specially diffed in just the right order. At present time we don't have the manpower to do this. > > Brad. > On Friday 03 October 2003 04:54 am, Brad Laue wrote: > Just to clarify the above with regard to xfs-sources, wolk-sources et > al, rob in #gentoo-dev suggested that a wolk USE flag would collide with > a number of gentoo-sources patches. These USE flags would be architected > in such a way that enabling 'wolk' would work around such conflicts. actually if you applied the wolk patch, probably none of the gentoo-sources patches would apply. Not to mention that currently wolk and gentoo-sources are based on the same KV, but hopefully won't be for long. > > Many ebuilds do this; if a USE flag enables a feature with which another > feature conflicts, the other feature must be disabled to compensate - > shouldn't be much of a logistical problem. the many individual patch nature of -sources makes them unlike any other ebuild out there (not that I'm saying mozilla isn't a beast itself), many patches can touch the same 4 lines of the same file, which if the first one fails or isn't applied everything goes down hill from there. --iggy > > Hope that clears that issue up, > Brad > > -- > gentoo-dev@gentoo.org mailing list > > -- Home -- http://www.brianandsara.net Gentoo -- http://gentoo.brianandsara.net -- gentoo-dev@gentoo.org mailing list