Re: [e4-dev] RC3 rules of engagement.

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

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 <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