You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2010/12/14 17:29:07 UTC
Future hosting of wicket stuff
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
Re: Future hosting of wicket stuff
Posted by James Carman <ja...@carmanconsulting.com>.
+1 for Apache Extras.
On Tue, Dec 14, 2010 at 11:29 AM, Martijn Dashorst
<ma...@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
>
Re: Future hosting of wicket stuff
Posted by Renaud Bruyeron <br...@fullsix.com>.
+1 for github
I don't really know what "proximity to apache" brings to wicketstuff
given the nature of wicketstuff (wicket core is another story). To me
this is irrelevant to the discussion.
What I know is: the social coding features of github is a must for
wicketstuff (unlike wicketcore where a more centralized governance might
make sense). In my opinion, this criteria alone trumps all the others.
Renaud
Le 12/14/10 5:29 PM, Martijn Dashorst a écrit :
> 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
Re: Future hosting of wicket stuff
Posted by Igor Vaynberg <ig...@gmail.com>.
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
<mi...@rivulet.ca> 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<ig...@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
>>> <ma...@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
>
>
Re: Future hosting of wicket stuff
Posted by Michael O'Cleirigh <mi...@rivulet.ca>.
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<ig...@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
>> <ma...@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
Re: Future hosting of wicket stuff
Posted by Martin Grigorov <mg...@apache.org>.
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 <ig...@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
> <ma...@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
> >
>
Re: Future hosting of wicket stuff
Posted by Clint Checketts <ch...@gmail.com>.
I don't know if I've any pull in voting, but +1 for github from me. It also
would help in cases when a Wicket-Stuff idea may want to fork Wicket core to
try new stuff.
-Clint
On Tue, Dec 14, 2010 at 10:39 AM, Igor Vaynberg <ig...@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
> <ma...@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
> >
>
Re: Future hosting of wicket stuff
Posted by Igor Vaynberg <ig...@gmail.com>.
+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
<ma...@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
>
Re: Future hosting of wicket stuff
Posted by Andrew Lombardi <an...@mysticcoders.com>.
+1 for Github.
On Dec 14, 2010, at 8:29 AM, Martijn Dashorst 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
To our success!
Mystic Coders, LLC | Code Magic | www.mysticcoders.com
ANDREW LOMBARDI | andrew@mysticcoders.com
2321 E 4th St. Ste C-128, Santa Ana CA 92705
ofc: 714-352-0298
fax: 714-782-6024
cell: 714-697-8046
linked-in: http://www.linkedin.com/in/andrewlombardi
twitter: @kinabalu
facebook: http://www.facebook.com/lombardi
fan mystic: http://www.facebook.com/mysticcoders
flickr: http://www.flickr.com/photos/kinabalu
Eco-Tip: Printing e-mails is usually a waste.
========================================================
This message is for the named person's use only. You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you are not the intended recipient.
========================================================
Re: Future hosting of wicket stuff
Posted by Martijn Dashorst <ma...@gmail.com>.
Looking at the votes I think moving to github has the major support.
Let's discuss how to proceed from here (but in another thread).
Martijn
Re: Future hosting of wicket stuff
Posted by nino martinez wael <ni...@gmail.com>.
+1 Apache Extras (but only based on that I already know svn)
2010/12/14 Martijn Dashorst <ma...@gmail.com>
> 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
>
Re: Future hosting of wicket stuff
Posted by Brian Topping <to...@codehaus.org>.
Also, if things move to Github and issues need to be moved, I spent some time getting too familiar with how that process works. There are no easy to use tools to move issues, it is inexact at best, but I do have the code that was used to move the Brix issues and am happy to post to Github if anyone wants it, contact me off list.
On Dec 14, 2010, at 3:19 PM, Brian Topping wrote:
> We moved Brix to Github over the last several weeks. I was somewhat skeptical at first, but I like it a lot. People that want a patch can just fork the project, and if the project wants their changes, they are trivial to grab.
>
> The issue management at Github is pretty weak. Usable for projects the size of Brix and WicketStuff, but weak.
>
> As far as wiki is concerned, it seems like Brix would be ideal for this, but I haven't gotten any traction in this regard. I believe a wiki written in Wicket would be valuable for a lot of projects, but this discussion shouldn't be sidetracked into the relative (lack of) merits. Interested folks can contact me off list if they want to discuss.
>
> +1 for Github. I agree in principle that being closer to Apache is a good thing, but for widgety projects, there's too much overhead to adding new folks.
>
> $0.02...
>
> Brian
Re: Future hosting of wicket stuff
Posted by Brian Topping <to...@codehaus.org>.
We moved Brix to Github over the last several weeks. I was somewhat skeptical at first, but I like it a lot. People that want a patch can just fork the project, and if the project wants their changes, they are trivial to grab.
The issue management at Github is pretty weak. Usable for projects the size of Brix and WicketStuff, but weak.
As far as wiki is concerned, it seems like Brix would be ideal for this, but I haven't gotten any traction in this regard. I believe a wiki written in Wicket would be valuable for a lot of projects, but this discussion shouldn't be sidetracked into the relative (lack of) merits. Interested folks can contact me off list if they want to discuss.
+1 for Github. I agree in principle that being closer to Apache is a good thing, but for widgety projects, there's too much overhead to adding new folks.
$0.02...
Brian
Re: Future hosting of wicket stuff
Posted by Maarten Bosteels <mb...@gmail.com>.
Hi Richard,
If the wicket related code that you are going to release is a clean,
polished project on its own, and you plan to keep supporting it,
then I think the project deserves its own hosting, instead of being added to
wicket-stuff.
There is a lot of cool stuff and useful ideas in wicket-stuff, And I am
certainly in favour of keeping wicket-stuff and the 'everyone can commit'
concept.
But the downside is that the level of maturity and support varies greatly
within the subprojects.
regards
Maarten
I have no opinion, but I am interested in seeing how the process
> is structured and comes to a resolution. I hope to release some
> Wicket related code early next year and will have to select some
> hosting environment.
>
> Thanks
>
> Richard
>
> --
> Quis custodiet ipsos custodes
>
Re: Future hosting of wicket stuff
Posted by richard emberson <ri...@gmail.com>.
What is the criteria being used for making this decision?
What is easiest for the developer:
Checkout/checkin/branching/merging/etc
What is easiest for the user:
Getting releases or snapshots/logging bugs/bug status/getting help/etc
If only developers are voting (those who commit code),
you will get what developers want.
Are users also voting? Is their vote equal to or more important
than a developer's vote?
I would assume there are two sets of needs; some might overlap while some
might be in conflict. How are such conflicting needs between what
a developer might find as easy to use and what a user finds as
easy being addressed?
Has a list of user needs been enumerated and evaluated against
the different options?
I have no opinion, but I am interested in seeing how the process
is structured and comes to a resolution. I hope to release some
Wicket related code early next year and will have to select some
hosting environment.
Thanks
Richard
--
Quis custodiet ipsos custodes
Re: Future hosting of wicket stuff
Posted by Igor Vaynberg <ig...@gmail.com>.
imho.
most people download through maven, so the downloading interface is
irrelevant. and even looking at it: googlecode has a downloads tab,
github has a big button on the front page - little difference.
the only other relevant part is the wiki - imho they are pretty much
the same on github and googlecode. nice thing about gc is that it has
the sidebar feature in the wiki, but its not a gamechanger.
the big win in github is the administration. currently this is a huge
timesink for the maintainers because every committer has to be
explicitly added to the project. with gc this remains the same, with
github there are pull requests and merge queue interface which are a
cheap alternative for those who only want to commit once.
-igor
On Tue, Dec 14, 2010 at 10:21 PM, tetsuo <ro...@gmail.com> wrote:
> I'm just saying that Google Code's interface is much cleaner and
> friendlier, which helps a lot with projects' adoption (you don't get a
> .
>
> And it supports Mercurial, which is pretty much the same as git in
> terms of cloning and merging changes back.
>
>
> On Tue, Dec 14, 2010 at 5:17 PM, Martin Grigorov <mg...@apache.org> wrote:
>> On Tue, Dec 14, 2010 at 7:37 PM, tetsuo <ro...@gmail.com> wrote:
>>
>>> GitHub may be a little better for developers, but I think it's quite
>>> intimidating to users (people who just want to easily download the
>>> binaries and read the documentation).
>>>
>>> Google Code (thus, Apache extras) is much more friendly to
>>> non-committer-users.
>>>
>>> But well, if one is fine with that randomly structured wicketstuff
>>> wiki site, github shouldn't be a problem... (sigh)
>>>
>> It will not be randomly structured.
>> There will be a main page with links to the documentation for each project.
>> Just like it was/is in Confluence.
>>
>>>
>>>
>>>
>>> On Tue, Dec 14, 2010 at 4:25 PM, Carl-Eric Menzel <cm...@wicketbuch.de>
>>> wrote:
>>> >> Moving to Github
>>> >
>>> > +1 for github. It makes distributed development so much easier. As for
>>> > staying close to Apache... apache.org is only a link away.
>>> >
>>> > Carl-Eric
>>> > www.wicketbuch.de
>>> >
>>>
>>
>
Re: Future hosting of wicket stuff
Posted by tetsuo <ro...@gmail.com>.
I'm just saying that Google Code's interface is much cleaner and
friendlier, which helps a lot with projects' adoption (you don't get a
.
And it supports Mercurial, which is pretty much the same as git in
terms of cloning and merging changes back.
On Tue, Dec 14, 2010 at 5:17 PM, Martin Grigorov <mg...@apache.org> wrote:
> On Tue, Dec 14, 2010 at 7:37 PM, tetsuo <ro...@gmail.com> wrote:
>
>> GitHub may be a little better for developers, but I think it's quite
>> intimidating to users (people who just want to easily download the
>> binaries and read the documentation).
>>
>> Google Code (thus, Apache extras) is much more friendly to
>> non-committer-users.
>>
>> But well, if one is fine with that randomly structured wicketstuff
>> wiki site, github shouldn't be a problem... (sigh)
>>
> It will not be randomly structured.
> There will be a main page with links to the documentation for each project.
> Just like it was/is in Confluence.
>
>>
>>
>>
>> On Tue, Dec 14, 2010 at 4:25 PM, Carl-Eric Menzel <cm...@wicketbuch.de>
>> wrote:
>> >> Moving to Github
>> >
>> > +1 for github. It makes distributed development so much easier. As for
>> > staying close to Apache... apache.org is only a link away.
>> >
>> > Carl-Eric
>> > www.wicketbuch.de
>> >
>>
>
Re: Future hosting of wicket stuff
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Dec 14, 2010 at 7:37 PM, tetsuo <ro...@gmail.com> wrote:
> GitHub may be a little better for developers, but I think it's quite
> intimidating to users (people who just want to easily download the
> binaries and read the documentation).
>
> Google Code (thus, Apache extras) is much more friendly to
> non-committer-users.
>
> But well, if one is fine with that randomly structured wicketstuff
> wiki site, github shouldn't be a problem... (sigh)
>
It will not be randomly structured.
There will be a main page with links to the documentation for each project.
Just like it was/is in Confluence.
>
>
>
> On Tue, Dec 14, 2010 at 4:25 PM, Carl-Eric Menzel <cm...@wicketbuch.de>
> wrote:
> >> Moving to Github
> >
> > +1 for github. It makes distributed development so much easier. As for
> > staying close to Apache... apache.org is only a link away.
> >
> > Carl-Eric
> > www.wicketbuch.de
> >
>
Re: Future hosting of wicket stuff
Posted by tetsuo <ro...@gmail.com>.
GitHub may be a little better for developers, but I think it's quite
intimidating to users (people who just want to easily download the
binaries and read the documentation).
Google Code (thus, Apache extras) is much more friendly to non-committer-users.
But well, if one is fine with that randomly structured wicketstuff
wiki site, github shouldn't be a problem... (sigh)
On Tue, Dec 14, 2010 at 4:25 PM, Carl-Eric Menzel <cm...@wicketbuch.de> wrote:
>> Moving to Github
>
> +1 for github. It makes distributed development so much easier. As for
> staying close to Apache... apache.org is only a link away.
>
> Carl-Eric
> www.wicketbuch.de
>
Re: Future hosting of wicket stuff
Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
> Moving to Github
+1 for github. It makes distributed development so much easier. As for
staying close to Apache... apache.org is only a link away.
Carl-Eric
www.wicketbuch.de