[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Proposed Change to Eclipse Bylaws

The less projects the better. If there is need to make a separation between Planning Council members and EPP committers - we can have PC members as project leads for EPP ?

On Fri, Sep 27, 2019 at 1:03 PM Ed Merks <ed.merks@xxxxxxxxx> wrote:

MikaÃl,

I didn't realize the repo is kind of an project-less orphan. Then I agree with you that it would be better as a project to properly fit in with existing processes.

Cheers,
Ed

On 26.09.2019 15:44, MikaÃl Barbero wrote:
Ed,Â

See my comments inline

On 24.09.2019 17:16, MikaÃl Barbero wrote:
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 Working Group?
Working 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 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:

https://git.eclipse.org/c/simrel/

So I think a "project" kind of already exists...

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.

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.Â
Yes, 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 definition?

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.


Is a project enough? Should this project be part of a larger initiative like a working group?
I'd say no, that's just too heavy weight...

Understood. Let's hear what other have to say about it.

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

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

WDYT?

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

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

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.



_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


--
Alexander Kurtakov
Red Hat Eclipse Team