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:
http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg04684.html
Going into such detail over and over again in various forums doesn't
work for me...as 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):
http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg04684.html
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.
Right.
Scott
|