[
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 Ed,
Taking into account the deadline and the fact that nobody has time to achieve this, it seems it's better to mark the bugs as I see you are doing...
Cheers,
Adolfo.
2009/9/29 Ed Willink
<ed@xxxxxxxxxxxxx>
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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
