Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] 2/2 Meeting minutes posted

Hi John,

On 2/2/2011 1:58 PM, John Arthorne wrote:
Scott Lewis  wrote on 02/02/2011 02:34:47 PM:
> Over these four years, ECF has not had any representation on the
> planning council...and never been consulted or even asked about any
> decisions associated with the simultaneous release (e.g. for
> whether/what *our* community is wanting in terms of the simultaneous
> release).

All projects have a representative on the planning council. In your case ECF falls under RT, represented by Tom Watson. Of course you can also represent yourself by bringing topics up here.

I don't really count the RT PMC as representing ECF project (or community) interests...that's one reason why I brought it up here.   I wasn't at the meeting and from the meeting notes I didn't see any mention of this topic at this or previous meetings.  Of course I can't/won't speak for representation of other runtime projects or their community...or other (non-runtime) projects.

> Over the past year, I've been made aware of several other projects
> that have previously participated in the simultaneous release, but
> are reaching (or have reached) the limit on their releng
> resources...and some are contemplating not participating in
> Indigo...because of the releng load, because of the increases in
> required 'todo' items, and perhaps some of these projects perceive a
> mismatch between what the simultaneous release is now requiring and
> what their community is telling them they want.  See [1] for a
> discussion on the ECF mailing list about simultaneous release
> participation, etc).

You made several references to the increasing requirements, but I'm not aware of any new requirements for the Indigo release with any real cost. Maybe you can go into detail here on what you think is new. The only new entry I see this year is asking projects to document the degree to which they support Eclipse Platform 4.1, which can simply be: "no support, no testing on 4.1"

See discussion and thread leading up to it here:

Going into such detail over and over again in various forums doesn't work for that ends up being yet another resource drain.

In fact there has been a shift in the past two years away from the old strict "must do" list of the past. A real effort was made to tone this down, and describe where entries may be optional or not applicable to a given project. In the current document [2], many of the entries are best practices that you aren't required to do.  Several others are standard Eclipse Foundation release requirements (plan IP log, release review, use SUA), that are just stated there for completeness. Maybe we should really pull those out into a separate document to make the true incremental cost of the train over a standard release more clear.

Maybe so.  Frankly I don't know if another document is really the answer though.

I'm not denying there is a cost to participating in the simultaneous release. There absolutely is, although I think the most time-consuming part of that is unavoidable - participating in the builds, producing a repository, communicating on the cross-project list, etc. Every project needs to decide if that cost is worthwhile to their consumers. Releasing at the same time but not in the common repository may in fact be the right answer in some cases.

I think it would be useful for people to read over the discussion here (and postings on same thread leading up to it):

as the distinction between simultaneous release requirements and general project release requirements did come up in that discussion.

> My question is this:  I don't see any indication in the planning
> council notes for yesterday's meeting of *anyone* bringing up the
> issue of projects (like ECF) questioning the utility for their
> consumers of participation in Indigo (given the costs for the
> projects/committers...which seem to continue to go up inexorably).  
> Can this issue get raised on the planning council?  I know for sure
> that I'm not the only project lead that is questioning whether the
> benefits of participating in the simultaneous release (for the
> consumers/community) offset the rising costs on the projects (mostly
> releng...but also IP process of course).   Although others may
> disagree, I think this is not a good sign.

This subject has definitely come up before. I know the Modeling project in particular has many small projects and has felt the pain of participating. Many projects have opted out of doing requirements they didn't feel were applicable or important to their consumers. In the end, I think a project would only ever be *removed* from the common repository if it was breaking the build, or didn't meet requirements that the Foundation sets out for every project release at Eclipse.

Is this stated policy (i.e. not removing projects that aren't doing 'must dos' for the simultaneous release)?...or is this just understood somehow?

> IMHO there is both a material problem and a process problem:  The
> material problem is that smaller/non-strategic run projects are
> generally starved for releng resources, and this is getting worse
> given the increasing requirements for SR participation, as well as
> reduced resources for open source projects in general.  The process
> problem (IMHO) is the (lack of) representation of the smaller/non-
> strategic run projects on the planning council.

I agree on the material problem - I don't know any Eclipse project that isn't starved for releng resources. Anything we can collectively do to reduce that is worth pursuing.

I agree. 

I think there is some progress being made on this front. Wayne has done some great work on IP/CQ tooling to simplify that part of the release process. The change of Eclipse SUA last year was painful for all projects, so this year PDE came up with a mechanism to streamline that process. Recently I think a big cost for all projects has been Hudson and build machine instability. The Foundation took over management of the Hudson server this year to work on reducing that (although there is still room for improvement here).

I'm not sure what the answer is to the perceived process problem. Maybe we need to communicate that all projects are represented via their top-level project on the council, and are most welcome to bring issues up through them. Of course this mailing list is public and absolutely anyone can bring subjects forward for discussion, as you have done.



Back to the top