Working on a feature in a local repo and then pushing the commits
for that feature to the master repo is a reasonable way of working.
In my definition, however, a "feature" represents a handful of
commits over a half-day or so of work (based on the agile concept of
a feature). I assume that you're using "feature" in a much broader
sense of the word.
The synchronization with git.eclipse.org has to happen more
frequently. If not automatically, then you'll have to work regular
manual synchronization into your development plan. Frankly, I agree
that doing it automatically won't work in the general case: if the
project has committers working outside of the Actuate
infrastructure, the opportunity for merge conflicts will grow.
The git.eclipse.org repository has to be treated as the master
repository. You can't treat the master repository as some protected
thing that you only ever push complete work to. Incomplete work
needs to be in the repository as well: perhaps in separate branches,
but most certainly in the master repository. It's okay to be a few
commits behind here-and-there, but the master repository needs to
contain the ongoing work.
Perhaps you might consider creating feature-specific branches for
ongoing development of features that you aren't ready to merge into
master or one of the version-specific branches .
I don't understand how working with GitHub would be any different
than working directly with git.eclipse.org. You'd still have to be
regularly pushing to a publicly-accessible repository. If you can do
this against GitHub, why not git.eclipse.org? Any global distributed
cloud-based infrastructure that I can envision is still going to
have a merge conflict/resolution problem to solve.
Git is our distributed infrastructure. At this point in time, we
have no plans (or motivation) to invest in an alternative solution.
Wayne
On 04/27/2013 11:36 PM, Wenfeng Li
wrote:
Why
it is not possible for any other committers to push local
git to Eclipse master git? Actuate's repo is not the
"master" copy, Eclipse one is. Any other committer's
local repo can be merged to the Eclipse master copy.
"Thrown
over the wall" is not accurate nor a
fair characterization of the contribution of our team. I am
disappointed on
the use of such words. If a feature required changes from
several
people, having a local repo to test the integration before
merging to the
master repo is a better process than automatically throw
over the code to
master repo without integration testing first.
I
am open to suggestions. But I think automatic merge is
not the solution.
What
do you think about the gitHub model? All committers
can have a "local"/"personal" git, and merge to the master
repo
when a feature is completed/tested.
If
you agree with such model, is it possible for Eclipse to
setup a global distributed gitHub equivalent for the Eclipse
community? With
that, we will be able to get out of the work to maintain a
local behind the
firewall git which I also agree that is not a good
situation.
Wenfeng
Synchronizing
multiple
distributed repositories is one of the key values provided by
Git. Git is
designed to solve the distribution, replication, and merge
problems. Git, when
used properly, is the cloud-based solution that you think you
need.
Having the main project content being developed in a Git
repository that is
"thrown over the wall" every month or week or so is
effectively a
private project. For all practical purposes, it is impossible
to contribute to
BIRT so long as the active repository is hidden away where it
is inaccessible
to the community. If only Actuate employees have any hope of
contributing to
the project repository, then it is effectively an Actuate
project.
Do you encounter specific, real problems when doing a Git push
to git.eclipse.org?
Let's work them out. Git is designed to make this work, let's
make it work.
Wayne
On 04/26/2013 10:00 PM, Wenfeng Li wrote:
I
agree with Mike that a public accessible local git is more
transparent. Hence the proposal for the foundation to set
up more
"local" git servers globally.
On
the other hand, having a behind the firewall local git
doesn't mean the project is Actuate's only, all
committers can set up
their own local git and push to the same master git at
Eclipse.
This is the distributed nature of Git.
As
for the suggestion of automatically push local
change, one issue needs to resolve is how to resolve
conflicts if there are changes from different "local"
git?
An
ideal situation is that committers don't need to worry
about
the source control system and build servers. A public,
reliable, fast,
cloud based global solution would be great.
Wenfeng
I am not sure that even this would be
acceptable. The problem
with doing development behind the firewall is that it
means that the project is
Actuate's, not Eclipse's. How can someone from any other
company participate
equally on the project if the main development and the
'stable ' builds all
happen behind a firewall?
Mike
Milinkovich
mike.milinkovich@xxxxxxxxxxx
+1.613.220.3223
Git is by
its
very nature a distributed system. Investing in something
like AWS for this
makes no sense.
We have no issue with a project team working from a local
clone. Some amount of
latency is expected, but a full month is too much for a
project that is
expected to working in an open and transparent manner. It
is basically
impossible for anybody else to participate in the project
if the repository is
always days, weeks, or months out-of-date.
The pushes back to eclipse.org have to be done more
frequently.
At a minimum, you should be able to very quickly set up a
cron job that forces
a push to eclipse.org every day, or--even better--a few
times a day (every
hour). This should literally require a one-liner cron
entry. I can help
if necessary.
Your developers shouldn't even notice the push is
happening. Even better would
be some kind of commit hook that does the push (as Jesse
suggests). If a single
push fails, the next one will do the job. That's how Git
works.
This needs to be automatic.
Please make this happen as soon as possible.
Wayne
On
04/26/2013 04:59 PM, Wenfeng Li
wrote:
Wayne
Is
it your recommendation
that projects should not use a local git depot,
instead all should just use the
Eclipse master git depot?
We
had run into network and
accessibility issue to the Eclipse server in the past
that causing delay of
work and risking not meeting the simultaneous release
schedule.
There were many times, developers can't do work for a
several hours to a
couple of day. And there were one time when the whole
team was shut down
for a week due to a undersea cable was cut between
North America and
Asia.
One
possible solution is for
Eclipse foundation to create a distributed git service
around the world (using
AWS?), it will allow committers to remove the need of
local gits.
For
now, with distributed
git, there is a question of how often you push the
local copy to the master
copy. It is a matter of someone needs to do the
work. The more
often the push, the more work. On the other hand, we
understand we don't
want to have a big gap. so our plan is to push
after every
stable build since we expect most users would only be
using stable builds.
In
short, I agree that we
need to push the code now, since it has been too long
since last push.
The intention was to push at least once a month if not
more often after each
stable build.
br,
Wenfeng
I'm moving
this discussion out of
bugzilla an onto the PMC list.
I assume that you mean "Git" rather than "GitHub".
How often does this push happen?
_______________________________________________
birt-pmc mailing list
birt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/birt-pmc
_______________________________________________
birt-pmc mailing list
birt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/birt-pmc
_______________________________________________
birt-pmc mailing list
birt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/birt-pmc
|
