[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] ECF Release Train Participation
- From: Thomas Hallgren <thomas@xxxxxxx>
- Date: Fri, 17 Dec 2010 11:09:25 +0100
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.6
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.
On 2010-12-16 21:36, Scott Lewis wrote:
On 12/16/2010 11:34 AM, Jeff McAffer wrote:
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.
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.
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).
ecf-dev mailing list