(no subject)

[fu]

I did a quick run through of a changeset submission process with exor674, one for Mercurial and one for Git.

Assumptions:

• pulling from the dev branch back to stable is roughly equivalent between Git and Mercurial, or is easy enough to work around on the committer side, so this is not shown here.


• we want to move away from asking for patches, to pull requests which include more context


• we need to concentrate on the branching workflow. We will encourage branching even for small bugfixes or feature development, to make it easy for devs to pick up a different bug once they have submitted a pull request for what they are currently working on.
  
  This is particularly important because we get devs that happily submit their first patch, and then get frustrated trying to clean up their repo when working on their second. This may also be useful when we discover that tweaks need to be done on review. Instead of doing:
  
  
  
  1. clean up old/current work
     
  2. grab patch from zilla or a saved file and reapply
     
  3. do tweaks
     
  4. generate a new patch containing the original patch + changes requested
     
  
  We might do:
  
  
  
  1. save current work on current branch
     
  2. switch to previous branch
     
  3. do tweaks
     
  4. submit pull request again, with the tweaks as a separate commit
     
  
  Thus the emphasis on branching in this run through.


• we're trying to analyze the core features to determine whether they can work the way we need them to, so we've left github and bitbucket out of the equation (except as ways to make the code public)

( mercurial workflow using bookmarks )

( Git workflow using git branches )

Summary of what we found:

• When using Mercurial bookmarks, we ran into an odd(?) issue where we lost track of where we were branching from (what would, in git, be the branch "master"). I'm assuming this is a bit of a workflow thing, and we can work around by creating the new bookmark upstream or master, so we could get back to the point in our repo before we started making any changes


• Same issue, but this time from the committer side? or, since we've merged at this point, and won't need to eep track of bookmarks, perhaps less of an issue?


• What am I doing when I pull then remove the bookmark? I ... managed to merge, right? That's what I did?


• Commit messages are now an issue. We standardized around a commit format containing the bug id, commit message, and patch author and enforced it by having the committer supply the commit message.
  
  Now, we'll either need to enforce a strict policy on commit messages before accepting the commit, or have the committer amend the commit messages beforehand. Other options are to make the changelog hook smarter (detect things of the form "Bug #"?), use a "changelog_bot" for all commits. We might also want to look into having the committer sign off the commit.
  
  *Finally* this might become a moot point, depending on what's available to us from github/bitbucket that will let us put stuff into the changelog community.


• need to determine what happens if you try to amend someone's commit in Mercurial by running it through MQ in order to fit guidelines above *points up*. At a guess, we'd end up with a dangling commit that would need to be stripped out of the submitting dev's repo, because the changeset hashes would no longer match


• git index! oh git index. You might be a pain. The question is, are you a pain that can be hidden away?


• it's much easier grokking branches, IMO, than bookmarks, because there's never any risk of forgetting where "master" is.


• git lets me do a merge commit, in order make sure that the bug number is mentioned in a related commit. *Might* be a bit of a moot point if we end up doing a rebase instead of a merge