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
|