Git is a distributed development model. There is no cloud magic that
automatically makes merging distributed Git repositories any easier
than just merging against git.eclipse.org. If I'm wrong, please let
me know. Be specific.
How long does a pull/push combination take? How often does it fail?
Using branches, including the notion of a main "development" branch
and individual committer branches is how Git is intended to be used.
Using branches does fully leverage the distributed model of Git.
http://nvie.com/posts/a-successful-git-branching-model/
We have many projects with very distributed teams. The Eclipse
project, for example, has developers working in shared repositories
from China, Europe, and America.
If there are specific impediments to making this work, please let me
know. We can try to work them out here, or we can open bugs to get
Webmaster assistance.
Wayne
On 04/29/2013 02:46 AM, Wenfeng Li
wrote:
There are two issues I think we need solutions: distributed
development model and globally reliable infrastructure. Using
branches might be able to support distributed development
model to some degree, but with only servers at NA, we don't
have the distributed infrastructure. Also, I think branching
approach is not fully leveraging the distributed model of git.
Wenfeng
AFAIK, anybody with write access can create a branch in a
git.eclipse.org repository. There may be a setting that
prevents this, but the webmaster can help you sort that out.
Many projects work this way today. Creating branches is easy.
I know that some projects make it hard to delete branches
(again, I think that this is a setting) and will involve the
webmaster to delete branches to reduce the opportunities for
errors.
If this is what's stopping BIRT committers from working
directly in the git.eclipse.org repository, then we can work
this out.
The ideal situation is that BIRT developers regularly commit
their ongoing work into the master repository at
git.eclipse.org. It is perfectly valid for them to be pushing
into separate feature-specific branches, but those branches
really need to be in the master repository.
Developers forking the master repository in a GitHub context
is a non-starter. Yes, these forked repositories would be
publicly accessible, but hunting them down and identifying
which ones are eclipse.org forks would be a problem pushed on
the community. IMHO, this would be far more confusing than
having development branches in the main repository.
Wayne
On 04/28/2013 02:20 AM, Wenfeng
Li wrote:
Yes,
we could have used a feature branch. It is what we
used to do with CVS. The down side is that someone
needs to manage the creation/deletion/build/testing of
branches. I think git, as distributed tool, can help
us save such work, as well as give everyone more
freedom to work on the code without touching the
master-git, which is always more involved and
perceived risky.
Github
like model is different from creating branches in the
master git, because a developer or team of developers
doesn't need to ask the master git owner to create
branches for them. They can just start working on the
code as they wish. I think it will encourage more
developers to experiment or play with the project
code, and then contribute to the master-git code base
when they are ready or let the community to test the
features before adding them to master git. There is
already people use github to work on Eclipse code
base, but I think it would have been better (at least
IP wise) that Eclipse hosts those codes. I think such
model will help Eclipses to get more contributions
from the community than everything in the master-git
model.
In
addition to the distributed development model, I
think we shall also have the distributed
infrastructure so that all committers around the
globe can rely on the Eclipse servers, would it be
better to leverage the cloud than having our own data
center?
Lastly,
I think the issue of this email thread probably
wasn't about our different view of what the
development model should be. The issue was about if
the local git should be behind the fire-wall. I think
we are all in agreement that the desire is to have it
on a public server. With current infrastructure, we
can try push more often but we don't have the ability
to make a public "local" git. I wish that EMO can
help. . It would be even better if Eclipse can
consider supporting the distributed github model as
well as a cloud based infrastructure for global
access.
Wenfeng
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
_______________________________________________
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
|