[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] RC3 rules of engagement.
|
We can discuss at the meeting, but since east coasters have a 3 hour head start...
Just wanted to say that at this point, I think we should err on the side of restraint.
I saw bugs today where a lot of stack manipulation (max/min/perspective switch) scenarios can get you in trouble.
I don't think we have the time to sort these out...I feel that we are just as likely to introduce regressions by being too aggressive in fixing things. For example, generic model issues like part activation, etc. etc...we have to decide soon that the devil we know is better than the devil we don't.
We need to have a good story on what the user should do when things seem "shaky."
For example, I saw problems with "reset perspective" and this bothers me because I would be inclined to reset a perspective if funny things happen wrt view/editor mixing, perspective switching, etc. If "reset perspective" is really implemented underneath as "reset, kill the deltas.xml, etc. etc...."...we need a good path for cleaning up a broken model instance.
So I think we need to focus on:
- having a safe, reliable "clean things up" action the user can take (or do it for them if we can detect when we've hosed the model)
- fix problems that persist after an exit/restart
- first impression/broken workflows where we can prove the fix is pretty localized/specialized
The temptation is to keep on fixing, fixing, fixing....because compared to 3.6 stability we don't look good.
But we are better off shipping with problems we can explain than keep tweaking and not really know what we have when we ship.
susan
Boris Bokowski ---07/19/2010 09:53:15 PM---Paul Webster wrote on 2010/07/19 20:23:07:
![]()
| ![]()
| ![]()
To: E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
cc:
Subject: Re: [e4-dev] RC3 rules of engagement. |
Paul Webster wrote on 2010/07/19 20:23:07:
> OK, now that we're in RC3, we need two +1s to make the fix (and
> technically 2 committers must code review)
> ...
>
> Boris, is this what we want to do?
How about: at least one review from another committer, and a +1 from Susan, McQ, John, or me. All of this prior to checking in the change.
I suggest we use the Platform UI meeting (Tuesday 11 am Eastern, see http://wiki.eclipse.org/Platform_UI) to coordinate which bugs we will be working on.
We probably need rules for changes after RC3 as well, I would suggest: two code reviews from other committers, and PMC approval (likely McQ or John).
Boris_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
![GIF image](gifOzSB48eHgY.gif)
![GIF image](gifl0RgqmWw_x.gif)
![GIF image](gifupCRuOb2Eb.gif)