-
Notifications
You must be signed in to change notification settings - Fork 168
Design Doc: Developer Infrastructure
This describes plans for the infrastructure supporting SiteMesh development:
The hosted infrastructure is divided into 2 categories:
- User facing: Simple, understandable resources for end users (website, downloads, documentation, community, announcements)
- Developer facing: Tools to support the SiteMesh team and contributors (source control, issue tracking, wiki…)
There will intentionally be a clear divide between these two as they are for very different audiences.
This document focusses on the developer facing infrastructure only (see Design Doc: SiteMesh WebSite for the other side of this).
- Update Sep 2009: ** We’re on GitHub. Migrated from BitBucket.
Only a handful of developers will be using this, so we don’t need to go overboard – target the needs of the few, over the needs of the many.
Overall goal here is: Productivity
An absolute must is a distributed version control system. The primary reason for this is that I (Joe) do most of my work offline whilst commuting and need full use of the vcs – it’s been a huge productivity gain since switching.
A secondary reason for this is for contributions (see section below).
I have a strong preference for Mercurial (I’m more productive with it), but I’ll tolerate Git ;).
A simple wiki and issue tracking mechanism. This is for sharing information among the developer team, it is not really targeted and end users. Things like instructions for releasing, design proposals, coding guidelines, etc.
Like the source control, it is preferable that this can be used/updated whilst offline.
A developer mailing list for discussion, which will also be notified upon commits, updates to docs/issues, etc.
Whilst the core SiteMesh project will be controlled by the development team, we want to encourage a healthy decentralized eco-system of contributions. To do this, we encourage those who want to work on such contributions (such as improvements to the core system, or non-core add-ons) to do so, without us getting in their way.
Using a distributed version control system, it should be easy for anyone (without our consent) to fork SM, start committing changes to their fork (even with an entire team), and publish the results to the community. Some of these will be useful, some not. Those that look beneficial can later be merged back into the main project.
The process (and encouragement) for this will be clearly documented.
Separating out user infrastructure from developer infrastructure simplifies things. We can use the best tool for each job.
SM3 will be moving away from two components of the existing OpenSymphony infrastructure. Here’s why:
- Java.net (scm and downloads) sucks. Sorry to not have any useful comments here, but if you’ve ever used it you’ll know what I mean. My (Joe) productivity is way lower on Java.net than with other systems.
- The OpenSymphony server (website, continuous build, wiki/issue-tracking) requires maintenance that no-one has time to perform.
The proposal is to move EVERYTHING to a robust managed hosted services where it can be someone else’s problem to keep the infrastructure up to date.
It would be preferable to have one service provide it all, so as not to complicate things.
As a starting point, it MUST support Mercurial or Git. Mercurial has the benefit that it’s much simpler to learn and use on a day to day basis. However, Git seems to have a lot more traction and many projects seem to be switching to it.
The shortlist:
- Codehaus (Git): Pros – excellent community, responsive admins, Java specific tools (continuous build, Maven repo sync). Cons – doesn’t feel integrated, wiki cannot be edited offline, ad-hoc hardware
- GitHub (Git): Pros – excellent community, offline wiki, integrated experience. Cons – uhhh, it’s not Mercurial ;)
- Google Code (Mercurial): Pros – very stable, offline wiki, integrated experience. Cons – Mercurial support is very new and lacking features such as allowing users to easily fork/merge repos.
- BitBucket (Mercurial): Pros – has everything we need, Mercurial, offline wiki, very similar to GitHub. Cons – lesser known.
- Code, Wiki and Issue tracker on GitHub SiteMesh3 project.
- Websites hosted on Google AppEngine.
- Was previously on BitBucket, but switched to GitHub as it has a larger community.
- Mailing Lists on Google Groups.
All complete.