[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-ocl.dev] Re: MDT OCL Project Plan for Helios (take 2)
|
Hi
Another glance through the RTF mailing list suggests that
a) we should treat some OMG Issues as Bugzillas and do what seems right
b) we should read them carefully; some have very detailed discussions on
whether
Set{} means Set(Void){}
I'll take a shot at another XLS.
I reduced the 91 bugs to 77, because I feel that a mature projhect
shoulkd not leave bugs
open for more than six months. We should plan to do all 77 (ok 67 if you
find 10 you hate)
and perhaps fail on a few. If we don't plan to do them at all we should
consider WONTFIX.
I'm happy to have theme bugs such as "OCL 2.1 compliance" with
dependency linkages,
but they need to be done today if they're to go in the MDT plan. I don't
have time.
I agree that API particularly overtly external API changes as soon as
possible.
Regards
Ed Willink
Laurent Goubet wrote:
Hi Ed,
Tedious indeed ... Good work on this!
I tend to join Adolfo on this : We should probably focus on everything
that involves API changes ASAP in the process, especially since we're
not full time on this and as the Helios release closes in, we might
have _a lot_ of bugs to fix when adding those of each projects together.
As I already mentionned, I don't feel comfortable at all with
parsers/grammars. I'd rather focus on the evaluation itself
(evaluation visitor) and bug fixes... Still need to make a lot of
changes to fix failures before the patch of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=287977 can be commited.
Laurent Goubet
Obeo
Adolfo Sánchez-Barbudo Herrera a écrit :
Hi Ed,
Thank you very much for this table. It seems to have been a tedious
work...Good work.
>From my point of view, I think that, for MDT-OCL 3.0.0, the team
should focus on every point which may involve API changes:
- LPG v2 migration.
- OCL 2.1 adoption (and current MDT-OCL required corrections)
- Refactoring of obscure functionality or just to improve the
implementation in some way (design, performance, API clean-up, etc).
New features / enhancements which may require too much time should be
deferred (which obviously excludes ready features, such as registry,
editor, etc)
The problem is that I'm not sure that all changes to achieve this are
properly related in bugzillas.
What about including a more coarse-grained bugzilla (i.e, OCL 2.1
adoption) which could depend/point to fine-grained one? So, we could
have an static "small" plan which won't change, and in the other hand
we will be able to "change" it while creating new bugs and creating
the dependencies from the coarse-grained bugzillas to them. In any
case, I agree that this is a plan, and we should clarify as soon as
possible what are we going to implement.... It's just an idea to
think about ;)
About responsibilities, I also feel comfortable with
grammras/parser/analyzer. So I guess that I could get library's
bugs.... and work on/revise all those related to them:
parser/analyzer/ast.
Cheers,
Adolfo.
Ed Willink escribió:
Hi All
I've gone through all the open Bugzillas. After closing a couple and
opening a couple we now have only 91 bugs! Very tractable.
The attached spreadsheet gives my analysis. Columns A-L from Bugzilla.
-----------------------
Column M; what I think we should do. 14 to Defer possibly till after
Helios.
Column N; what I think could be a plan theme (not introducing any
new themes).
I don't really mind which bugs appear in the plan. I'm not that keen
to inflict 77 bugs on the plan, so I've refrained from
re-annotating each bug. I'm happy just to set a Helios milestone on
the 77 and --- on the other 14. However if we plan to
do 77 perhaps we should put them all in.
How many of these do we want in the plan?
I don't intend to change Kenn's plan without further discussion.
-----------------------
Column O; the relevant sub-components.
Some of these like ui and tests could be keywords. Could the others?
Perhaps they could be Whiteboard, but with no obvious definition of
Whiteboard, I don't know what tools will get confused.
I think that the Column O names can be transferred to tags, so that
you can just search on 'library' and get all the library bugs.
A note on some of the less obvious components:
ast - requires a change to OCL:.ecore/OCL.uml and associated code
console - the old interpreter example
environment - the shared heart of the analyzer/validator/evaluator
support
future - brand new functionality
internationalization - some annoying hand-me-downs
language - areas awaiting design and associated OMG issues
I regard myself as mainly involved in/responsible for analyzer, ast,
editor, language, parser, registry, ui with some shared involvement
in environment, tests and one day synthesis.
Any volunteers for the other sub-components.
Is use of tags for the sub-components a good idea?
If the team is happy, I'll tag every bug as per Column O and change
the targets to Helios on Wednesday.
Regards
Ed Willink
Kenn Hussey wrote:
The rolled-up plan won't pick up additions/changes to themes (i.e.
the whiteboard field in Bugzilla) automatically, but if you let me
know once the OCL plan has been updated accordingly, I'll go ahead
and make the necessary changes to the MDT plan.
Thanks,
Kenn
On Fri, Sep 25, 2009 at 12:10 PM, Ed Willink <ed@xxxxxxxxxxxxx
<mailto:ed@xxxxxxxxxxxxx>> wrote:
Hi Kenn
I'm hoping to find time on Sunday to go through every Open OCL
Bugzilla and keyword it to a theme and sub-theme or defer it
according to what I think we should do for Helios.
This will be before 30th.
Will your tooling pick this up automatically or will it cause
chaos?
Regards
Ed Willink
Kenn Hussey wrote:
Thanks Alex. You might want to change the name of the final
milestone from "1.4.0" to "Helios", and it would be nice(r) if
the compliance items could have a whiteboard of "Compliance"
rather than "OCL 2.1", but everything else looks great! I've
updated the rolled-up MDT plan to take your changes into
account - see
http://www.eclipse.org/projects/project-plan.php?projectid=modeling.mdt.
Cheers,
Kenn
On Thu, Sep 24, 2009 at 8:48 AM, Alexander Igdalov
<alexander.igdalov@xxxxxxxxx
<mailto:alexander.igdalov@xxxxxxxxx>> wrote:
Hi all,
Please take a look on the second version of the
plan.
http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/modeling/mdt/ocl/project-info/plan_helios.xml&component=OCL
<http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/modeling/mdt/ocl/project-info/plan_helios.xml&component=OCL>
Kenn, Ed, thanks for your comments.
Cheers,
- Alex.
------------------------------------------------------------------------
_______________________________________________ mdt-ocl.dev
mailing list mdt-ocl.dev@xxxxxxxxxxx
<mailto:mdt-ocl.dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx <mailto:mdt-ocl.dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
------------------------------------------------------------------------
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
------------------------------------------------------------------------
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
--
*Adolfo Sánchez-Barbudo Herrera*
adolfosbh(at)opencanarias(dot)com
<mailto:adolfosbh%28at%29opencanarias%28dot%29com>
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231 / +34 617 718268
------------------------------------------------------------------------
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev