i think keeping it simple would be best we host the main wicketstuff repo on github. people who want to contribute then have two ways of doing this:
if they are going to work on a project on a continuous basis they can request push rights and we can grant them if they just want to fix a bug or give a one-off commit they can open a pull request which one of the maintainers can apply -igor On Tue, Dec 14, 2010 at 9:51 PM, Michael O'Cleirigh <[email protected]> wrote: > I'm +1 for github because I've been learning git recently and I think it > would be worth switching from svn. > > Also because on the last vote I thought github was too radical but in > hindsight wish we had switched to it. > > On the weekend I did a git svn clone of the full wicketstuff repository to > start investigating how such a migration could be done. I also wrote a > program to build a svn-to-git-authors file by scraping the users page on > http://sourceforge.net/users/${user} based on the subversion commit log. I > can make this file available to others for testing. > > My work was focused on how to make a read-only mirror of svn but what would > be a good workflow for getting updates into the root repository? > > Would using the github repo as a central repo (the same as svn)? And the > developers would have the ability to push and pull against it? > > wicketstuff repo -> wicketstuff developer forks > > authorized devs can push into the wicketstuff repo. > > Or is their some kind of hybrid like the "blessed repository" pattern: > http://whygitisbetterthanx.com/#any-workflow (scroll down to the second one) > > release repo -> development repo -> wicketstuff developer forks > > Then each wicketstuff developer with access granted can push into the > development repo. Hudson would work from the development repo and releases > would be cut from the release repo by pulling in the latest from the > development repo. > > Or something else? > > Maybe using submodules or subtree to split the repository into its composite > parts? > > Regards, > > Mike > > >> I'm also +1 for github. >> But this is based on my experience as a user of github. >> >> I don't have any experience in managing github organization. >> I guess each wicketstuff project will be a repository and it will have its >> own issue tracker. >> Will we add each contributor as a member with no managing functions to the >> organization ? I'm trying to imagine how I as a contributor to project X >> will be notified when someone else file an issue for this particular >> project. Or it will be mine responsibility to check the issue tracker for >> my >> project from time to time and create pull request for my patches and >> explanation for which issue it is and then the person who applies the >> patch >> will manage the issue tracking too ? >> >> On Tue, Dec 14, 2010 at 5:39 PM, Igor >> Vaynberg<[email protected]>wrote: >> >>> +1 for github >>> >>> biggest drag on managing wicketstuff is the high price for >>> accepting/applying/submitting patches; at github it is almost >>> non-existant since anyone can raise a pull request and they are >>> trivial to apply. >>> >>> -igor >>> >>> On Tue, Dec 14, 2010 at 6:29 PM, Martijn Dashorst >>> <[email protected]> wrote: >>>> >>>> Things change and while we had a nice stay at sf.net, I think it is >>>> time to move on with Wicket Stuff to newer ground. We have had this >>>> discussion before and the discussion stalled mostly because Apache and >>>> Google were in talks about a new service called Apache Extras [1]. >>>> Fortunately those talks are now over and we can continue our future of >>>> Wicket Stuff hosting discussion. >>>> >>>> In my opinion there are two possible hosting solutions for Wicket Stuff: >>>> >>>> - the newly announced Apache Extras >>>> - github's organization feature >>>> >>>> For Wicket Stuff we have a couple of things that worked fairly badly >>>> in the past. SVN connectivity from our build system connecting to >>>> SF.net was spotty at best, and didn't work most of the time. This has >>>> improved considerably by using Hudson instead of Teamcity (though not >>>> all builds that were done on teamcity have been migrated to hudson) >>>> >>>> I declare the JIRA instance of wicket stuff officially dead and gone >>>> to meet its maker. While we could opt for another JIRA enterprise >>>> license, I find maintaining the service a chore, and having to upgrade >>>> every now and then a waste of time better used to build cool stuff. >>>> While the issue trackers of Apache Extras (i.e. google code) and >>>> github are barebones, they have enough features to work with—we're not >>>> building missile guidance software requiring CMM level 5, SAS-71 etc >>>> certification. >>>> >>>> A similar issue arises with confluence. While I appreciate confluence >>>> being the best wiki available, again maintaining and upgrading it is >>>> no picnic, and both Apache Extras and github provide fine >>>> implementations of wikis. >>>> >>>> So I'd like to propose the following options: >>>> >>>> - stay at sf.net but use the sf.net hosted issue tracker and wikis >>>> - move everything over to an Apache Extras Wicket Stuff project >>>> - move everything over to a Github Wicket Stuff organization >>>> >>>> Staying at sf.net >>>> >>>> - scm options: SVN, Git, Mercurial, Bazaar, or CVS >>>> - no social options >>>> - No Apache Extras brand name >>>> - account management a drag >>>> - no limitation on allowed open source licenses >>>> - web UI a complete travesty >>>> >>>> Moving to Apache Extras >>>> >>>> - scm options: HG and SVN >>>> - no social options >>>> - Apache Extras brand name >>>> - account management a drag >>>> - limitation on allowed open source licenses >>>> >>>> Moving to Github >>>> >>>> - scm options: git >>>> - many social options (easy forking/merging/pull requests, etc) >>>> - No Apache Extras exposure >>>> - account management possibly easier (less need to actually add >>>> accounts to projects for sure) >>>> - no limitation on allowed open source licenses >>>> >>>> For this exercise I assumed the wiki and issue trackers of both github >>>> and Apache Extras are equally barebones. >>>> >>>> What do you think? If I've missed something add to this thread. If you >>>> prefer one solution over the other speak up! >>>> >>>> Martijn >>>> >>>> [1] >>> >>> >>> https://blogs.apache.org/foundation/entry/the_apache_software_foundation_launches > >
