Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] ECF Release Train Participation

Hi Scott, Jeff

I think Scott's list applies well to Buckminster as well. We decided early on not to participate in Indigo, much because we're a small company and in the balance between progress and bureaucracy, we tend to favor the former. Eclipse is more bureaucratic than any other open source community and it's just getting worse. There have been more times then one when I've wondered what is more important; strict adherence to rules or developing useful software? The prevailing mindset causing a never ending set of requirements to be added to the release train is one manifestation of this bureaucracy.

I was annoyed the last time new requirements were added because none of them addressed things ever mentioned in the Buckminster community and nobody asked us what we thought about them being added. What's worse, I don't think anyone actually asked the Eclipse community at large if the need for them really existed. At the end, we were just ordered to comply (with an implicated - or leave the train). This year, we choose to leave. The benefit from participating does in no way justify the cost for us.

In the end, I think an open source community should be driven by user input, not by requirements imposed by councils debating wether or not their forum should be open.

Thomas Hallgren

On 2010-12-16 21:36, Scott Lewis wrote:
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 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 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).


ecf-dev mailing list

Back to the top