On 24.09.2019 17:16, Mikaël Barbero
Groups are rather heavy weight for such a thing. It's
not as if there will be a budget to be allocated or that
anyone will pay fees to be a member of such a group.
I fully agree that the removal of the
planning council from the Bylaws will help clarifying
the Eclipse Foundation position.
As this is a time for a change, what about
transferring all the resources associated with the
planning council to an actual Eclipse project or a
I tend to agree in the current state. I just want to
leave the door open in case some organizations think it
would be better to have a "management" structure on top of
the IDE building/packaging effort.
Currently, simrel's resources (git repos,
Jenkins instance, etc.) are somewhat owned by the
planning council but there is no tangible Eclipse
project associated with those resources.
Well, in the end the planning council
mostly manages SimRel and we already have a SimRel
project of some sort:
So I think a "project" kind of already
That's a git repository without a backing Eclipse
Project. Some people have write permissions on it, but it's
currently done without following the Eclipse Development
Process. The list of people with write permission is managed
by the webmasters, but it should be something public like
for any other project. Also, having a project would let us
benefit from the tooling to identify inactive committers and
be able to do some cleanup.
that's a good point. Although I tend to think that
anyone who wants to be involved should be able to do
so. I.e., do we really actually need a formal
Likewise, the planning council membership
is currently defined in the Bylaws, but when it will
be removed, I guess there will be no more record of
it. IMHO, it is desirable to clarify those points
before the bylaws get changed to have a clear message
to give to the community.
IMHO, we should follow the same rules (ie the EDP) as for
any other repo/project hosted by the Foundation? With the
planning council special status, we could somewhat justify
those resources being outside of any project. Not anymore.
say no, that's just too heavy weight...
Is a project enough? Should this project
be part of a larger initiative like a working group?
Understood. Let's hear what other have to say about it.
would wonder how that will be different from the
committers for the simrel repo; those are the people
doing the real/actual work after all. :-P
I would say that from a day to day
operational point of view, we need at least a project
whose committers are the planning council members.
Well, we could imagine that projects participating to the
simrel don't have write permissions anymore and only
contribute their changes via gerrit patches. But it could
also be the same set of committers as today.
It could be a brand new project or we
could merge the simrel effort into EPP and make it the
central project for the Eclipse IDEs distributions.
Again from an operational point of view, simrel and
epp have been working so closely for so many years
that I think it makes sense to have the resources of
both getting even closer.
In general much of this is a cat herding
exercise. I'm not sure the cats will be more inclined
to be less unruly by virtue of project reorganization.
Also, reorganizing existing infrastructure is work and
therefore has a cost. Who will do that and will the
benefits justify the overhead?
I agree this is cat herding *if* everything can stay the
same with the removal of the Planning Council from the
Bylaws. IMHO, it cannot. The Foundation should not host a
git repo with code outside of any actual project. I'm
proposing to move everything to EPP to avoid the project
creation steps and other tedious tasks and as I already
mentioned because the effort of both simrel and epp are very
The benefit is to be more open and transparent: we get a
project like any other that does *an* aggregation of
projects, with its own rules, with a clear list of
contributors, actual landing pages for the project... Maybe,
tomorrow, another project will want to do something similar
but with other rules, other projects etc... Everybody is
I think the general goal should be to
make things as simple as possible so as to run more
smoothly. Also, to my thinking, anyone who wants to be
helpful with regard to streamlining the simultaneous
release process should be welcomed with open arms.
I agree and I don't think that I'm proposing anything
going against being welcoming to anyone who want to help.
The raison d'être of the EDP (and to have a project
following it) is to be more open and transparent.