From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev-return-4049-arch-gentoo-dev=gentoo.org@gentoo.org> Received: (qmail 29533 invoked by uid 1002); 25 Jun 2003 18:52:14 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: <mailto:gentoo-dev@gentoo.org> List-Help: <mailto:gentoo-dev-help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev-unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev-subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 24960 invoked from network); 25 Jun 2003 18:52:14 -0000 To: gentoo-dev@gentoo.org References: <20030625013328.GA10762@inventor.gentoo.org> <200306250726.32233.tclark@telia.com> <20030625054738.GA28336@cerberus.oppresses.us> <200306251942.26436.tclark@telia.com> From: Matthew Kennedy <mkennedy@gentoo.org> Date: Wed, 25 Jun 2003 13:48:12 -0500 In-Reply-To: <200306251942.26436.tclark@telia.com> (Tony Clark's message of "Wed, 25 Jun 2003 19:42:26 +0200") Message-ID: <87smpyq9hv.fsf@killr.ath.cx> User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [gentoo-dev] *IMPORTANT* top-level management structure! X-Archives-Salt: a476a25a-fa60-42d4-8d8f-5883448aede4 X-Archives-Hash: f8d1f8661592e83b111ed75f1f1185fb Tony Clark <tclark@telia.com> writes: > On Wednesday 25 June 2003 07.47, Jon Portnoy wrote: >> On Wed, Jun 25, 2003 at 07:26:32AM +0200, Tony Clark wrote: >> > On Wednesday 25 June 2003 06.04, Jon Portnoy wrote: >> > > On Wed, Jun 25, 2003 at 05:02:32AM +0200, Tony Clark wrote: >> > > > On Wednesday 25 June 2003 03.33, Daniel Robbins wrote: >> > > >> > > [snip] >> > > >> > > > 1. What is Gentoo 1.4. What it may have been intended to be in >> > > > January is probably not what it is going to be now. Before you >> > > > recruit all and sundry you have to define this as if it isn't defined >> > > > everything will fall down and chaos will return. Some basic things I >> > > > see is that it needs to be are: gcc3.3 based >> > > > glibc2.3.2 >> > > > openssl0.9.7 >> > > >> > > We can do this if you want to wait another couple of months. >> > > >> > > Unfortunately, there are some requests to have 1.4 ready for LWESF at >> > > the beginning of Augusy >> > >> > This is just classical, happens everyday type stuff in >> > electronics/software companies, espically ones who don't know what they >> > are building with clear goals. Marketing keeps moving the requirements >> > and dates aren't met. Some deadline finally gets set and a patch work >> > job happens to meet THE DATE. >> >> We know what we're building and have clear goals. Those goals have been >> specified on this list by Daniel in the past. > past day, week, month, year? He has had about 4 posts here in the last 6 > months. Why isn't the QA guy demanding a list of packages to be included? >> >> With minor exceptions, _those goals are met_. > > What exceptions? Why the sudden panic then? >> >> However, you're now suggesting _entirely new_ goals that _do not fit_ >> with the schedule already in mind. Marketing is irrelevant - a few >> people said "Do you think we'll be ready for LWESF?" and I said "Yes." I >> intend to follow up on that, now that our goals are either met or about >> to be met. There is no 'THE DATE' that we absolutely must adhere to. >> Instead, I'm telling you that there is no technical way we can go with >> gcc 3.3 and openssl 0.9.7 in stable keywords without waiting a >> significantly long period of time while work is done in those areas. > Now above you say there is a deadline and here you say there isn't. I can't > see how you can say I am describing new goals when you can't point me to a > document which states what the current goals are. There is no QA as noone > can trace a specification pass back to a specified requirement. I've > digressed into QA but thats actually what the total process should be about. > >> > > This is not viable. The tree is not gcc3.3-ready and OpenSSL 0.9.7 >> > > needs a much more mature upgrade path, otherwise there will be serious >> > > breakage (you need to remerge wget without ssl support, then merge the >> > > new openssl, then rebuild everything depending on it currently). >> > >> > The OpenSSL upgrade is really ready, it just that the whole tree needs a >> > rebuild which is time consumming. You have to break the cycle sooner or >> > later. Seems to me one solution is to release a binary version of 1.4 >> > build with the latest OpenSSL goes someway to ease that upgrade. Users >> > can get a >> >> Certainly, new stage1 and stage2 installs would have no problem - they >> haven't done an emerge system yet. A stage3 with openssl 0.9.7 would >> have no problem. Existing users or people using old stage3s would be >> screwed. We need a better upgrade path for that in order to avoid the >> kind of "patch work job" you described earlier. >> >> With regards to 'breaking the cycle,' we need functionality in Portage >> that either allows the ebuild to directly run revdep-rebuild or >> incorporate revdep-rebuild into Portage (or preferably real reverse >> dependencies, which will come in Portage 2.1 last I heard). > Ok, now this is good. All that is needed is to write these points down and > pretty soon you will end up with a requirement document that everyone can > understand, identify where they can be of most use and a check list you can > tick off when each thing is done. Now the project is managed! It really is > simple but because it is tedious, for a good designer, it is somewhat boring. > >> >> > working basic system maybe with kde and gnome desktops then add or >> > rebuild at their own pace. New takers have no problems as they are >> > current. GCC is a slightly different problem but not as large. I guess >> > it could be solved putting different versions of GCC in slots. Glibc is >> > pretty well there and doesn't seem to have any problems that I have >> > noticed. >> >> SLOTs are irrelevant to the GCC issue. The GCC issue is that the tree is >> not ready for it. Many applications will not build and there are many, >> many unsolved problems and weird issues that people can't track down. >> GCC 3.3 is not production ready and I, for one, am not interested in >> pushing people to release a broken compiler on the masses for the sake >> of saying "we're up to date!" - can you please justify pushing GCC 3.3 >> before it's ready? > > I don't need too. I'm not a gentoo developer, I just help where I can, when > I can. What you should be telling me is here is a url of the number of > packages that won't build with gcc3.3 in portage and here is another list > that we are not sure of. Have that in an easy to find location then things > can start to happen. It's all very well to say things are as broken as SCO's > kernel code but all I can say is, show me the list and I will see what I can > do to fix some of it. :) > Hi Tony, This is the list I've started to work off of: http://bugs.gentoo.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=gcc-3.3+gcc+3.3&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&remaction=run&namedcmd=everything+gcc3.1&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0= There's really only 14 open bugs, however I leave the closed ones in the list for historical interest. Jon, GCC will never be perfect. Like anything, there's always bugs, so I wouldn't stress out too much :) Matt -- Matthew Kennedy Gentoo Linux Developer -- gentoo-dev@gentoo.org mailing list