From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24278 invoked by alias); 11 Aug 2006 14:32:00 -0000 Received: (qmail 24270 invoked by uid 22791); 11 Aug 2006 14:31:59 -0000 X-Spam-Check-By: sourceware.org Received: from dns1-chi.paetec.net (HELO dns1-chi.paetec.net) (64.80.249.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Aug 2006 14:31:52 +0000 Received: from dtcsrvr09.dtccom.com ([66.153.88.146]) by dns1-chi.paetec.net (8.13.6/8.13.6) with ESMTP id k7BEVaj1020789; Fri, 11 Aug 2006 10:31:41 -0400 (EDT) Received: by dtcsrvr09.dtccom.com with Internet Mail Service (5.5.2658.3) id ; Fri, 11 Aug 2006 10:31:36 -0400 Message-ID: From: "Doyle, Patrick" To: =?iso-8859-1?Q?=27=D8yvind_Harboe=27?= , ecos-discuss@ecos.sourceware.org Date: Fri, 11 Aug 2006 14:32:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2658.3) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: RE: [ECOS] Splitting the eCos repository X-SW-Source: 2006-08/txt/msg00110.txt.bz2 > -----Original Message----- > From: =D8yvind Harboe [mailto:oyvind.harboe@zylin.com]=20 > Sent: Friday, August 11, 2006 5:24 AM > To: ecos-discuss@ecos.sourceware.org > Subject: [ECOS] Splitting the eCos repository >=20 >=20 > How about splitting the eCos repository? >=20 > - It would help to market the support for multiple repositories. I've > seen a lot of messy maintainence due to the lack of this knowledge. > - It would reduce the size of the eCos repository that 90% use. >=20 > Something like: >=20 > - eCos core. Up to and including architecture HAL's > - eCos devboard. Contains all the HAL's for development boards. > - eCos highlevel/net. All high level(many files) stuff like net, > microwindows, etc. goes > - eCos legacy. >=20 > 1 eCos repository is too little, 10 is too many. :-) I like it... As I said, we already do much the same here. One of the concerns I've had about the OMAP ports is to wonder what happens when they get committed to the repository. (That has been dwarfed by my primary concern of when are we ever going to find the time to formalize them). Minor tweaks and additions, not to mention total rewrites, need to go through an official maintainer (which, with suitable negotiations, could be me) to commit them to the CVS repository. OTOH, I (here I use the royal "I", meaning Paul or Tom) could simply maintain an OMAP repository, which would be available as a tarball, periodically updated, through the eCos web site. Then the 99.999999% of folks using eCos on platforms other than the OMAP wouldn't have to deal with the (albeit minor) bandwidth and disk space taken up by the OMAP port. Lather, rinse, and repeat that for each processor and platform and you've got a very sleak core OS plus additions for different applications. I especially like the fact that eCos was designed from the ground up to be easily portable to different platforms and processors. I have yet to try porting Linux to a new platform, and I know that a lot of progress has been made in the area of modularizing it to make such ports easier, but I still cringe at the thought. Whereas, with eCos, I almost look forward to it :-) Oops, that was way too much of a digression. Anyway, I like your idea. I think the split makes sense in theory... I'm sure there would be a lot of discussion in the community regarding which packages belong where, but eCos's inherent architecture would make such changes easy to implement. Great idea! --wpd -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss