public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: John Dallaway <jld@ecoscentric.com>
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	[thread overview]
Message-ID: <200303181605.21189.jld@ecoscentric.com> (raw)
In-Reply-To: <1047995318.7459.2925.camel@hermes.chez-thomas.org>

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

  reply	other threads:[~2003-03-18 16:04 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-18  8:47 Patches " John Dallaway
2003-03-18 13:48 ` Gary Thomas
2003-03-18 16:04   ` John Dallaway [this message]
2003-03-18 17:25     ` Proposal for processing patches " Jonathan Larmour
2003-03-18 18:21       ` Nick Garnett
2003-03-18 18:56     ` Andrew Lunn
2003-04-12  5:00       ` Jonathan Larmour
2003-04-14  7:28         ` Andrew Lunn
2003-03-18 19:01     ` Andrew Lunn
2003-03-18 22:58       ` Jonathan Larmour
2003-03-18 19:16     ` SNMP for FreeBSD Andrew Lunn
2003-03-19 13:22       ` Jonathan Larmour
2003-03-19 14:23         ` Gary Thomas
2003-03-19 18:07         ` Nick Garnett
2003-03-25 17:01       ` Andrew Lunn
2003-03-19 14:22     ` 2.0 branch: mn10300 debug info patch Bart Veer
2003-03-19 14:40       ` John Dallaway
2003-03-19 18:07       ` Nick Garnett
2003-03-18 18:09   ` Patches for the eCos 2.0 branch Nick Garnett
2003-03-18 18:25     ` Gary Thomas
2003-03-18 19:05       ` Nick Garnett
2003-03-18 19:13         ` Gary Thomas
2003-03-19 10:18           ` New CPM/DPRAM allocator John Dallaway
2003-03-19 13:02             ` Nick Garnett
2003-03-19 14:38               ` Gary Thomas
2003-03-19 15:44               ` John Dallaway
2003-03-19 17:06                 ` Gary Thomas
2003-03-19 18:22                   ` Nick Garnett
2003-03-19 18:26                     ` Gary Thomas
2003-03-19 18:52                       ` Nick Garnett
     [not found]                         ` <1048100525.7462.5617.camel@hermes.chez-thomas.org>
2003-03-19 19:21                           ` Nick Garnett
2003-03-20 13:02                           ` Nick Garnett
2003-03-20 13:14                             ` Gary Thomas
2003-03-20 18:11                               ` Nick Garnett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200303181605.21189.jld@ecoscentric.com \
    --to=jld@ecoscentric.com \
    --cc=ecos-maintainers@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).