Susan, I've been working a variety of these issues but agree that it's time to really tighten down the screws like in a 'real' RC3...
I'm a big +1 for the layout manipulation issues that the one thing that *has* to work is 'Reset', barring any other fixes. If we can tie the layout into a shape that cannot be reset then that's a 'high pri' to fix (more so even that fixing the mechanism that got you there). Transparency is, I think, the key...I don't want to be pulling a Jobs..."Just don't use it that way"...;-) Eric From: Susan Franklin McCourt <[email protected]> To: E4 Project developer mailing list <[email protected]> Cc: E4 Project developer mailing list <[email protected]>, [email protected] Date: 07/20/2010 01:08 AM Subject: Re: [e4-dev] RC3 rules of engagement. Sent by: [email protected] 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: Boris Bokowski <[email protected]> Sent by: [email protected] 07/19/2010 09:52 PM Please respond to E4 Project developer mailing list To: E4 Project developer mailing list <[email protected]> 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 [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev[attachment "pic01096.gif" deleted by Eric Moffatt/Ottawa/IBM] _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
