From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev-return-4046-arch-gentoo-dev=gentoo.org@gentoo.org> Received: (qmail 6432 invoked by uid 1002); 25 Jun 2003 17:42:28 -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 17468 invoked from network); 25 Jun 2003 17:42:27 -0000 From: Tony Clark <tclark@telia.com> To: gentoo-dev@gentoo.org Date: Wed, 25 Jun 2003 19:42:26 +0200 User-Agent: KMail/1.5.2 References: <20030625013328.GA10762@inventor.gentoo.org> <200306250726.32233.tclark@telia.com> <20030625054738.GA28336@cerberus.oppresses.us> In-Reply-To: <20030625054738.GA28336@cerberus.oppresses.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306251942.26436.tclark@telia.com> Subject: Re: [gentoo-dev] *IMPORTANT* top-level management structure! X-Archives-Salt: ad12739a-656c-4694-a076-0672597e7083 X-Archives-Hash: 4ed143e1b9bdec4ca09b2c801cace223 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. :) > > That's not too many for an August deadline: I'm not sure where you got > that idea. They'll be ready at the same time because it makes sense for > them to be ready at the same time to have a uniform release. There is no > reason _not_ to release them at the same time. Great but not visible. > > If a specific arch leads decides they're not ready for a 1.4 release, > they won't be released. I'm not going to mandate that archs that aren't > ready have a release, but I'm not going to refuse to release what's > ready, either. Your the release guy, your call seems reasonable. > > Marketinng Dept? We have nothing to gain from 'marketing' except for > providing a superior product to users. I am sorry that providing a > superior product to users and attempting to avoid any inconvienence to > users does not fit with what you would like. I am not willing to push > gcc 3.3 yet because it breaks for a lot of people; I am not willing to > push openssl 0.9.7 out of package.mask because many people will have > broken systems without a better upgrade path. I am sorry that you do not > understand QA. Talk about the pot calling the kettle black. You can't point to 1 record that confirms anything your designing. I have been a designer for ISO9001 approved companies for the last 10 years, before that to Mil and other telecom standards, please give me a break. > > > > > These are just really fundementals but until the requirements are > > > > documented things will never really come together. > > > > > > > > Get things out in the open. Gentoo-core is probably the worst idea > > > > someone ever came up with, OSS development is meant to be a very > > > > transparent process. Make it transparent. I know there are always > > > > private issues but if they involve more than 3 people then perhaps > > > > they should be public. > > > > > > We are making it transparent by discussing development on gentoo-dev. > > > > Don't tell me, someone woke up this morning and formed a new management > > structure, honest :) You know you need this transparent as it is the > > only hope of it getting done in time. It's not a big deal for me > > actually, it's just that of ppl where primed and ready for the > > announcement you would be more than halfway towards meeting the > > objectives. > > Can you explain what you mean here? Getting what done > in time? Which announcement? Which objectives? Your asking me? Shit I'm not running the project, your meant to know all those answers. > > > Anyway, from another comment it is impossible to define goals for Gentoo > > therefore I would submit it is impossible to have a 1.4 release. I have > > no problems with that, marketing probably does though. > > Now you're really grasping at straws. Can you tell me which comment says > that it's impossible to define goals for Gentoo? Can you point to any document that defines Gentoo 1.4? > > What marketing? The fact that I said that it'd be nice to have something > to hand out on CDs to people for LWESF so they can go home and install > Gentoo suddenly means everything we do is based on marketing? Ecveryone has marketing whether they know it or not. You just described a part of marketing. > > I apologize for all of us for trying to provide you, the users, with a > superior product, good QA, and convienent upgrades. I think it is already established that you have no QA in the design sense. Bugs are handled pretty well, product is good, ego is a little on the high side, so in general thanks for a job well done. Hey QA ain't everything, I'm the first to admit that, I'm just happy Gentoo is QAed to death like debian. tony -- Contract ASIC and FPGA design. Telephone +46 702 894 667 http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x633E2623 -- gentoo-dev@gentoo.org mailing list