From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18390 invoked by alias); 18 Mar 2003 16:04:20 -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 18324 invoked from network); 18 Mar 2003 16:04:20 -0000 Content-Type: text/plain; charset="utf-8" From: John Dallaway Organization: eCosCentric Limited To: ecos-maintainers@sources.redhat.com Subject: Proposal for processing patches for the eCos 2.0 branch Date: Tue, 18 Mar 2003 16:04:00 -0000 User-Agent: KMail/1.4.3 References: <200303180848.24682.jld@ecoscentric.com> <1047995318.7459.2925.camel@hermes.chez-thomas.org> In-Reply-To: <1047995318.7459.2925.camel@hermes.chez-thomas.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200303181605.21189.jld@ecoscentric.com> X-SW-Source: 2003-03/txt/msg00011.txt.bz2 Hello eCos Maintainers I've spoken with some of you already about putting in place a process for deciding which patches do and do not get applied to the eCos 2.0 branch from now on. I would like to suggest that we post proposals for patching the 2.0 branch to the ecos-maintainers (sic) list. Each proposal should contain: a) A brief name by which we can all refer to the patch. b) A description of what the patch achieves or the problem which it addresses. No more than a few sentences. c) A rationale for including the patch in the 2.0 final release. This rationale should be mindful of the need to minimise disruption to the branch as far as possible and therefore preserve the value of 2.0b1 testing feedback from the eCos community. A good rationale might be: "This patch touches the XYZ platform HAL package only. Support for this platform is currently completely broken." A bad rationale might be: "This patch provides feature ABC which I've been intending to implement for ages and would really like to see in the eCos 2.0 final release." d) The patch itself, or a URL to the patch in the ecos-patches list archive. I would like the eCos maintainers to then have a maximum period of 2 days to debate before (hopefully) a consensus is reached. If consensus is not reached then a simple majority verdict among the maintainers should prevail. The above procedure should be adopted for all target side code in the branch at minimum. There is still quite a bit of work to be done on the configtool for 2.0 final so we might consider excepting configtool code from this process. The usual procedures for patches to the trunk of the repository would be unaffected by all this. Please comment on or otherwise indicate your acceptance of this proposal and whether you think configtool patches should be excepted or not. Thanks John Dallaway