[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] ECF Release Train Participation
|
On 12/16/2010 11:34 AM, Jeff McAffer wrote:
<stuff deleted>
Can you say specifically which must dos are things that are above and beyond what you normally do for releases?
It's mostly not a matter of must dos that we don't do for normal ECF
releases, but rather how much is required.
For example: planning...and communication of the plan in required
format. Of course we do some planning for ECF's next release...in
regular conference calls, in the mailing list (here), and via
enhancements and testing. But the simultaneous release notion of
planning is much more heavyweight and formalized.
Release Reviews are similar to planning...of course we do it for (minor
and major) releases, but it's more for the simultaneous release
requirements.
The Communication requirement for the simultaneous release is a
significant time cost. To know this, all one has to do is be on
cross-projects-issues-dev (reading and writing/communicating about the
state of the whole simultaneous release as required).
Optimization must do causes additional releng work for us, because some
of our consumers want to get jars directly (e.g. maven repos).
The Ramp down plan is like planning and release review materials
creation...of course we do it for internal usage, but the release review
requires more.
All the [New this year] are, of course, additional (new) work...for ECF
we are already doing most of these things for our releases, but the
simultaneous release requires additional work of creating, publishing,
maintaining, communicating extra artifacts.
For the plan, release review and IP elements, can you point out things that are unique to the train vs. normal releases?
Any thoughts on how to make the release train builder interaction less taxing would be great. I'm sure that David and crew would love to lower the barriers there.
I'm sure. David and the Buckminster gents (and the builder itself) are
generally great to work with. But there is the inevitable complexity
of coordination among all participating projects, dealing with things
like inter-project interaction (e.g. incompatibilities in bundle
versions across projects), hudson and/or hw/network failures, etc. I
realize that David, Thomas, Henrick and others I'm not aware of bear the
brunt of most of this rather than the project committers/project leads
(i.e. me)...but there is some inevitable time cost to everyone.
<stuff deleted>
Sorry, I was unclear. The topic is "what *extra* stuff do projects have to do to be on the release train vs. doing a normal release". So, specifically, which must do requirements would ECF skip when putting out a normal release. Perhaps those should be reconsidered or do not apply to RT projects in general or...
The new ones this year seem candidates to me. Also the
documentation-creation requirements for planning, review materials (e.g.
why not have the N&N and review materials be the same?), ramp-down, and
perhaps others could be streamlined. I get the feeling from listening
to the reviews that not much of a given project's plan, review
materials, and ramp-down plan are actually viewed by others, but of
course I can't know for sure whether that's so.
<stuff deleted>
Can you be specific about IP elements related to release train participation vs. normal releases? The train should be a collection of releases and should not be adding any IP overhead so perhaps there is something askew.
The CQ-submit-by January need costs us extra time/work. For some
community additions/contributions it's very likely that we won't even
know about the contribution (and associated CQ) by January for the
simultaneous release.
Then there's the work on the contents of about.html, license.html,
feature.xml, etc WRT legal requirements. Although the tooling has
gotten much better (and this has helped...in particular with last year's
requirements change)...thanks to whomever did that tooling.
Ok, that's enough/all I have for now. Hopefully others will contribute
their views as well (ECF commiters and/or other project leads).
Scott