New Workflow and Repo Structure for Mozmill
Clint Talbert
So, this was our first big release using github. And well, there were a
lot of things that were really tough to do using that tool. We've read
a lot more about how to do this properly and we've decided on another
strategy for the 1.5.1 release that looks like it is going to be much
better, simpler, and more efficient.
This is thanks to Vincent Driessen's great post on github workflow. You
should read that first: http://nvie.com/git-model
And now here's how we're going to adapt that basic idea:
* Vincet's "develop" branch is our "master" branch
* Vincet's "master" branch is our "stable" branch
* Vincet's "hotfix" branch is our "hotfix" branch
* We do not currently have a release branch.
We have to modify this slightly in order to adjust to our own reality of
the state of our code.
* Stable - this branch will contain the current "shipping release" of
the codebase. It currently contains the 1.5 codebase.
* Master - this is our development branch for the next big feature
release - 2.0
* hotfix* - these are short-lived branches that will branch from the
stable branch and will merge back into both "stable" and "master" This
is where we will do 1.5.1 development.
= FAQ =
* I have a change that needs to be checked in to 1.5.1, where does it go?
--> It goes into the hotfix-1.5.1 branch
* How will my 1.5.1 change get into the "master" branch so that it is
included in 2.0?
--> It will be merged into master upon the completion of 1.5.1 with all
the other changes
* If I'm landing a change for 2.0 where does it go?
---> On master. That doesn't change.
* What happens when we get ready to release 2.0?
---> A release-2.0 branch will be created, it will branch from master.
It will merge back into master and stable upon the release.
* Who does that merge?
--> The unlucky guy that releases mozmill for y'all. aka me.
* Who checks in to mozauto/stable?
--> No one. We only merge our release and hotfix branches into it. And
we do that as part of the release process.
* Where did all the feature branches on mozautomation/mozmill go?
--> I removed them as they were cluttering up the branch list. They are
still available on your local fork.
* Why is 1.4.2 still in the branch list? Isn't it done now that we have
the stable branch?
--> Yes, it is done. I kept it just in case something goes horribly
wrong. But so far, things seem ok. Once I'm confident we are good,
I'll delete it.
If you have other questions, don't hesitate to ask.
And in case it wasn't abundantly clear, if you have a change that was
+'d for 1.5.1, you are clear to land on the hotfix-1.5.1 branch.
Cheers,
Clint
Henrik Skupin
Hey.
> This is thanks to Vincent Driessen's great post on github workflow. You
> should read that first: http://nvie.com/git-model
I read that and I'm impressed! That looks like the perfect strategy. And
I really really love the "--no-ff" option for git merge, which I haven't
known before. That's exactly what I had proposed before with a single
commit per feature. :)
> * I have a change that needs to be checked in to 1.5.1, where does it go?
> --> It goes into the hotfix-1.5.1 branch
When do we create that branch? Directly after a release and when we know
we definitely want to have another bugfix release?
> * What happens when we get ready to release 2.0?
> ---> A release-2.0 branch will be created, it will branch from master.
> It will merge back into master and stable upon the release.
When you create the docs please also mention that no no features are
permitted from this point. That's a great benefit we should strictly follow.
> * Who does that merge?
> --> The unlucky guy that releases mozmill for y'all. aka me.
Congrats! :D
> * Who checks in to mozauto/stable?
> --> No one. We only merge our release and hotfix branches into it. And
> we do that as part of the release process.
One question I have here. I would tend to say that we shouldn't stop
support for 1.5.x once 2.0 has been released and is the latest version
on the master and stable. Switching to 2.0 will have a big impact on
existing tests and it can take a while until developers have time for
and also to finish that work. That could mean that 1.5.x could live
beside 2.0 for a couple of months and another hot fixes could be
possible. How would you manage that? There is no solution given in the
blog post. We cannot do something like 1.5.3 -> 2.0 -> 1.5.4 -> 2.0.1.
> * Where did all the feature branches on mozautomation/mozmill go?
> --> I removed them as they were cluttering up the branch list. They are
> still available on your local fork.
And that's the way how it should work. No more feature branches on
mozauto. Yay!
> * Why is 1.4.2 still in the branch list? Isn't it done now that we have
> the stable branch?
> --> Yes, it is done. I kept it just in case something goes horribly
> wrong. But so far, things seem ok. Once I'm confident we are good,
> I'll delete it.
So Heathers check-in for the Jetpack issue is now accidentally also a
part of 1.5? I was waiting with my enabledScope patch and haven't
checked it in. Please advice how to proceed here.
> And in case it wasn't abundantly clear, if you have a change that was
> +'d for 1.5.1, you are clear to land on the hotfix-1.5.1 branch.
Thanks for your work in cleaning up all that branches. I'm sure we have
a good basis for the upcoming 2.0 and maintenance patches.
--
Henrik Skupin
QA Execution Engineer
Mozilla Corporation
Henrik Skupin
> So, this was our first big release using github. And well, there were a
> lot of things that were really tough to do using that tool. We've read
> a lot more about how to do this properly and we've decided on another
> strategy for the 1.5.1 release that looks like it is going to be much
> better, simpler, and more efficient.
Can we please get this up into the wiki? All that stuff should probably
accessible from:
https://wiki.mozilla.org/Auto-tools/Projects/Mozmill/Proposed_Workflow#Github_workflow
Henrik Skupin
> * I have a change that needs to be checked in to 1.5.1, where does it go?
> --> It goes into the hotfix-1.5.1 branch
>
> * How will my 1.5.1 change get into the "master" branch so that it is
> included in 2.0?
> --> It will be merged into master upon the completion of 1.5.1 with all
> the other changes
On Bug 593504 [1] a question came up exactly about this specific part.
As what I have seen a couple of patches have been landed on both
branches and some not. Currently it is really confusing and we should
find a way to make it better with 1.5.2.
So what should be the right action for 1.5.1? Do we want to continue and
checkin patches into the hotfix-1.5.1 and master and start with the
merge process with 1.5.2?
Thanks,
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=593504
Mikeal Rogers
--
You received this message because you are subscribed to the Google Groups "MozMill Developers" group.
To post to this group, send email to mozmi...@googlegroups.com.
To unsubscribe from this group, send email to mozmill-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozmill-dev?hl=en.
Henrik Skupin
> * How will my 1.5.1 change get into the "master" branch so that it is
> included in 2.0?
> --> It will be merged into master upon the completion of 1.5.1 with all
> the other changes
As talked with Clint yesterday we will have weekly merges. He will be so
kind in doing the merges. So if you have a reviewed patch only check it
into the hotfix-1.5.1 branch. Mark the bug as fixed and set the
whiteboard entry "[needs-landing-2.0]". That way we can easily track
which patches have to land on master and it will help us with
verification work. Once the patch has been landed the whiteboard entry
will become "[mozmill-2.0]".
Thanks
Clint Talbert
a while, busy working behind the scenes.
Will update the wiki as soon as I can.
Clint
Henrik Skupin
As it looks like this way isn't a really productive one. Today bug
606558 has been filed because a feature differs between the hotfix-1.5.1
and master branch. We should really re-think the handling of the merge
process. Especially that the weekly merge didn't happen for two weeks
now. The code will differ even more as longer we are waiting. Personally
I don't see it as a good solution anymore.
My proposal is that we should check-in code into the master immediately
once a patch has landed on the hotfix-1.5.x branch.
What do you think?
Jeff Hammel
There are various reasons why this is hard:
- currently, as will always be the case when code paths diverge (APIs
different or code is significantly refactored), a given patch cannot
be landed on the master as landed on the release branch
bug 606558 is a good example of this. the reason why i filed it as
opposed to merge from hotfix-1.5.1 is now in master logparser deals
with command line flags in a completely different place and in a
completely different way than it does in hotfix-1.5.1. logging is a
pluggable event. command line handling has been completely
restructured. While I'm sure Clint, since he takes a lot on himself,
would probably have done this himself when landing, it is neither a
fair nor sustainable distribution of labor to have one person
responsible for reconciling all changes when the API drastically
differs.
- we could tag multiply in bugzilla whether something needs landing in
the release branch as well as the development branch. however, this
has considerable overhead. our current use of bugzilla does not
support this, so we'd have to come up with some better methodologies
there. we would have to submit multiple patches save in those rare
instances where the code lives and functions in the same place and way
on the release branch as on the master
- we could also file a different bug in mozilla for dealing with
release and master. this is also annoying.
- many of the fixes done on a release branch are not directly
applicable to master. master may have fixed the problem a different
way, made a problem obsolete, or otherwise caused a difference in
intention between the branches. merging, regardless of how good your
tools are, will always require thought and intelligence as one must
consider the intention of the code
- landing things multiple places, even if there is no/little conflict,
is prone to human error. while i've been the worst offender here, i
have certainly not been the only one. i think most of the mozmill
devs have either forgotten to land a commit multiple places or have
had problems landing a commit multiple places. Unless we're ready to
invent a tool to solve this (signs point to no), then there will
always be this issue. Plus, note, that your commits will break how
git works. You're copying leaf nodes to other branches. git, afaik
(harth?) has no way of telling whether these commits are identical,
and if there is even a tiny change, then all hope is lost
Being a grunt developer that wants to worry as little as possible
about VCS or release management, I would have a somewhat fascist
workflow resembling in cartoon form the below:
- development takes place on master
- master is kept stable; you write tests to enforce this and have
continuous integration as a safety net
- when a release is required or desire, you cut a release branch from the master
- NO NEW FEATURES EVER GO ON TO THIS RELEASE BRANCH! you can --
hesitantly -- merge features from master, but only release-specific
fixes should be committed there first (non-release-specific fixes
should go in master and be merged to release); ideally, you will have
zero release specific fixes, save things like setting version numbers,
etc
- rinse and repeat
This allows maximum forward movement. However, I've traded off
flexibility because, again, I'm just a grunt developer and like to
solve these sorts of problems with a hammer. The real point is there
are trade-offs no matter what the approach is. With our approved
workflow, we at least have flexibility.
I am content to give the current system more time to settle itself out
and not worry about rigorously enforcing any particular methodology.
I don't think there is one of us who can claim that they have been in
conformance to any set of rules all the time. I'm sorry I filed the
bug. I should have just left things broken. It didn't affect my work
and, knowing all of the above, I thought I was doing the right thing
by fixing a problem that I found. I don't think we can account for
all possibilities ahead of time. If really, we *can* develop this
methodology, we *should* make it programmatic, not only for our own
case but because this is one of the great problems of computer science
</rant:philosophical>
Jeff
> --
> Henrik Skupin
> QA Execution Engineer
> Mozilla Corporation
>