Taverna's IP Clearance

[Stian Soiland-Reyes <so...@cs.manchester.ac.uk>]

We've been pusing the University lawyers on the IP clearance - so I
understand we should have this filed with Apache before we push/move
anything existing into Apache's git/Jira/Confluence, right?


Shoaib - could you ping the lawyers?

On 19 November 2014 16:46, Marlon Pierce <ma...@iu.edu> wrote:
> Looks like you still need to make your initial code contribution, so you
> should do that first. See
> http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
>
> Here's a the guideline on release management for podlings, which all the
> committers should become familiar with:
> http://incubator.apache.org/guides/releasemanagement.html.  And see also
> http://www.apache.org/dev/release.html.  You want to think this through when
> creating your source code tree structure.
>
> Marlon
>
>
> On 11/19/14, 7:03 AM, Stian Soiland-Reyes wrote:
>>
>> I agree that we should probably manage well with just one Jira
>> project, it makes it easier to describe cross-product issues as well.
>>
>> The versions don't have to strictly be linear and are free-text - so
>> you  could have say a version "3.1.0 Server", released before "3.0.0
>> Workbench".
>>
>>
>> I am not so sure about not having multiple code
>> repositories/tags/releases. We will have to do multiple binary
>> releases anyway due to operating system-specific installers (e.g. as
>> in OpenOffice, but not as large!) - but it could be a bit awkward with
>> module versioning and timing if it's "just one big thing"
>>
>> For instance, the "taverna-language" bit is pretty much ready to be
>> released from day 1 as it's been stabilizing over 2 years, and is
>> usable as a separate API and (possibly with an addition of converter
>> command lines).
>>
>> The Taverna Engine and the Command Line product are on the other hand
>> strongly linked - at least to start with it would not make sense to
>> have an Engine without a Command Line. However the Engine APIs are
>> meant to be stable and not to be dancing about in version numbers - so
>> we'll quickly end up with a diverse set of submodule versions if it's
>> all in a single code-base. From my experience this leads easily to
>> wrongly "upgrading" a module to a new minor/major version even though
>> nothing has changed - because it's too much git-investigative work to
>> verify that it hasn't.  If these submodules are a subset of multiple
>> subset, then it can get messy.    I would not recommend having
>> sub-modules of sub-modules, as that is really not the Maven way
>> anymore.
>>
>>
>> One alternative would be to have a single repository, but not a
>> top-level Maven project.  This would make tagging and branching
>> awkward (e.g. module-specific), but everything else would be managed
>> as if it was multiple repositories. An advantage of that is also that
>> you get a single checkout if you are truly interested in looking
>> at/building everything - although you would most likely build things
>> in the wrong version. (e.g. build a SNAPSHOT version of a module that
>> nothing else would depend on).
>>
>>
>>
>>
>>
>>
>> On 17 November 2014 18:54, Marlon Pierce <ma...@iu.edu> wrote:
>>>
>>> Two general points:
>>>
>>> * Jira is very important part of the Apache process, particularly for
>>> handling non-committer contributions and for communicating with the rest
>>> of
>>> the world. Take a look for example at [1].
>>>
>>> * Learning the Apache release process itself will be an important part of
>>> your incubation.
>>>
>>> Although some Apache projects have multiple Jira spaces, most don't.
>>> Discusss the pros and cons of two spaces on the list and vote if you
>>> don't
>>> have obvious consensus.
>>>
>>> Also plan now how you handle releases.  Take a look for example at how we
>>> handle Airavata releases [2], which include both client and server
>>> pieces.
>>> There is 1 source release and multiple binary artifacts.  I suggest
>>> starting
>>> simply with one release package through the incubator a few times before
>>> splitting things.
>>>
>>> Marlon
>>>
>>> [1]
>>>
>>> http://archive.cloudera.com/cdh5/cdh/5/hbase-0.98.1-cdh5.1.0/book/submitting.patches.html.
>>>
>>> [2] https://airavata.apache.org/about/downloads.html
>>>
>>>
>>> On 11/17/14, 12:15 PM, alaninmcr wrote:
>>>>
>>>> On 17/11/2014 17:18, Stian Soiland-Reyes wrote:
>>>>>
>>>>> I talked to Andy here at ApacheCon in Budapest (hah everything on the
>>>>> list!)
>>>>>
>>>>> and we discussed the thing of importing the existing Taverna issues
>>>>> into Apache's Jira.
>>>>
>>>>
>>>> [snip]
>>>>
>>>>> and also we have issues for TAVSERV separately - do we want to keep
>>>>> this distinction?
>>>>
>>>>
>>>> I think one of the reasons is so that you can do separate release
>>>> versions
>>>> of the server and the workbench/clt. You cannot AFAIK do releases of
>>>> components within Jira.
>>>>
>>>> Alan
>>>
>>>
>>
>>
>



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718

Re: Taverna's IP Clearance

[Michael Joyce <jo...@apache.org>]

Yep, best to have that resolved before stuff starts getting pushed I would
say. Otherwise that will just be a heck of a headache later =D


-- Joyce

On Thu, Nov 20, 2014 at 5:23 AM, Stian Soiland-Reyes <
soiland-reyes@cs.manchester.ac.uk> wrote:

> We've been pusing the University lawyers on the IP clearance - so I
> understand we should have this filed with Apache before we push/move
> anything existing into Apache's git/Jira/Confluence, right?
>
>
> Shoaib - could you ping the lawyers?
>
> On 19 November 2014 16:46, Marlon Pierce <ma...@iu.edu> wrote:
> > Looks like you still need to make your initial code contribution, so you
> > should do that first. See
> > http://incubator.apache.org/guides/mentor.html#initial-ip-clearance
> >
> > Here's a the guideline on release management for podlings, which all the
> > committers should become familiar with:
> > http://incubator.apache.org/guides/releasemanagement.html.  And see also
> > http://www.apache.org/dev/release.html.  You want to think this through
> when
> > creating your source code tree structure.
> >
> > Marlon
> >
> >
> > On 11/19/14, 7:03 AM, Stian Soiland-Reyes wrote:
> >>
> >> I agree that we should probably manage well with just one Jira
> >> project, it makes it easier to describe cross-product issues as well.
> >>
> >> The versions don't have to strictly be linear and are free-text - so
> >> you  could have say a version "3.1.0 Server", released before "3.0.0
> >> Workbench".
> >>
> >>
> >> I am not so sure about not having multiple code
> >> repositories/tags/releases. We will have to do multiple binary
> >> releases anyway due to operating system-specific installers (e.g. as
> >> in OpenOffice, but not as large!) - but it could be a bit awkward with
> >> module versioning and timing if it's "just one big thing"
> >>
> >> For instance, the "taverna-language" bit is pretty much ready to be
> >> released from day 1 as it's been stabilizing over 2 years, and is
> >> usable as a separate API and (possibly with an addition of converter
> >> command lines).
> >>
> >> The Taverna Engine and the Command Line product are on the other hand
> >> strongly linked - at least to start with it would not make sense to
> >> have an Engine without a Command Line. However the Engine APIs are
> >> meant to be stable and not to be dancing about in version numbers - so
> >> we'll quickly end up with a diverse set of submodule versions if it's
> >> all in a single code-base. From my experience this leads easily to
> >> wrongly "upgrading" a module to a new minor/major version even though
> >> nothing has changed - because it's too much git-investigative work to
> >> verify that it hasn't.  If these submodules are a subset of multiple
> >> subset, then it can get messy.    I would not recommend having
> >> sub-modules of sub-modules, as that is really not the Maven way
> >> anymore.
> >>
> >>
> >> One alternative would be to have a single repository, but not a
> >> top-level Maven project.  This would make tagging and branching
> >> awkward (e.g. module-specific), but everything else would be managed
> >> as if it was multiple repositories. An advantage of that is also that
> >> you get a single checkout if you are truly interested in looking
> >> at/building everything - although you would most likely build things
> >> in the wrong version. (e.g. build a SNAPSHOT version of a module that
> >> nothing else would depend on).
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 17 November 2014 18:54, Marlon Pierce <ma...@iu.edu> wrote:
> >>>
> >>> Two general points:
> >>>
> >>> * Jira is very important part of the Apache process, particularly for
> >>> handling non-committer contributions and for communicating with the
> rest
> >>> of
> >>> the world. Take a look for example at [1].
> >>>
> >>> * Learning the Apache release process itself will be an important part
> of
> >>> your incubation.
> >>>
> >>> Although some Apache projects have multiple Jira spaces, most don't.
> >>> Discusss the pros and cons of two spaces on the list and vote if you
> >>> don't
> >>> have obvious consensus.
> >>>
> >>> Also plan now how you handle releases.  Take a look for example at how
> we
> >>> handle Airavata releases [2], which include both client and server
> >>> pieces.
> >>> There is 1 source release and multiple binary artifacts.  I suggest
> >>> starting
> >>> simply with one release package through the incubator a few times
> before
> >>> splitting things.
> >>>
> >>> Marlon
> >>>
> >>> [1]
> >>>
> >>>
> http://archive.cloudera.com/cdh5/cdh/5/hbase-0.98.1-cdh5.1.0/book/submitting.patches.html
> .
> >>>
> >>> [2] https://airavata.apache.org/about/downloads.html
> >>>
> >>>
> >>> On 11/17/14, 12:15 PM, alaninmcr wrote:
> >>>>
> >>>> On 17/11/2014 17:18, Stian Soiland-Reyes wrote:
> >>>>>
> >>>>> I talked to Andy here at ApacheCon in Budapest (hah everything on the
> >>>>> list!)
> >>>>>
> >>>>> and we discussed the thing of importing the existing Taverna issues
> >>>>> into Apache's Jira.
> >>>>
> >>>>
> >>>> [snip]
> >>>>
> >>>>> and also we have issues for TAVSERV separately - do we want to keep
> >>>>> this distinction?
> >>>>
> >>>>
> >>>> I think one of the reasons is so that you can do separate release
> >>>> versions
> >>>> of the server and the workbench/clt. You cannot AFAIK do releases of
> >>>> components within Jira.
> >>>>
> >>>> Alan
> >>>
> >>>
> >>
> >>
> >
>
>
>
> --
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
> http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
>