This is the mail archive of the
mailing list for the Archer project.
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,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
so that we can push changes upstream. I don't think this will be a
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
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)