[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] RC3 rules of engagement.
|
> [...]
> 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 <susan_franklin@xxxxxxxxxx> To: E4
> Project developer mailing list <e4-dev@xxxxxxxxxxx> Cc: E4 Project
> developer mailing list <e4-dev@xxxxxxxxxxx>, e4-dev-bounces@xxxxxxxxxxx
> Date: 07/20/2010 01:08 AM Subject: Re: [e4-dev] RC3 rules of engagement.
> Sent by: e4-dev-bounces@xxxxxxxxxxx
>
>
>
> 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 <Boris_Bokowski@xxxxxxxxxx>
> Sent by: e4-dev-bounces@xxxxxxxxxxx
>
> 07/19/2010 09:52 PM
> Please respond to E4 Project developer mailing list
>
> 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[attachment "pic01096.gif"
> deleted by Eric Moffatt/Ottawa/IBM]
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
>
