From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17367 invoked by uid 1002); 15 Jul 2003 11:40:53 -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 13810 invoked from network); 15 Jul 2003 11:40:52 -0000 From: Paul de Vrieze To: gentoo-dev@gentoo.org Date: Tue, 15 Jul 2003 13:40:47 +0200 User-Agent: KMail/1.5.2 References: <20030714214621.33b75fbd.zhen@gentoo.org> <200307151106.10407.pauldv@gentoo.org> <20030715053742.I12388@sigint.cs.purdue.edu> In-Reply-To: <20030715053742.I12388@sigint.cs.purdue.edu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_/g+E/Fpq8L4kZ23"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200307151340.47839.pauldv@gentoo.org> X-Spam-Status: No, hits=-5.1 required=5.0 X-Spam-Level: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Subject: Re: [gentoo-dev] Gentoo part II. X-Archives-Salt: a1ca93c6-a08b-40f4-9c7e-6b483b93d03c X-Archives-Hash: 166dae905f4a97a3b0b3482691984d4c --Boundary-02=_/g+E/Fpq8L4kZ23 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Tuesday 15 July 2003 12:37, splite wrote: > On Tue, Jul 15, 2003 at 11:06:09AM +0200, Paul de Vrieze wrote: > Content-Description: signed data > > > developers for gentoo. Having a single "boss", and a "lieutenant" with = no > > structure at all is not going to work. Especially as the amount of > > developers grows. > > Works for the Linux kernel. Why do you need more developers? Does every > package in the universe have to end up in the portage tree, with its own > developer? I'm quite serious. Just because someone cobbles up an ebuild > for whatever obscure package, does it have to go in? Well, Linus has more then one luitennant. And those luitennants also have=20 their own sergeants etc. The kernel development process is surely structure= d.=20 It has local responsibilities just as gentoo is going to have. > > > We need structure. > > You have structure now. Why make it a full-blown bureaucracy? No, we don't (well didn't, as we are trying to set it up now) > > > Part of that structure is a place where things are documented, like > > responsibilities. > > You already have a place for documentation. We need developer-developer documentation, and indeed we have a place for i= t.=20 Having a place though, does not make that it doesn't need to get written. > > > The problem is that with 30 developers you could easilly ask something > > you didn't know. Now the problem is that you can still ask, but you don= 't > > know who to ask. Documenting procedure and formalizing a bit should hel= p. > > What's wrong with giving a shout-out to gentoo-dev? I'd rather see someo= ne > documenting Portage better (say, "how SLOTs work"), than documenting > procedures for asking questions. > We are not documenting procedures at all, or aiming to. We are documenting = who=20 does what, so we can see the gaps and overlaps. > > There are also many people and organizations that want gentoo to run on > > their servers. Those people have one thing they REALLY REALLY hate, and > > that is comming to office in the morning and finding out that the night= ly > > world update fucked up their setup, and it will take at least until the > > end of the > > Then those people shouldn't be idiots. Seriously, who in their right mind > runs automated nightly updates on production systems? Run them on a test > machine, then if things look okay afterward, push it out to the production > boxes. That's common sense. > Of course they don't do that, but there are contacts with corporations that= do=20 want to use gentoo because they like its structure, but don't like the movi= ng=20 target nature of the tree. The idea is to create releases to suit those=20 users. Those releases then only receive security fixes and major bug fixes. > > morning fixing things up. Normally such thing will mean a great loss of > > productivity. > > Then they should be paying Red Hat or SuSE for support. Folks, you're > not responsible for someone being dumb enough to let their systems be > borked nightly. In fact, if you start acting like you are, you may > well find someone trying to hold you to it in court. > Of course no smart person does a nightly update on a production system. The= y=20 just want MORE stability. > > Since we believe that the gentoo technology is better than the > > competition, > > Gentoo tech is quite nice, but it doesn't have to be all things to all > people. > I didn't say it is perfect, I said that it is better than competition for t= he=20 area's we care about. > > even for servers we want to offer what they want while keeping what we > > have. > > If they want a system that's flexible and easy to fix and customize, > Gentoo's great. If they want guaranteed uptime, they should buy a > commercial distro and a service contract. > No OS vendor guarantees uptime as there are too many untracable causes for= =20 crashes. Many of them hardware (or position of the moon) related. > > For offering what is needed for servers we do need more quality > > assurance. > > I hate to keep bringing up Debian, but it's a perfect example. Their > desire for QA has brought the project to a virtual standstill. Even given > the huge number of Debian Developers, they can't validate all 10,000+ > packages on the 11 architectures they support in any timely fashion. > That's why they're taking years between releases now. > > As long as Gentoo keeps being "good enough", it will have users. As long > as its developers take pride and derive enjoyment from working on it, > Gentoo will be good enough. You don't need Quality Assurance committees > drawing up charts and setting milestones. If you want to set a release > date, just pick one, Bach's birthday, whatever. Ship whatever you have > on that date; it's still bound to be better than Debian or Red Hat, even > with all their QA aparatus. There is no final decision on QA yet, but the idea is to pick a date, say=20 Bach's birthday, then do a fixed period of testing and fixing (coming from = a=20 stable branch that should have no bugs anyway), then release. > > > With QA and the growth of the project comes a management structure. That > > Any "project" has a management structure, by definition. If the present > structure can't keep up with growth, another possibility is to check the > growth. No growth implies a change of the structure. We are currently in that proce= ss.=20 And indeed we do check growth rates with our ability to manage it. > > > structure is inevitable. John made a proposal on how to arange parts of > > that structure. While we will put every effort in it not to create a new > > debian, we need to be more organized than before. > > That's appreciated, but I and a few others think he went over the top. > Debian is not the model to emulate. I wouldn't even try to make a "fixed" > version. Maybe Gentoo should stick to its founding spirit and come up > with something different. > I never said I agree with everything that John said.=20 > > So please all discuss the merrits of his proposals. I believe that the > > problems they try to address are there and are well accepted. > > I don't think the actual problems have really been discussed, at least > not here. As I asked before, whose needs aren't being met here? Simply > stating "we need structure" like it's axiomatic isn't an argument. If the > developers are having fun, and the users are getting something useful (and > for free), why isn't that sufficient? > Because we want to be better tomorrow than we are today. Gentoo is not=20 perfect, and probably newer will be, but we can aim towards it. For gentoo= =20 developing to stay fun, developers must keep the feeling that their ideas a= re=20 being considered. Any good idea that stays in a developers/users private=20 overlay is basically a waste. Today that happens too often because of certa= in=20 chokepoints. Paul =2D-=20 Paul de Vrieze Researcher Mail: pauldv@cs.kun.nl Homepage: http://www.devrieze.net --Boundary-02=_/g+E/Fpq8L4kZ23 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/E+g/bKx5DBjWFdsRAhtdAKDjiIGILGadwaGf1Ri46Z/8etheBACfcobQ lt3td5/jiFEwq2eMNAWMueQ= =QiA4 -----END PGP SIGNATURE----- --Boundary-02=_/g+E/Fpq8L4kZ23--