Mozilla.com/Workflow-improvements: Difference between revisions

← Older edit

Mozilla.com/Workflow-improvements (view source)

Revision as of 17:57, 18 January 2011

1,238 bytes added , 18 January 2011

no edit summary

Jlongster

Confirmed users

508

edits

@@ Line 30: / Line 30: @@
        -> fix bad? -> remove push-needed -> reopen bug -> start bugfix cycle
-The bugfix cycle looks pretty standard.  The rollout cycle is a little bloated, but that's mainly because the staging branch isn't currently being used, but changes are still being pushed through it.  Also note how there isn't a step to rollback a bad bug on the live site, but that's as simple as reverting the files in SVN on the production branch.
+The bugfix cycle looks pretty standard.  The rollout cycle is a little repetitive, but that's mainly because the staging branch isn't currently being used.  This cycle gets laborious when there are many bugs.   Also note how there isn't a step to rollback a bad bug on the live site, but that's as simple as reverting the files in SVN on the production branch.
 === Improvements ===
@@ Line 46: / Line 46: @@
 * SVN's handling of branches.  Revision numbers aren't kept in sync at all; each branch has completely separate revisions (merge tracking is coming it seems, but it's a big hack with bad edge cases right now).
-** Pushing code between branches frequently merges several revisions into one with completely separate numbers.  The result is that the user must manually track the movement of code by including the origin branch and revision in the new commit (every single time).
+** Pushing code between branches frequently merges several revisions into one with completely separate numbers.
+** The user must manually track the movement of code by including the origin branch and revision in the new commit (every single time).
 ** In general, the user has to perform a lot of careful tracking of revision numbers for bookkeeping.  This is prone to error.
 ** Hard fix: Switch to git
@@ Line 57: / Line 58: @@
 == Dramatic Proposal: Git ==
-Git solves a lot of this, and makes it easier to sleep at night (ok, maybe not).  We will reap the benefits for years if we switch to git now.  It will be easy to move code around and rationalize about what's going on, and there a lot of cool tools to show you branching/merging statuses, history, etc.
+[http://git-scm.com/ Git] solves a lot of this, and makes it easier to sleep at night (ok, maybe not).  We will reap the benefits for years if we switch to git now.  It will be easy to move code around and rationalize about what's going on, and there a lot of cool tools to show you branching/merging statuses, history, etc.
 We will also be more in sync with the other teams at Mozilla.
@@ Line 93: / Line 94: @@
 * Since it's all done for you, git keeps a very good history of what went on.  This lets us generate cool graphs and statistics about the codebase to see what's going on and helps us to improve our process more and more.
+=== Releases & one-offs ===
+A big problem with mozilla.com is that there is a high number of small changes which always need to go out ASAP, as well as larger changes that trickle in over time.  We want to start doing rolling releases ever 2 weeks, with the occasional one-off.
+The above process describes what would happen with a one-off, so a one-off changes are easily supported.  For a release cycle, the developer would merge his/her bugfix branch into master but not push it out.  When time comes to publish a release, all it takes is publishing the master branch (an easy  git command).
+=== Localizers ===
+One problem is that localization contributors submit patches through SVN, and it wouldn't be good to tell them to use git.  However, [http://www.viget.com/extend/effectively-using-git-with-subversion/ git-svn] lets us pull in commits from SVN where localizations are coming through.
 === Other notes ===
-git-svn is a great tool which comes with git.  It's a bridge between git and SVN that works very well; it actually converts git commits to SVN revisions and back.  I've been using it to work with the mozilla.com codebase.  We can use it to convert the whole SVN repository into git.
+The above process is just an idea, there are many ways we could use git.  We could publish commits on the master branch in the centralized server, but then we need a separate process to support one-offs because you can't publish only part of a branch.
+[http://www.viget.com/extend/effectively-using-git-with-subversion/ git-svn] is a great tool which comes with git.  It's a bridge between git and SVN that works very well; it actually converts git commits to SVN revisions and back.  I've been using it to work with the mozilla.com codebase.  We can use it to convert the whole SVN repository into git.
 The biggest obstacle will be the learning curve for people who don't know  git and making the transition easy, if we did this.  I think we'd gain a lot of benefits though.