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<igor.vaynb...@gmail.com>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
<martijn.dasho...@gmail.com> 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
