> [...] > 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).
Bug 320344 is one of those (https://bugs.eclipse.org/bugs/show_bug.cgi?id=320344). After the editor area is killed, resetting the perspective will not bring it back. Stefan > 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 > > > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
