I am aware of these problems, in fact I started a discussion about them in 2008. Somebody else provided a continuum build server back than (Jeremy Thomson?), that had none of these problems. The specific exceptions thrown by teamcity show up on google searches with other SVN servers as well. What I was trying to say is that, since you are moving to other buildservers in your proposal, that will more than likely solve the sf<->teamcity problem. Moving to github may be a good thing, but is really not related to the problems you described, and I do not see any reason to couple the decision of a move to github to the other proposals you make for the build environment. But yes github is nice, seems to be well received, and I haven't touched wicketstuff in over a year, so feel free to ignore this rant.
On Mon, 19 Apr 2010 21:13 +0200, "Martijn Dashorst" <[email protected]> wrote: > 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 >
