[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [modeling-pmc] [cross-project-issues-dev] Xtext RC4
|
Hi All,
I have no doubt of the professionalism of EGit guys, but the one week
delay in the Juno SR2 would have been avoided if policies had been followed.
The point is not questioning anybody carefulness. IMO, the problem here
is that some kind of "you may skip the policy" has been granted. That's
a dangerous line crossing ... and to be honest, a little bit
disappointing for those who make efforts in reading and following them.
To move forward on this issue, I agree with EdM point of view. I don't
see the point of making any PMC member to look at bug fixes when they
are not related/involved in the project. Just guessing, but I suppose
that these reviews are based on the mere description of the bug and its
solution, and no real and objective risk evaluation on the changed code
is done after all.
I think that a experienced (let's say 2+ years) eclipse project leader
judgement should be enough, however this must be stated in the ramp down
policy. The policy are meant to be strictly followed, otherwise let's
call them guidelines or whatever you prefer.
Cheers,
Adolfo.
On 12/06/2013 19:15, Miles Parker wrote:
My mistake, didn't notice xtext at the bottom of the list. Good deal!
And yes, there has been a lot of discussion about simplifying EDP around here as well.
On 2013-06-12, at 11:12 AM, Ed Merks <Ed.Merks@xxxxxxxxx> wrote:
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
_______________________________________________
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