a diverse project, there are many bosses and they don’t report to each
Every project has a lead and a PMC.
They must work together. If not, something is broken and needs to be fixed
just need to make sure the projects have strong leadership to pull it all
together. I just wanted to add the data to the mix.
Definitely. The prime directive for
the projects (leadership) must be to deliver the best value they can provide
to the community. The products/companies can then decide which releases
to adopt. This is nothing new. For example we at IBM don't consume every
release/SR. We have clearly defined schedules and rely on the open source
deliverables. In order to make that work it is essential to have public
release plans where projects indicate whether they participate in a release
with new features or just bug fixes.
Doug Schaefer <dschaefer@xxxxxxx>
Eclipse Planning Council
private list <eclipse.org-planning-council@xxxxxxxxxxx>
Shorter release cycles (cont...)
Yes, but my scenario was more driven by
a committer team that didn’t work as a unit. On a diverse project, there
are many bosses and they don’t report to each other. The train helped
me bring the different factions together and helped us work as a unit.
And ironically enough, it was because the releases were yearly and people
didn’t want to miss it. I kinda loose that hammer if we release too often.
You may end up with committers taking a release off knowing they can jump
back on for the next release in three months. It’s a strain on the rest
of the team.
It something we can over come, and sometimes
face anyway. We just need to make sure the projects have strong leadership
to pull it all together. I just wanted to add the data to the mix.
We may want to require projects that wish
to release on the train to publicize their release schedule, and give an
appropriate heads-up for any changes to the schedule. This may help with
the scenario Doug just described, but also help when a component has a
lot of consumers on the train.
On Wed, May 6, 2015 at 11:00 AM, Doug Schaefer
Indeed a great discussion and again Thank
You all for contributing and being open to the idea. I feel something great
coming out of it. :)
First for Ian’s question, yes, one repo
at a fixed URL. It’s a requirement I have of my customers to be able to
update from release to release. Our schedule is somewhat random and driven
by other forces so they don’t really know which Eclipse Platform release
their getting unless they look hard at it. They’d be pretty confused if
they could upgrade to some but not others.
I also wanted to add a bit of history that
not many people know about other than long time CDT committers that were
around at the time or heard my old grampa stories over CDT Summit beers…
Before CDT joined the train, our release
strategy was a mess. And it was really the diversity of our project that
caused it. We had two major players, I worked for one and I now work for
the other (hint, hint). One of them had a product based on CDT and that
product delivery schedule was driven by the platform it supported. The
other was trying to release in sync with the Eclipse platform so it could
feed into the product stack that that company was building on top.
The problem crept up with the two schedules
didn’t match. What ended up happening was that CDT released every time
one of these two stacks needed a release. Unfortunately, the committers
remained focused on their product release and ended up not helping
the other out when it was time for them to release. In fact, on one famous
occasion, the one who had a few months before their release added a new
feature two weeks before the other was going to have their release. Luckily
we had great leaders back then and the commit was reverted.
It was a complete mess and as we started
to grow committers from different ISVs, we started to ask, do we release
every time one of them needed a release. That would have been complete
chaos. So when the idea of the train came along I used the opportunity
to standardize our releases and there was really little fuss because everyone
knew that was the right thing to do and the answer was handed to us on
a silver platter.
So while the idea of 3 month cycles is
a great advance forward, I do fear the unintended consequences. If projects
aren’t releasing on every train release, then they have a decision to
make on which releases to release on. And what drives that decision? The
old train gave us an automatic choice that we didn’t have to think or
fuss about. Sometimes that’s a good thing.
I really like the direction we are headed,
and the idea of a release once per season would make us much more agile.
One technical thing we need to consider
is how we will structure the repository. Currently we create a new composite
repository every each (for the June release) and add the SR1 and SR2 when
they become available. In the next year, we wipe the slate clean and start
again with a fresh repository.
If we are moving away from a Release +
SR1 + SR2 and moving towards a rolling release, then I don't think we should
clear the repository each year. This will make year-to-year updates impossible.
One suggestion is to create a single composite
repository, and store the latest N releases (N=4?). When N+1 is released
we then drop the oldest release from list of children (of course we could
maintain the update site forever at a permanent URL -- but that would be
part of our retention strategy which we have not yet discussed).