Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] Platform/JDT/PDE Committers Please Read: Git development process

> I was wondering if tagging process can be completely removed
Not completely. We should go for a "2 branches" approach, because there's 
another reason for tagging explicitly:

6. To have a well-defined checkpoint for contributions to the I-build.

It's important that teams can decide explicitly what will end up in a 
build. If the build process just starts off HEAD, then the integration 
build input is not controlled any more, and every committer must be aware 
that releasing anything on an I-build day is risky.
- The person doing the build input should have run all tests and should 
only release a state for which the tests are green locally.
- Sometimes, we need "parallel" releases in multiple bundles that need to 
be synchronized.
- Sometimes, we need a rebuild (which should be more stable and thus only 
include changes for the broken contributions).


Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
"General development mailing list of the Eclipse project." 
2011-10-13 01:04
Re: [eclipse-dev] Platform/JDT/PDE Committers Please Read: Git development 


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 it.
3. To distribute the workload because CVS tagging was really slow.
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 

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 

Anyways, just my thoughts after too much turkey and too much wine.


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 that repository. 

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 [1]. 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 
release process) 
- 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 [2] 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. 



eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit

R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 |
eclipse-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe 
from this list, visit

Back to the top