Re: Process

[Phil Muldoon <pmuldoon at redhat dot com>]

Thiago Jung Bauermann wrote:
> 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).
>   

I mean it purely to keep the divergence between the two as small as we 
can, with appropriate economy. Point well taken about experimental 
changes.  This is more a personal goal too. I will be pushing whatever I 
have to the GDB mainline where possible. Does this mean those changes 
will get accepted? Who knows - I hope for a listening audience, and 
perhaps lively debate ;) I guess we all have our individualized views of 
project Archer; and I'm guessing threads like these are ways for us all 
to converge on a set of ideas we are all comfortable with. Personally I 
see it as a clearing house - and a place to experiment initially - but 
always in mind to move this upstream.

> 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.
>   

Yeah there are lots of ways, and that idea is certainly good. You can 
manage patches through dependency management in bugzilla too. Or as 
Roland suggested, a branch in git.

>   
> Not sure what you meant with "travel between both projects".
>   

Yeah I was a bit obtuse. It is my goal is to be equally comfortable with 
Archer's and GDB's upstream rules, guidelines and procedures. I want to 
be a Project Archer committer and a GDB committer. And hey ...  if we do 
our work very well eventually Archer will go away; it won't be needed 
any more. ;)

(Or .... it could always be somewhat of an incubator for technology 
beyond this initial set)

Regards

Phil