Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [modeling-pmc] [cross-project-issues-dev] Xtext RC4 
Miles,
The Xtext folks are using Gerrit and have in the past asked me to review a few bugzillas closely related to Xtext code I'd previously helped improve.
There is currently a drive in the Architecture Council to simplify the development process and the Eclipse Board and EMO generally support that effort. So I expect next year's release will involve less formalisms and will focus more directly on what really matters... 

Regards,
Ed


On 12/06/2013 7:05 PM, Miles Parker wrote:

I see Ed W's point, but FWIW, just another data point… Mylyn is usually pretty conservative about these things, and this is a really special case, but I closed 22 bugs in Mylyn Reviews in the last 48 hours. :O That was w/ close Project Lead / PMC involvement, but we didn't go through any additional *process* about it.

My *personal* feeling is that EDP serves an important purpose but often the formalisms hard-wire ceremony for the sake of ceremony when it really comes down to is the project team doing what they think is best for the user community. The process is too heavy-weight and when it comes dowwn to it would you rather take the time to fix and test the bug or to research the proper process? Here's a suggestion for a lighter-weight voluntary *practice*: -- add folks from outside your own sub-project to these very late stage reviews.

Or… no, that won't work, because only *two* Modeling Projects (BPMN2 and EMF Compare) are even _using_ Gerrit.. :P

https://git.eclipse.org/r/#/admin/projects/

http://milesparker.blogspot.ca/2013/01/adopting-gerrit.html

On 2013-06-12, at 9:38 AM, Ed Merks <Ed.Merks@xxxxxxxxx> wrote:


Ed,

Comments below.

On 12/06/2013 5:54 PM, Ed Willink wrote:

Hi Ed

If we have a policy we should stick to it.

That's generally the best policy...

If the policy is no longer in force, where is the notification, where is the replacement?

Yes, we'll need to document something.

When the policy was written, there was presumably a concern to minimize the risk of problems during rampdown. I don't see why this concern has changed.

I've never personally had this concern and generally approve whatever project leads think is best.

Committers working on a project inevitably have a very subjective view of how to proceed.

Indeed, but they're also the people most knowledgeable about how best to proceed.

Requiring the external approval has two benefits:

a) the threat of a review makes the committers think much harder about whether it is necessary and check their changes more thoroughly

I wouldn't presume to question Sven's carefulness.

b) the external review should be objective and so provides a better judgement on the balance of risks

I know Sven to be a well balanced person.   I don't know any project leads who don't take pride in the quality of what's being release and take personal responsibility for their decisions.  The thread of doing something stupid that everyone notices is, in my opinion, in and of itself sufficient deterrent.

I committed several fixes myself in the last weeks (and days) without seeking PMC approval.  I presume others are doing the same, i.e., using their informed best (albeit subjective) judgement.

     Regards

         Ed Willink


On 12/06/2013 16:27, Ed Merks wrote:

FYI,

I trust that project leads generally know what's best for their projects and for their downstream users, so I see no general need to police or review their decisions.

Regards,
Ed

On 12/06/2013 12:42 PM, Sven Efftinge wrote:

Ed,

comments inline

On Jun 12, 2013, at 11:47 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Doesn't it need PMC approvals before being resolved as fixed?

No, we don't follow that policy anymore.


 From the yet to be superseded http://wiki.eclipse.org/Modeling_Project_Ramp_Down_Policy/Helios
	• After RC3: Two additional Committers and at least 2 PMC members must review and vote +1 after reviewing the bug for appropriateness and risk.

Two additional committers have reviewed the change.
I don't see why votes from the PMC would help.

After reviewing the commit myself, I see quite a lot of new lines and control flow changes in core code, but the bug description reads as a UI inelegance rather than a killer. So IMHO not really appropriate for RC4.

It's an important missing compiler analysis. I don't think UI is mentioned at all.

Regards,
Sven


_______________________________________________
cross-project-issues-dev mailing list

cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



_______________________________________________
modeling-pmc mailing list

modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3345 / Virus Database: 3199/6403 - Release Date: 06/11/13




_______________________________________________
modeling-pmc mailing list

modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc

_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc


______________________________
Miles T. Parker, M.Sc.
Tasktop Labs
http://tasktop.com
Lead: Eclipse Mylyn MFT, AMP
Committer: Eclipse Mylyn Reviews, R4E, Virgo
http://milesparker.blogspot.com
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc

Back to the top