[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [modeling-pmc] Epsilon GMT component
|
Thanks, Dimitrios.
On the CQ for the codebase itself, I'd say the current snapshot is
sufficient, as we're essentially trying to provide a clean start for the
components in GMT.
I'm expecting some clarification on the approach Legal will require us to
make later today (or soon) as we migrate/cleanup GMT components.
Thanks again,
Rich
On 6/25/08 8:08 AM, "Dimitrios Kolovos" <dskolovos@xxxxxxxxx> wrote:
> 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
>>
>>
> _______________________________________________
> modeling-pmc mailing list
> modeling-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/modeling-pmc
