Re: [e4-dev] Resources 6-Mar-2009 meeting notes

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

We should likely also consider the same
questions for the 'back porting' excercise (i.e. moving new e4 functionality
-into- the 3.x stream) where appropriate....

Eric

Paul Webster <pwebster@xxxxxxxxxxxxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

03/06/2009 01:53 PM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [e4-dev] Resources 6-Mar-2009 meeting notes

Hi all,

Before we start forking other projects I think it's time we set up a
policy for it.

1) fork owner

Someone has to be responsible for keeping the fork up to date.  I
also
need someone I can ping if a forked project breaks the build.

2) rebase frequency

It looks like the forked projects need to have a statement about when
they're rebase on the main project.  Every I build?  Simple rebase
once a week to HEAD?  On any breaking change in 3.5 (o.e.ui.ide has
been lucky that most of the work in 3.5 these days has been in
o.e.ui.workbench, but as Francis mentioned that's not the case in
o.e.ui.navigator or o.e.ui.navigator.resources?

3) how do we work easily with the tools we have

It seems like the cleanest way to work would be to for the project and
then work in an e4 branch.  Updates to the main project in HEAD (at
each I build) can be taken and then applied to the e4 project in its
HEAD with relatively little pain.  The e4 branch can simply merge
in
HEAD at that point and keep going.

There is a 3rd party source code workflow supported by CVS using
vendor tags ... I'm not sure how it applies between the main project
and the forked project.

----

Once we decide on the policy, then we can fork the o.e.ui.navgator*
and apply the changes back to o.e.ui.ide.

-- 
Paul Webster
Hi floor.  Make me a sammich! - GIR
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev