| Re: [eclipse-dev] Integrate more projects into Platform UI? |
IMHO, the point about skill set is a bit over exaggerated. In CDT, we have one set of committers that have access to all components. These components are about as broad as the Eclipse platform components we're talking about here. Committers who don't know much about debug, don't make commits there. It's worked very well for us.There is strength in numbers. I would prefer to see the entire platform as one project to make sure we maintain as much momentum as we can and to do what we can to serve new contributors.Doug.On Mon, Mar 7, 2016 at 10:47 PM, Sarika Sinha <sarika.sinha@xxxxxxxxxx> wrote:Regarding the "debug" component also, I fully agree with points expressed by David.
Thanks & Regards,
Sarika"Szymon Ptaszkiewicz" ---03/07/2016 08:56:33 PM---Regarding the "resources" component, I fully agree with points expressed by David.
From: "Szymon Ptaszkiewicz" <szymon.ptaszkiewicz@xxxxxxxxxx>
To: "General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
Date: 03/07/2016 08:56 PM
Subject: Re: [eclipse-dev] Integrate more projects into Platform UI?
Sent by: eclipse-dev-bounces@xxxxxxxxxxx
Regarding the "resources" component, I fully agree with points expressed by David.
Szymon
From: "David M Williams" <david_williams@xxxxxxxxxx>
To: "General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
Date: 2016-03-05 05:42
Subject: Re: [eclipse-dev] Integrate more projects into Platform UI?
Sent by: eclipse-dev-bounces@xxxxxxxxxxx
> == Feedback desired
>
> What do you think? Should be suggest the move to Platform UI for the
> following components:
>
> - resources
> - debug
> - releng
>
> to the PMC?
I will not speak for 'resources' or 'debug', but for the "releng" component group I would object to a large scale change in committers that have not gone through the traditional path of earning committer rights there. For several reasons:
A. The role of "release engineer" involves special skills and interests that most committers do not have.
B. It sometimes involves access to parts of code or infrastructure that not that many committers should be able to access.
C. Another reason has to do with the goals and philosophy of a component or project. Being a committer implies more than the ability to commit code to a repository -- they also do (or should!) participate in the design, plans, and priorities of the component or project. In my opinion, that can only work well with a cohesive group of like-minded, similarly skilled people.
D. Also -- you do not want to turn me loose on the UI and Text code! :)
E. There are parts of "release engineering" that do not show up in "Git commit" activity, so I think it is a disservice to people like Markus Keller not to acknowledge his significant contributions to release engineering.
F. I think our current system has a good division of labor. The "releng component" is focused on (and responsible for) the production of enterprise quality builds; while all committers can do "quick even-if-slightly-incorrect builds" with Gerrit and Hudson. I am quite happy to continue to maintain that division of labor and I would not like to see Gerrit/Hudson support for the whole team become part of my formal (or informal!) responsibility. (Though always glad to help if I can.)
From my point of view, there is not a current problem that needs to be solved.
You mention two things specifically:
> several minor cleanup patches are currently pending in Gerrit since a while.
Most of them from you. :) I have no doubt these are well intentioned, but I question the "cost/benefit" ratio. Substantial contributions that solved problems or provided material improvements would receive higher priority. I think these cleanup patches are getting the attention they deserve.
> Also I think it would be helpful if David could fix releng related issues directly in sub-projects.
Please don't direct my work or increase my workload. I have enough people doing that for me as it is. :)
= = = = = = = = = = = = = = = = = =
None of the above negative attitude is to say additional contributions or committers is not desired and welcome -- that would be great. I would just prefer the traditional route to them earning commit rights.
= = = = = = = = = = = = = = = = = =
There is an exception, of sorts, to all I said above. In the 'eclipse.platform.releng' repository, there are some modules that more rightly belong in the repository with the rest of their domains. The obvious ones are
org.eclipse.ant.optional.junit
org.eclipse.cvs
org.eclipse.help-feature
org.eclipse.rcp
org.eclipse.rcp (feature)
I would have no objection to those modules moving to more appropriate repositories.
= = = = = = = = = = = = = = = = = =
There is a lot more I could say, but I think I have already been too wordy.
I hope have answered your main question.
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev