From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32685 invoked by alias); 8 Jan 2003 22:41:17 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 32660 invoked from network); 8 Jan 2003 22:41:16 -0000 `To: jifl@eCosCentric.com Cc: wpd@delcomsys.com, ecos-maintainers@sources.redhat.com In-reply-to: <3E1C4230.2020308@eCosCentric.com> (message from Jonathan Larmour on Wed, 08 Jan 2003 15:22:24 +0000) Subject: Re: OMAP RedBoot port From: Bart Veer References: <3E1C4230.2020308@eCosCentric.com> Message-Id: <20030108222802.C24C9616CB@delenn.bartv.net> Date: Wed, 08 Jan 2003 22:41:00 -0000 X-SW-Source: 2003-01/txt/msg00005.txt.bz2 >>>>> "Jifl" == Jonathan Larmour writes: >> 3) Create an official "package" of the new files and place that >> on Delphi's ftp server. I have a document somewhere around here >> that describes how to do that. (Did that idea ever catch on -- >> do people distribute independent packages?) Jifl> They do _if_ it's not going in the master repo. Although out Jifl> of interest in eCos 2.1 eventually, eCos is likely only to Jifl> be distributed as EPK packages! >> 4) Request write access to the CVS repository so that I may >> commit the changes myself. >> >> Obviously, I am exploring option #4 right now, but I would >> welcome questions, comments, and/or snide remarks on the other >> three options. Jifl> This is an interesting point. So far we've restricted write Jifl> access to (full) maintainers only. I would be interested in Jifl> other maintainer's views on whether we should open this up Jifl> more freely now, in the same way as GCC, GDB etc. where Jifl> package maintainers are allowed to check stuff in for their Jifl> own packages. This wouldn't be the same as a full maintainer Jifl> - it's purely an efficiency improvement. Jifl> We would also, like GCC/GDB, have a top level MAINTAINERS Jifl> file listing the responsibilities. Package maintainers would Jifl> be able to commit directly to their "own" packages without Jifl> waiting for approval. They can check in patches for other Jifl> packages too if they like, but only with approval. *All* Jifl> patches must go to ecos-patches in any case. Jifl> Comments? eCos is rather more package-oriented than gcc or gdb. We could end up with a very large number of maintainers, most of them responsible for only one or a small number of packages. Each maintainer is a potential source of security problems, e.g. compromised ssh keys. In an EPK-based system, it might make more sense to reduce the importance of anoncvs. All the core packages would still go into anoncvs, of course, but new ports and device drivers could instead be provided only as EPK's. Releasing a new version would involve generating a new EPK, putting it on sources.redhat.com in a write-only incoming ftp directory, and then moving them to somewhere more public. The latter could be done by a cron job or a script, possible with a certain amount of validation by a human. A useful side effect would be to keep down the size of the anoncvs tree itself: ports and device drivers already account for a large proportion of the tree, and most users are only interested in a small number of targets. In that scenario, it might be better to stick with a small number of people with write access. Bart