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

[Edwin C. <com...@gm...>]

Hi Dave,

To vote just reply to the email with a YES or NO in the body.

The nature of the repository will not change. The source code will
still be in a Mercurial repository. What changes will be the address
of the main repository. Currently the main repository (representing
the main line of work) is hosted at SourceForge. We would like to move
this repository to Bitbucket.

Moving to Bitbucket makes things easier for committers as well as
administrators. For committers it means:
 - Committers will have to sign up for Bitbucket (free).
 - Committers can fork the project at Bitbucket to create their own sandbox
 - If you are already have commit rights on SourceForge you can get
commit rights on the main repo at BitBucket (just send an email to me)
and pull changes from your fork into the main repo
 - If you do not have commit rights then you can send pull requests,
so the admins can decide if they want to pull changes from your
sandbox (probably via a sandbox of the admin).

Greetings,
Edwin

On 1 August 2011 14:11, Dave Potts <dav...@pi...> wrote:
> Hi
>
> 1. How does one vote?  do you have some type of link that can be used?
> 2. What happens to existing projects?
>
> I have an entire series of useful(?) changes (console,http,handler
> stratgy,projection etc)  They are part of my personnel  codebase how could
> I integrate these changes if you change the nature of the Mercurial
> repository?
>
>
> Dave.
>> 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 :)
>> ------------------------------------------------------------------------------
>> Got Input?   Slashdot Needs You.
>> Take our quick survey online.  Come on, we don't ask for help often.
>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
>> http://p.sf.net/sfu/slashdot-survey
>> _______________________________________________
>> Gwt-openlayers-users mailing list
>> Gwt...@li...
>> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users
>>
>
>
>
> ------------------------------------------------------------------------------
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Gwt-openlayers-users mailing list
> Gwt...@li...
> https://lists.sourceforge.net/lists/listinfo/gwt-openlayers-users
>