[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