This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Process

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 ?) 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)



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]