Unless you haven't read the lists last couple of weeks, there have
been numerous problems letting our build server connect to sf.net's
servers. In the past the service of sf.net was abysmal (but we haven't
used their stuff for a while, so it may have improved).

Moving to greener pastures most certainly is related to these
problems: we don't have the time to manage the server properly. We
don't have the time to ensure timely upgrades of the software, we
don't have the time to investigate what is messing up our buildserver
(is it teamcity, sf.net, our polling schedule?).

Moving to github may not solve these problems or introduce new ones,
but it provides some really nice infrastructure, together with the
best SCM currently available (Hg could also classify as best, I hear).

Github solves: wiki, site, tracker, scm (post commit hooks!). No more
confluence/jira to maintain... now that would be a boon!

Martijn

On Mon, Apr 19, 2010 at 5:49 PM, Pointbreak
<[email protected]> wrote:
> 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
>>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

Reply via email to