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

[Dave P. <dav...@pi...>]

YES

I am in favour off anything that makes life easier for programmers and
cuts down on the amount of admin for administrators.
> + 1 here.
>
> 2011/8/1 Edwin Commandeur <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
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
>
>
> --
> Giuseppe La Scaleia
> CNR - IMAA
> geoSDI
> Sviluppo Software
>
> C.da S. Loja
> 85050  Tito Scalo - POTENZA (PZ)
> Italia
>
> phone:  +39 0971427305
> fax:      +39 0971 427271
> mob:    +39 3804697436
> mail:     giu...@ge...
> skype:  glascaleia
>
> web:     http://www.geosdi.org
>