Re: [Gwt-openlayers-users] GWT-OpenLayers : Vote on an SCM move to BitBucket

[Simon B. <sim...@gm...>]

 YES vote.  I have been working in a team that has been making additions to
the gwt-openlayers source and would like an easy way to put forward a patch
for review

regards,

Simon Borysiewicz

------------------------------
*
*
*From:* Andrew Hughes [mailto:ahh...@gm...]
*Sent:* Monday, 1 August 2011 9:55 PM
*To:* gwt...@li...;
gwt...@li...
*Subject:* [Gwt-openlayers-users] GWT-OpenLayers : Vote on an SCM move to
BitBucket

Hi All,

This is for both the devel and users list. Currently the number of emails we
receive regarding contributing to the project indicates that the process is
not straight forward, not easy and not intuitive. This would no doubt
preclude a lot of "would be" contributors from contributing and something I
believe we must address.

Goal: Make it as easy as possible for everyone to contribute
without compromising the stability and quality of the codebase.

At this point you can read on or jump the the conclusion and vote at the
end....

*How Distributed Version Control Should be Used (IMHO):*

Distributed version control should pass through a hierarchy of repositories
as it makes its way onto the stable baseline that releases are cut from
(Linus would probably call this a 'network of trust'). Believe it or not,
this is more about opening up access to source control than it is
restricting it. Why, because this way everyone has a sandbox repository to
fool around in, try things out, send them to others... do some RnD e.t.c.
This means that rather than sending an email to the mailing list about "how
can I contribute this" or "what is the process" or "here are some patches"
or "can I have access to the repository" everybody can just work with their
own repository... nice! It also means that since this is in a repository, it
can be easily promoted/pulled into the GWT-OpenLayers baseline ready for the
next release! via 'pull requests'.

*What's the problem with GWT-OpenLayer's and Folllowing this:*

The fundamental problem is that its *NOT EASY* for us to adhere to such a
process with SourceForge's source repository administration. It's possible,
but certainly not easy.
-Creating a new repository for a developer involves too much manual input. A
new member needs to send a request (email), the request needs to be granted,
the repository needs be be manually created by an administrator via shell.
-Controlling access to each repository involves too much manual input,
SourceForge's administration web ui doesn't control who can push to each
repository. Administrators have to ssh in and then edit the
gwt-openlayers-USERNAME/.hg/.hgrc file to manually set repository
permissions. Again, this takes too much manual effort.
-Promoting code is also too manually intensive, the reason is that if an
individual actually gets their own repository, then then push up some work
to it. The only want that it will be push up into the baseline repository
that we release from is by sending emails, or patches via email e.t.c and
this is often not an intuitive or inviting process. This process is not
intrinsic in SourceForge's source control hosting.

*Addressing these Issues:*

Rather than documenting, emailing and publishing a DIY process of making a
contribution and how to work with source control, *we should target a
hosting service where the process is intrinsic in the service it's
self * :) The
sooner we can switch the better.

*CONCLUSION*

Some of the developers are already using bitbucket (
https://bitbucket.org/gwtopenlayers) for Mercurial repository hosting. This
can work concurrently with SF's mercurial. However, we should really focus
on bitbucket's additional features (such as forking, pull requests e.t.c).
These features provide us with a suitable service and an easy, intrinsic
process for contribution. Using SF and bitbucket concurrently is something I
would not recommend either, it doesn't solve our problem.

*Please vote on a move to BitBucket and decommission SF's mercurial
repository YES/NO?*

Cheers :)