This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: Process
- From: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, Project Archer <archer at sourceware dot org>
- Date: Fri, 25 Jul 2008 16:46:38 -0300
- Subject: Re: Process
- References: <m3sktzhup5.fsf@fleche.redhat.com> <4889CDC5.10704@redhat.com>
On Fri, 2008-07-25 at 13:57 +0100, Phil Muldoon wrote:
> > * Upstream rule: I think we should require FSF assignment paperwork,
> > so that we can push changes upstream. I don't think this will be a
> > major imposition.
> >
>
> Again this is probably stating what is implied already, but if there are
> no patch-dependencies holding another patch back in Archer, it should be
> merged upstream.
I agree with this, but wonder how well it would work in practice.
Since Archer is a branch, it can accept some experimentation which
wouldn't be ready for HEAD yet. Also, if the patch which ends up
accepted in HEAD has some rework based on review comments, these
differences should be reflected back in the branch and this could be
some work...
So while this is good practice it is also some burden on the developer,
which Tromey says he would like to keep low. Perhaps this can be kept as
optional, for those who want to get bonus points? :-) It would surely
ease future merge (both merge from HEAD, and to HEAD).
We could experiment with that and use a patch tracker (perhaps even
http://gdb.false.org/patches/patches/list ?) to manage what has been
merged and what hasn't.
> I'd like the original author to do this, but understand
> differences here. Personally my goal is to attain commit after review
> status upstream as a soon as possible, to enable travel between both
> projects as needed.
Not sure what you meant with "travel between both projects".
--
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center