Ian, sorry for the slow reply. I thought
I had replied to this last week but apparently I didn't. Yes, the idea
here is that we completely automate the tagging process. We pick a branch
and tag everything in that branch as part of the build. The problem of
source changes not always predicting binary changes is nothing new here.
We still have the comparator that runs a check at build time to catch cases
where the binaries change without a corresponding source change.
Ian Bull <irbull@xxxxxxxxxxxxxxxxx> Sent by: eclipse-dev-bounces@xxxxxxxxxxx
10/12/2011 07:03 PM
Please respond to
"General development mailing list of the Eclipse project."
"General development mailing list
of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
Re: [eclipse-dev] Platform/JDT/PDE Committers
Please Read: Git development process
I was having some similar thoughts over the Canadian Thanksgiving
weekend. In particular, I was wondering if tagging process can be completely
removed (or at least automated). We tag (using the current process)
for 5 reasons (are there others?):
1. To double-check our build contributions.
2. To allow work to continue in HEAD without releasing
3. To distribute the workload because CVS tagging was
4. To provide 'reproducible builds' (you called this a
superimposed branch, which is a great analogy).
5. To set our qualifiers properly so if a bundle doesn't
change, the qualifier doesn't change.
Taking these in order:
1. This can be part of the build process. Hudson,
for example, shows you a list of commits since the last build. We could
likely do something similar.
2. IMHO this was never really a good idea. This broke
down pretty quickly when somebody else wanted to commit something to the
bundle and have their changes released. Using a separate branch or
using concepts like git-flow are much better solutions.
3. This is no longer an issue.
4. We would still tag our builds, just not our individual
bundles. Reproducing a build would simply involve building a different
tag. Maybe each team could contribute a branch to the build (master
by default). So, if the p2 team wanted to fix a problem in yesterdays IBuild,
we branch off that tag, fix it, and contribute the new branch. Likely
our build process could start with a tag command (tag IYYYYMMDD-HHMM)
5. This is the hardest one. I wonder if we could
have the Jar comparator do this for us? That is, if a bundle changes
since the last commit, then the qualifier is automatically update. Of
course there is a chicken/egg problem here, but if we don't include the
version field in our Comparator algorithm, it might just work.
Our current git scripts look for new commits, but that
makes the assumption that if the src doesn't change, then the binaries
don't change. That's a little short-sighted, especially when we build
and use our own compiler.
Anyways, just my thoughts after too much turkey and too
On Wed, Oct 12, 2011 at 11:18 AM, John Arthorne <John_Arthorne@xxxxxxxxxx>
Now that we are becoming more familiar
with Git, we should have a discussion about our team development processes
and consider changes that are more suitable to our new tools. In particular,
our existing release process of tagging and map files were designed for
the CVS world where moving code between branches was painful. This process
is not adapting well to Git. For example, you can't reliably checkout a
branch or tag that matches what was in a given build, and there is no clear
way to apply release tags such as "R3_7_1" because no single
commit is guaranteed to represent the built contents of all bundles in
If you think about it, our map files effectively superimposed another branch
on HEAD, with the precise contents of that branch defined by the map tags
for each project. This allowed us to do things like proceed with new work
in HEAD without disrupting rebuilds, or revert a change by altering the
map file (because backing out changes that span multiple files in CVS is
painful). With Git, the more natural _expression_ of this setup is to have
two branches: one for integration builds and one for ongoing work that
we want to test and share with other teams but not submit to a build. It
turns out that there is a popular Git development process similar to this,
called git-flow . I think a simplified form of git-flow would match
our current development practices:
- Two main branches called "develop" and "master"
- All major feature work is first released to "develop"
- Each team periodically merges "develop" into master after performing
their appropriate checks and tests (similar to our current weekly tag and
- Integration builds automatically tag and build the contents of "master"
With this approach each tag on master represents a build. This makes it
easy for anyone to checkout the contents of any particular build even if
it spans multiple Git repositories. This also allows you to revert a build
submission or make a surgical fix for a rebuild without disrupting the
ongoing work in the develop branch. We could also adopt other aspects of
git-flow such as release branches for our end-game period, although I'm
not convinced we need it.
After that long-winded explanation, my request is that all teams think
about their development practices and how they can be adjusted or improved
in our new Git setup. Read up on git-flow and think about how it applies
to our development process. If you're interested you might also want to
look at other processes such as github-flow  for an alternate viewpoint.
Talk about it within your team, and we'll aim to have a general discussion
about it at next week's planning call (Wednesday October 19th, 11am EDT).
If you don't normally join that call, send feedback to your team lead,
or you're welcome to join next week's call to chime in. I don't think we'll
arrive at a perfect development process overnight, but we can start to
make changes and refine it as we go forward.