[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [modeling-pmc] Epsilon GMT component
|
Hi Rich,
More comments below.
Best regards,
Dimitrios
Richard Gronback wrote:
> Hi Dimitrios,
>
> See replies below...
>
> Best,
> Rich
>
>
> On 6/25/08 7:24 AM, "Dimitrios Kolovos" <dskolovos@xxxxxxxxx> wrote:
>
>
>> Dear Modeling PMC, EMO,
>>
>> An update and some more questions on the alignment of the Epsilon GMT
>> component with the IP process follows.
>>
>> So far we’ve done the following:
>>
>> 1) 3rd-party libraries
>>
>> Filed CQs for JDOM (CQ - 2445 approved) and ANTLR 3.1b (CQ 2446 - pending)
>>
>> 2) Refactored the package names and now they are org.eclipse.epsilon.*
>> instead of org.epsilon.*
>>
>> 3) Added (Incubation) to the names of all plugins and features
>>
>>
>
> Note that your download zip files
> (http://www.eclipse.org/gmt/epsilon/download.php) will need to include the
> word 'incubation' as well, and you'll need to display the incubation logo on
> the page, per
> http://www.eclipse.org/projects/dev_process/incubation-conforming.php
>
>
Thanks for the reminder. We'll do that shortly.
>> 4) Added appropriate copyright notes to all Java source files and an
>> epl-v10.html to all plugins/features
>>
>> What we still need to do (here come the questions :) ):
>>
>> 5) Drop version to < 1
>>
>> The “current” version of Epsilon is 1.3.6. Does it make sense to set the
>> “new” version to 0.3.7 or should we start from 0.0.1?
>>
>>
>
> You can use any number you'd like. Typically, it seems like incubation
> projects/components start at 0.7.0 or 0.8.0, though 0.3.7 seems fine. The
> number should give some indication of how far from release you are. If
> you've previously considered the code to be 1.3.6, why not start off at
> 0.9.0 and shoot to graduate next cycle? It's up to you, really.
>
>
I see. In this case we'll go for 0.8.0 which should give us a bit of
time establish a good graduation strategy, a matter which will probably
require further discussion.
>> 6) Update plugins and features folder names in the CVS.
>>
>> After the refactoring our local plugin/feature folders are in the form
>> of org.eclipse.epsilon.* but the respective folders in CVS are still
>> org.epsilon.*. There are two options: one is to ask the CVS admin to
>> rename/move folders in the CVS and the other one is to disconnect
>> folders, share them again under their new names and then ask the CVS
>> administrator to delete all org.epsilon.* folders. Any thoughts on this?
>>
>>
>
> I'd ask to have them renamed, or do this in conjunction with moving them to
> the /cvsroot/modeling repo after clearance is given to move from Eclipse
> legal and the PMC.
>
>
In this case I think we'll leave it as it is for now and sort this out
when we are about to move to the modeling repository.
>> 7) Change (?) the provider of plugins and features
>>
>> Must the provider of plugins and features be set to “Eclipse.org” or can
>> we leave it as it is (“University of York”)?
>>
>>
>
> I'm not sure where it's written, but the provider name should be
> Eclipse.org, while all the copyrights should be "University of York" (I
> guess).
>
>
Thanks for the clarification.
>> 8) Pre-Eclipse code
>>
>> At the time we joined GMT we were not asked to submit our pre-Eclipse
>> code for review. How can this be reconciled? (It is mostly a typicality
>> as all pre and post Eclipse code has been written by us)
>>
>>
>
> You'll need to open a CQ and attach the code so it can be reviewed by Legal.
> Once this and the 3rd party reviews are done, you should be cleared to move
> to /cvsroot/modeling, though the details of that are forthcoming.
>
>
Should we attach the code as it was when we first joined GMT (that may
be a hard - but not necessarily impossible - to track now :) ) or the
current code?
>> 9) We haven’t still received feedback on what we should do with non-EPL
>> libraries (e.g. Simmetrics and MDR) but this is of secondary importance
>> right now. For now we’ll just exclude them as they are not essential.
>>
>>
>
> Good plan (to exclude). They'll need CQs as well, if/when you plan to
> incorporate them again.
>
The point is that it is certain that they won't be approved due to
conflicting licences. What we had in mind was to store them in an
external location (e.g. Sourceforge) and provide links to there, but
let's leave that for now.
>
>> Any feedback would be greatly appreciated.
>>
>> Best regards,
>> Dimitrios
>>
>>
>> Richard Gronback wrote:
>>
>>> Migrating CVS will not lose your history... It's merely a copy of folders
>>> from one location to another.
>>>
>>> Best,
>>> Rich
>>>
>>>
>>> On 6/23/08 11:15 AM, "Dimitrios Kolovos" <dskolovos@xxxxxxxxx> wrote:
>>>
>>>
>>>
>>>> Rich: Thanks for your prompt reply and pointers. We'll start working on
>>>> these issues immediately and keep the list posted on any developments.
>>>>
>>>> Ed: Does migrating to a different CVS repository mean that all
>>>> source-code history will be lost? Is there a good way around it or do we
>>>> just have to live with that?
>>>>
>>>> Best regards,
>>>> Dimitrios
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>
>>>>> Rich,
>>>>>
>>>>> I also think this is a good opportunity to create a new CVS module
>>>>> that is properly within the modeling project's CVS structure where all
>>>>> the other projects reside. So likely we'd want a org.eclipse.gmt
>>>>> parent with a module for each project/component in GMT that's being
>>>>> reviewed and migrated...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Ed Merks/Toronto/IBM@IBMCA
>>>>> mailto: merks@xxxxxxxxxx
>>>>> 905-413-3265 (t/l 313)
>>>>>
>>>>>
>>>>> Inactive hide details for Richard Gronback
>>>>> <richard.gronback@xxxxxxxxxxx>Richard Gronback
>>>>> <richard.gronback@xxxxxxxxxxx>
>>>>>
>>>>>
>>>>> *Richard Gronback <richard.gronback@xxxxxxxxxxx>*
>>>>> Sent by: modeling-pmc-bounces@xxxxxxxxxxx
>>>>>
>>>>> 06/23/2008 10:43 AM
>>>>> Please respond to
>>>>> PMC members mailing list
>>>>> <modeling-pmc@xxxxxxxxxxx>
>>>>>
>>>>>
>>>>>
>>>>> To
>>>>>
>>>>> PMC members mailing list <modeling-pmc@xxxxxxxxxxx>, <emo@xxxxxxxxxxx>
>>>>>
>>>>> cc
>>>>>
>>>>> Richard Paige <paige@xxxxxxxxxxxxx>, Janet Campbell
>>>>> <janet.campbell@xxxxxxxxxxx>
>>>>>
>>>>> Subject
>>>>>
>>>>> Re: [modeling-pmc] Epsilon GMT component
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Excellent, thanks for the update.
>>>>>
>>>>> See inserted comments below...
>>>>>
>>>>> Best,
>>>>> Rich
>>>>>
>>>>>
>>>>> On 6/23/08 6:57 AM, "Dimitrios Kolovos" <dskolovos@xxxxxxxxx> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Dear EMO, Modeling PMC,
>>>>>>
>>>>>> We are in the process of making the Epsilon GMT component compatible
>>>>>> with the Eclipse IP process and we could use some advice on the actions
>>>>>> we need to take. To my understanding we should do the following:
>>>>>>
>>>>>> 1) File CQs in the IPZilla for any 3^rd party jars we are using
>>>>>>
>>>>>> We are currently using jdom.jar which has been approved for other
>>>>>> projects (https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1587). We also
>>>>>> use version 3.1b of the ANTLR runtime jar (version 3.0 has been approved
>>>>>> for other projects e.g.
>>>>>> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1359)
>>>>>>
>>>>>>
>>>>> Right, so you'll just need to submit piggyback CQs through the portal.
>>>>>
>>>>>
>>>>>
>>>>>> We¹ve removed the simmetrics jar we were using as it licensed under GPL
>>>>>> which is incompatible with EPL
>>>>>>
>>>>>>
>>>>>>
>>>>> Great.
>>>>>
>>>>>
>>>>>
>>>>>> 2) File a CQ for the pre-Eclipse code (similarly to
>>>>>> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1460)
>>>>>>
>>>>>> 3) Change the namespace from org.epsilon.* to org.eclipse.*
>>>>>>
>>>>>> Do we need to set the complete path of Epsilon under Eclipse as the
>>>>>> namespace? In this case it would need to be org.eclipse.gmt.epsilon.*.
>>>>>> However, if GMT components are to be relocated soon, this would have to
>>>>>> change again. If we could set the namespace to just
>>>>>> org.eclipse.epsilon.* it would be more resistant to future relocations.
>>>>>> Is that OK?
>>>>>>
>>>>>>
>>>>>>
>>>>> I think org.eclipse.epsilon.* is fine.
>>>>>
>>>>>
>>>>>
>>>>>> 4) Set version of plugins to <1 as it is a component of an Incubation
>>>>>> project
>>>>>>
>>>>>> 5) Add (Incucation) to the name of the plugins/features
>>>>>>
>>>>>>
>>>>>>
>>>>> And download zips/jars.
>>>>>
>>>>>
>>>>>
>>>>>> 6) Set up an IP Log page under the Epsilon website (e.g. such as
>>>>>> http://www.eclipse.org/stp/development/ip_log.php)
>>>>>>
>>>>>>
>>>>>>
>>>>> You may want to leverage the query approach used by GMF (and now most of
>>>>> modeling, afaik)
>>>>> http://www.eclipse.org/modeling/gmf/project-info/ipquery.php That is,
>>>>> until
>>>>> the official method is available:
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=220977
>>>>>
>>>>>
>>>>>
>>>>>> I also have a question about EPL-incompatible libraries. For example, in
>>>>>> Epsilon (and I believe in other modeling components too) we need to
>>>>>> provide support for MOF 1.4 models which is realized by MDR (and which
>>>>>> appears to be incompatible with EPL). We would also like to provide
>>>>>> support for fuzzy string matching using Simmetrics (which as mentioned
>>>>>> above is GPL). As we cannot host those plugins on Eclipse, I was
>>>>>> wondering if we could host them elsewhere (e.g. on Sourceforge) and
>>>>>> provide a link from the Epsilon GMT site to them.
>>>>>>
>>>>>>
>>>>>>
>>>>> This is a complicated issue, so copying Janet for counsel. :)
>>>>>
>>>>>
>>>>>
>>>>>> I¹d be grateful if you could confirm, complement or comment on the above
>>>>>> at your earliest convenience. I suspect that any information you provide
>>>>>> would also be useful for other GMT components that are in the same
>>>>>>
>>>>>>
>>>>> process.
>>>>>
>>>>>
>>>>>> Best regards,
>>>>>> Dimitrios Kolovos
>>>>>> _______________________________________________
>>>>>> modeling-pmc mailing list
>>>>>> modeling-pmc@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> modeling-pmc mailing list
>>>>> modeling-pmc@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> modeling-pmc mailing list
>>>>> modeling-pmc@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> modeling-pmc mailing list
>>>> modeling-pmc@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>>>>
>>>>
>>> _______________________________________________
>>> modeling-pmc mailing list
>>> modeling-pmc@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>>>
>>>
>>>
>> _______________________________________________
>> modeling-pmc mailing list
>> modeling-pmc@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>>
>
> _______________________________________________
> modeling-pmc mailing list
> modeling-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
>
>
