[Potlatch-dev] Codebase and git

[Richard Fairhurst]

In the near future it looks likely that P2 will become the default 
editor on osm.org.Consequently we need to move from the 'rapid 
development' stage to the 'mature code' stage, and enforce a bit more 
rigour in the codebase - "with great power comes great responsibility" 
and all that. :)

In particular, two absolute, non-negotiable rules:

1. At any given moment, the main P2 codebase needs to be of a quality 
deployable on osm.org.
2. The main codebase must always compile without errors or warnings 
(using the recommended compiler setup).

Rule 1 means, for example, no '?' icons and no partly-working 
functionality. If an order comes down from on high (OSMF) that "P2 needs 
to be able to do this" or "P2 must stop doing this", we need to be able 
to react instantly, without spending time fixing up half-completed stuff 
or drawing icons until we have a deployable version once again.

In conjunction with this, we will be moving from svn to git (as used for 
the core Rails port). This will allow people to hack on their own 
improvements in parallel until they're ready for integration into the 
main codebase. Andy will be posting a nice git tutorial to the list in 
readiness (he doesn't know this yet ;) ).

To reiterate, this absolutely isn't meant to stop people working on cool 
new things, but rather to make sure that osm.org always has a stable, 
predictable editor. git should facilitate both of these: it's good news 
for all of us.



To pave the way for P2 becoming the main editor, we need to freeze 
functionality for now. There's some cool stuff being committed, but 
right now, anything that is not either (a) fixing an existing P2 issue, 
or (b) bringing P2 up to feature parity with P1 (e.g. i18n and 
history/revert), is not an immediate priority. As it takes up time for 
others to learn and review, and may introduce new issues in itself, it 
could be a distraction from the pressing task - and we really shouldn't 
have to make this choice, which is why we're moving to git.

r25368 should be the base for the functionality freeze. That's certainly 
not to say that we abandon the stuff that's been done since then, but we 
will separate it into the essentials (a and b above) and the 
enhancements (new functionality) as part of the move to git, and then 
move the new functionality into the core code as and when it's ready.

cheers
Richard