I'd say either move to googlecode (http://code.google.com/p/wicketstuff/) :
or [X] stay with sf.net But we will still need a building server. I'd hate to see wicketstuff die. 2010/4/19 Pointbreak <[email protected]>: > I would think that an eventual move to github is unrelated to any of the > maintenance problems you describe. Therefore I would say keep it is > simple as possible and stay with sourceforge when executing the proposed > tags. As moving to a github (and a distributed VCS) will introduce its > own problems, paradigm shifts, tool incompatibilities and general > misunderstandings. Whether or not such a move would be beneficial or not > should be a separate discussion, that is unrelated to the problems you > are trying to solve in your proposal. > > [X] stay with sf.net > [ ] move to github > > > On Mon, 19 Apr 2010 17:31 +0200, "Martijn Dashorst" > <[email protected]> wrote: >> Currently we have a maintenance nightmare. Keeping up confluence, >> jira, teamcity and the maven repo is cumbersome at best. We keep >> running out of diskspace (/var has reached -300M disk free, yes minus >> 300M). >> >> So I propose the following: >> - use Apache's build grid for Wicket code, Apache repository for >> staging and snapshot releases: separating the Apache Wicket projects >> from Wicket Stuff projects >> - no more custom, self hosted products a la confluence and jira (no >> matter how much we like them) >> - use wicketstuff.org only for running examples and a build server >> for wicket stuff projects >> - use sonatype's OSS repo hosting for our snapshots, release staging >> and releases (no more wicketstuff.org/repository/maven) >> >> Most importantly: >> - vote on the future of the hosting of Wicket Stuff: >> [ ] stay with sf.net >> [ ] move to github >> - if we stay on sf.net: use the sf.net provided tools to manage the >> project: issues, wiki and website >> - if we stay to move to github: use github's provided tools to manage >> the project: issues, wiki and website >> >> Martijn >> >
