Re: [eclipse.org-planning-council] 2/2 Meeting minutes posted

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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.

> 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"

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.

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.

> 
> 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.

> 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 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. 

John

[2] http://eclipse.org/indigo/planning/EclipseSimultaneousRelease.php