From Wayne and Jessie's email , I gather that any local git
repo is not recommended. All committers should be using the
git.eclipse.org directly.
Wayne, after our subnet is white-listed I have not heard
the access deny problem anymore. On the other hand, the longest period of
not being able to access Eclipse servers was due to a under-sea internet cable
was cut. Nothing webmaster or us can do anything about it.
I will talk to all committers at Actuate to connect to
git.eclipse.org directly. I expect that the same concern
of performance, reliability, etc would be raised. But I will
convey the message that this is Eclipse's recommendation: Actuate should not be
providing a local git repo behind the firewall. If
needed for Kepler release, Actuate can keep the local git repo until
Kepler is done. But definitely stop after that.
Wenfeng
From: birt-pmc-bounces@xxxxxxxxxxx
[mailto:birt-pmc-bounces@xxxxxxxxxxx] On Behalf Of Wayne Beaton
Sent: Monday, April 29, 2013 12:06 PM
To: birt-pmc@xxxxxxxxxxx
Subject: Re: [birt-pmc] BIRT Git repository may be out of date.
The webmaster's email log shows
that--in most cases--the problems were caused by repeated authentication
problems causing our intrusion detection logic to blacklist the subnet. He
tells me that the subnet has been whitelisted, so as long as your committers
know their login credentials they should be able to access git.eclipse.org
directly.
If problems persist, we need to know about them so that they can be addressed.
I am concerned about the authentication problem. What could be causing multiple
authentication failures? Are committers forgetting their credentials? Or was
this just a point-in-time problem?
Do these problems persist today?
Wayne
On 04/29/2013 02:03 PM, Wenfeng Li wrote:
If the branches are all in the same central server and if the
central server is not accessible, then users of the git system are stuck.
This is what I meant not fully leveraging the distributed model of git.
We can go back to check the historic data, you can also check
with Eclipse web masters. As I recalled in the previous email, there were
cases we don't have access for Eclipse servers for days and at one case for
weeks.
Wenfeng
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.
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
_______________________________________________ birt-pmc mailing list birt-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/birt-pmc
|
