You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ctakes.apache.org by Steven Bethard <st...@Colorado.EDU> on 2012/09/07 13:07:00 UTC
release plans?
So I know we're still waiting on Apache to upload the code to SVN (https://issues.apache.org/jira/browse/INFRA-5079) but perhaps we could already be talking about what our upcoming release plans look like? Here are several things that I know are in the pipeline, but I don't know which release they're planned for:
* Move UMLS out of Apache distribution (https://issues.apache.org/jira/browse/CTAKES-53)
* Rename packages to org.apache.ctakes (https://issues.apache.org/jira/browse/CTAKES-54)
* Rename modules consistently (https://issues.apache.org/jira/browse/CTAKES-55)
* Change build infrastructure to Maven (https://issues.apache.org/jira/browse/CTAKES-30)
* Update UIMA type system so that it is possible to load SHARP annotations (James, could you and Stephen Wu file an issue for this with appropriate details?)
My current guess is that the release plan looks something like:
2.6-incubating: CTAKES-53
3.0-incubating: everything else
Is that right? Are there other open issues that have to be addressed before 2.6-incubating?
Also, does Jira let us mark the release that we plan to fix an issue by? I didn't see any way of doing that. If we could do that, it would be an easy query to find out what needs to be done for what release.
Steve
RE: release plans?
Posted by "Bleeker, Troy C." <Bl...@mayo.edu>.
Jira can be configured to manage releases and cycles completely. An
administrator needs to turn those things on and someone define the
releases in plan. I don't have edit access yet. Jira has a nice query
function under Issues -> Search for issues. User IDs with more power
than mine can create custom searches, even change the columns that show
up and get sorted upon, and save those for others in the project to
utilize.
Thanks
Troy
-----Original Message-----
From: ctakes-dev-return-323-Bleeker.Troy=mayo.edu@incubator.apache.org
[mailto:ctakes-dev-return-323-Bleeker.Troy=mayo.edu@incubator.apache.org
] On Behalf Of Steven Bethard
Sent: Friday, September 07, 2012 6:07 AM
To: ctakes-dev@incubator.apache.org
Subject: release plans?
So I know we're still waiting on Apache to upload the code to SVN
(https://issues.apache.org/jira/browse/INFRA-5079) but perhaps we could
already be talking about what our upcoming release plans look like? Here
are several things that I know are in the pipeline, but I don't know
which release they're planned for:
* Move UMLS out of Apache distribution
(https://issues.apache.org/jira/browse/CTAKES-53)
* Rename packages to org.apache.ctakes
(https://issues.apache.org/jira/browse/CTAKES-54)
* Rename modules consistently
(https://issues.apache.org/jira/browse/CTAKES-55)
* Change build infrastructure to Maven
(https://issues.apache.org/jira/browse/CTAKES-30)
* Update UIMA type system so that it is possible to load SHARP
annotations (James, could you and Stephen Wu file an issue for this with
appropriate details?)
My current guess is that the release plan looks something like:
2.6-incubating: CTAKES-53
3.0-incubating: everything else
Is that right? Are there other open issues that have to be addressed
before 2.6-incubating?
Also, does Jira let us mark the release that we plan to fix an issue by?
I didn't see any way of doing that. If we could do that, it would be an
easy query to find out what needs to be done for what release.
Steve
RE: release plans?
Posted by "Bleeker, Troy C." <Bl...@mayo.edu>.
You can use the Fix Versions field as you stated but someone has to
create the 2.6, 3.0, etc versions. If you did patches in the future, no
problem, you can create say a 3.0.1.1 version if you want.
Thanks
Troy
-----Original Message-----
From: ctakes-dev-return-325-Bleeker.Troy=mayo.edu@incubator.apache.org
[mailto:ctakes-dev-return-325-Bleeker.Troy=mayo.edu@incubator.apache.org
] On Behalf Of Masanz, James J.
Sent: Friday, September 07, 2012 9:51 AM
To: ctakes-dev@incubator.apache.org
Subject: RE: release plans?
I think we need 2 issues opened regarding the type system. I will do
that today. One for things that are additions and won't impact current
users, and another for things that require refactoring and could affect
current users, such as the fix to be creating an (instance of a subclass
of) Event for a disease/disorder etc instead of an (instance of a
subclass of) Entity.
To mark the release that we plan to fix an issue by, perhaps we could
use the "Fix Version/s" field. Or does that normally include the version
that a patch is released for (if we ever create patches).
I propose the following:
2.6-incubating
CTAKES-7 Pre-Migration- Update/Migrate current cTAKES documentation
CTAKES-13 Pre-Migration- Create cTAKES 2.6 release (what would have
been 2.6 in SF)
CTAKES-14 TimeMention is missing feature for what is being manually
annotated as "class"
CTAKES-19 ctakes constituency parser does not generate function tags
CTAKES-24 extraneous jars in cTAKES 2.5
CTAKES-33 Add Relation Extractor
CTAKES-36 remove generated types from source tree
CTAKES-42 user guide - Note that test1.xml uses CDA not plaintext AE
3.0-incubating
CTAKES-12 Upgrade to cTAKES components to latest Lucene version.
CTAKES-16 use uimaFIT's selectCovered() instead of UIMA's subiterator
CTAKES-18 add XxxxEntity|EventMention types for other NEs similar to
MedicationEventMention
CTAKES-25 retrain rest of models using OpenNLP 1.5
CTAKES-27 Upgrade cTAKES dependencies/libraries
CTAKES-28 Externalize dictionarylookup/UMLS password to password file
or variable
CTAKES-30 Maven integration of cTAKES components
CTAKES-31 constrainToWindow assumes tokens are not sorted
CTAKES-32 dictionary lookup creates new LookupTokens many times
CTAKES-35 SyntaxAttributeCalculator.java hardcodes file names
CTAKES-38 Orange book is not the most recent
CTAKES-39 Upgrade LVG to a later version
CTAKES-44 Tokenizer does not handle Windows-style newlines
CTAKES-47 codes and OUI in CreateLuceneIndexForSnomedLikeSample.java
CTAKES-48 negation annotator - Sentence type used in code not in descr
CTAKES-50 Remove UIMA Deprecated references in Annotators
CTAKES-52 Context sensitive tokenizer misses certain kinds of time
expressions
CTAKES-53 move UMLS out of Apache distribution
CTAKES-54 rename packages to org.apache.ctakes
CTAKES-55 rename modules consistently
Regards,
James Masanz
> -----Original Message-----
> From: ctakes-dev-return-323-
> Masanz.James=mayo.edu@incubator.apache.org [mailto:ctakes-dev-return-
> 323-Masanz.James=mayo.edu@incubator.apache.org] On Behalf Of Steven
> Bethard
> Sent: Friday, September 07, 2012 6:07 AM
> To: ctakes-dev@incubator.apache.org
> Subject: release plans?
>
> So I know we're still waiting on Apache to upload the code to SVN
> (https://issues.apache.org/jira/browse/INFRA-5079) but perhaps we
could
> already be talking about what our upcoming release plans look like?
Here are
> several things that I know are in the pipeline, but I don't know which
release
> they're planned for:
>
> * Move UMLS out of Apache distribution
> (https://issues.apache.org/jira/browse/CTAKES-53)
> * Rename packages to org.apache.ctakes
> (https://issues.apache.org/jira/browse/CTAKES-54)
> * Rename modules consistently
> (https://issues.apache.org/jira/browse/CTAKES-55)
> * Change build infrastructure to Maven
> (https://issues.apache.org/jira/browse/CTAKES-30)
> * Update UIMA type system so that it is possible to load SHARP
annotations
> (James, could you and Stephen Wu file an issue for this with
appropriate
> details?)
>
> My current guess is that the release plan looks something like:
>
> 2.6-incubating: CTAKES-53
> 3.0-incubating: everything else
>
> Is that right? Are there other open issues that have to be addressed
before
> 2.6-incubating?
>
> Also, does Jira let us mark the release that we plan to fix an issue
by? I didn't
> see any way of doing that. If we could do that, it would be an easy
query to
> find out what needs to be done for what release.
>
> Steve
RE: release plans?
Posted by "Masanz, James J." <Ma...@mayo.edu>.
I think we need 2 issues opened regarding the type system. I will do
that today. One for things that are additions and won't impact current
users, and another for things that require refactoring and could affect
current users, such as the fix to be creating an (instance of a subclass
of) Event for a disease/disorder etc instead of an (instance of a
subclass of) Entity.
To mark the release that we plan to fix an issue by, perhaps we could
use the "Fix Version/s" field. Or does that normally include the version
that a patch is released for (if we ever create patches).
I propose the following:
2.6-incubating
CTAKES-7 Pre-Migration- Update/Migrate current cTAKES documentation
CTAKES-13 Pre-Migration- Create cTAKES 2.6 release (what would have
been 2.6 in SF)
CTAKES-14 TimeMention is missing feature for what is being manually
annotated as "class"
CTAKES-19 ctakes constituency parser does not generate function tags
CTAKES-24 extraneous jars in cTAKES 2.5
CTAKES-33 Add Relation Extractor
CTAKES-36 remove generated types from source tree
CTAKES-42 user guide - Note that test1.xml uses CDA not plaintext AE
3.0-incubating
CTAKES-12 Upgrade to cTAKES components to latest Lucene version.
CTAKES-16 use uimaFIT's selectCovered() instead of UIMA's subiterator
CTAKES-18 add XxxxEntity|EventMention types for other NEs similar to
MedicationEventMention
CTAKES-25 retrain rest of models using OpenNLP 1.5
CTAKES-27 Upgrade cTAKES dependencies/libraries
CTAKES-28 Externalize dictionarylookup/UMLS password to password file
or variable
CTAKES-30 Maven integration of cTAKES components
CTAKES-31 constrainToWindow assumes tokens are not sorted
CTAKES-32 dictionary lookup creates new LookupTokens many times
CTAKES-35 SyntaxAttributeCalculator.java hardcodes file names
CTAKES-38 Orange book is not the most recent
CTAKES-39 Upgrade LVG to a later version
CTAKES-44 Tokenizer does not handle Windows-style newlines
CTAKES-47 codes and OUI in CreateLuceneIndexForSnomedLikeSample.java
CTAKES-48 negation annotator - Sentence type used in code not in descr
CTAKES-50 Remove UIMA Deprecated references in Annotators
CTAKES-52 Context sensitive tokenizer misses certain kinds of time
expressions
CTAKES-53 move UMLS out of Apache distribution
CTAKES-54 rename packages to org.apache.ctakes
CTAKES-55 rename modules consistently
Regards,
James Masanz
> -----Original Message-----
> From: ctakes-dev-return-323-
> Masanz.James=mayo.edu@incubator.apache.org [mailto:ctakes-dev-return-
> 323-Masanz.James=mayo.edu@incubator.apache.org] On Behalf Of Steven
> Bethard
> Sent: Friday, September 07, 2012 6:07 AM
> To: ctakes-dev@incubator.apache.org
> Subject: release plans?
>
> So I know we're still waiting on Apache to upload the code to SVN
> (https://issues.apache.org/jira/browse/INFRA-5079) but perhaps we
could
> already be talking about what our upcoming release plans look like?
Here are
> several things that I know are in the pipeline, but I don't know which
release
> they're planned for:
>
> * Move UMLS out of Apache distribution
> (https://issues.apache.org/jira/browse/CTAKES-53)
> * Rename packages to org.apache.ctakes
> (https://issues.apache.org/jira/browse/CTAKES-54)
> * Rename modules consistently
> (https://issues.apache.org/jira/browse/CTAKES-55)
> * Change build infrastructure to Maven
> (https://issues.apache.org/jira/browse/CTAKES-30)
> * Update UIMA type system so that it is possible to load SHARP
annotations
> (James, could you and Stephen Wu file an issue for this with
appropriate
> details?)
>
> My current guess is that the release plan looks something like:
>
> 2.6-incubating: CTAKES-53
> 3.0-incubating: everything else
>
> Is that right? Are there other open issues that have to be addressed
before
> 2.6-incubating?
>
> Also, does Jira let us mark the release that we plan to fix an issue
by? I didn't
> see any way of doing that. If we could do that, it would be an easy
query to
> find out what needs to be done for what release.
>
> Steve
Re: release plans?
Posted by Jörn Kottmann <ko...@gmail.com>.
On 09/10/2012 04:12 PM, Chen, Pei wrote:
> But yes, in the past we used to use the Affects Versions, Fix Versions as described in conjunction with the 'Status' field. I would suggest committers to update the bug item to 'Fixed' when the commit is made to SVN and 'Close' the issue only after the release has been made and verified.
The fix version can be used in jira to generate a list of all issues
fixed for a specific version, over
at UIMA and OpenNLP we use that feature to automatically generate this
list during a "release"
build. The fix version is also used to show lists of issues which still
need to be fixed for the
a release.
There is a "resolved" and "closed" state for an issue. If an issue is
reported from a person
who will not fix it the "closed" state can be used as a verification
that it now works for
him after a committer "resolved" it.
Jörn
RE: release plans?
Posted by "Chen, Pei" <Pe...@childrens.harvard.edu>.
Sorry, I was off the grid last week.
But yes, in the past we used to use the Affects Versions, Fix Versions as described in conjunction with the 'Status' field. I would suggest committers to update the bug item to 'Fixed' when the commit is made to SVN and 'Close' the issue only after the release has been made and verified.
Regarding what goes in 3.0-incubating, I would suggest even making it as simple as possible (i.e. no critical logical/functional changes or bug fixes other than repacking to org.apache.).
And put everything else into an 3.1-incubating release... I created the current Jira items quickly just so that we would not forget them, but I'll update them to later today to better reflect this.
If anyone needs write access, feel free to create a Jira account and let us know your id and we could add you to the project as it's a separate auth than people.apache.org.
--Pei
> -----Original Message-----
> From: Mattmann, Chris A (388J) [mailto:chris.a.mattmann@jpl.nasa.gov]
> Sent: Friday, September 07, 2012 6:53 PM
> To: <ct...@incubator.apache.org>
> Subject: Re: release plans?
>
> Hey Steve,
>
> On Sep 7, 2012, at 9:40 AM, Steven Bethard wrote:
>
> > On Sep 7, 2012, at 6:30 PM, Mattmann, Chris A (388J) wrote:
> >> On Sep 7, 2012, at 4:07 AM, Steven Bethard wrote:
> >>> Also, does Jira let us mark the release that we plan to fix an issue by? I
> didn't see any way of doing that. If we could do that, it would be an easy
> query to find out what needs to be done for what release.
> >>
> >> Yep, you just create upcoming release versions, then set the "Fix
> >> version" attribute for the issue to that version.
> >
> > Ok, I thought about setting the "Fix version", but that looked like the
> version in which it actually got fixed, not the version in which we intend to fix
> it. But I guess eventually those should be the same, so it probably does make
> sense to use that for both.
> >
>
> Yep "Fix version" means version you intend to fix in (or the actual version it's
> fixed in): one and the same. "Affects version" usually is listed in the situation
> that the bug is discovered with a particular version *after the fact* that is,
> after it was released.
>
> Cheers,
> Chris
>
> > On Sep 7, 2012, at 4:50 PM, Masanz, James J. wrote:
> >> I propose the following:
> >>
> >> 2.6-incubating
> >> CTAKES-7 Pre-Migration- Update/Migrate current cTAKES documentation
> >> CTAKES-13 Pre-Migration- Create cTAKES 2.6 release (what would have
> >> been 2.6 in SF)
> >> CTAKES-14 TimeMention is missing feature for what is being manually
> annotated as "class"
> >> CTAKES-19 ctakes constituency parser does not generate function tags
> >> CTAKES-24 extraneous jars in cTAKES 2.5
> >> CTAKES-33 Add Relation Extractor
> >> CTAKES-36 remove generated types from source tree
> >> CTAKES-42 user guide - Note that test1.xml uses CDA not plaintext AE
> >>
> >> 3.0-incubating
> >> CTAKES-12 Upgrade to cTAKES components to latest Lucene version.
> >> CTAKES-16 use uimaFIT's selectCovered() instead of UIMA's subiterator
> >> CTAKES-18 add XxxxEntity|EventMention types for other NEs similar to
> >> MedicationEventMention
> >> CTAKES-25 retrain rest of models using OpenNLP 1.5
> >> CTAKES-27 Upgrade cTAKES dependencies/libraries
> >> CTAKES-28 Externalize dictionarylookup/UMLS password to password file
> >> or variable
> >> CTAKES-30 Maven integration of cTAKES components
> >> CTAKES-31 constrainToWindow assumes tokens are not sorted
> >> CTAKES-32 dictionary lookup creates new LookupTokens many times
> >> CTAKES-35 SyntaxAttributeCalculator.java hardcodes file names
> >> CTAKES-38 Orange book is not the most recent
> >> CTAKES-39 Upgrade LVG to a later version
> >> CTAKES-44 Tokenizer does not handle Windows-style newlines
> >> CTAKES-47 codes and OUI in
> CreateLuceneIndexForSnomedLikeSample.java
> >> CTAKES-48 negation annotator - Sentence type used in code not in
> >> descr
> >> CTAKES-50 Remove UIMA Deprecated references in Annotators
> >> CTAKES-52 Context sensitive tokenizer misses certain kinds of time
> >> expressions
> >> CTAKES-53 move UMLS out of Apache distribution
> >> CTAKES-54 rename packages to org.apache.ctakes
> >> CTAKES-55 rename modules consistently
> >
> >
> > This all looks basically good. My only concern would be CTAKES-53 - don't
> we have to remove UMLS to be able to release from Apache? My
> understanding was that otherwise we can't release due to licensing conflicts.
> >
> > Steve
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW: http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++
> Adjunct Assistant Professor, Computer Science Department University of
> Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++
Re: release plans?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Steve,
On Sep 7, 2012, at 9:40 AM, Steven Bethard wrote:
> On Sep 7, 2012, at 6:30 PM, Mattmann, Chris A (388J) wrote:
>> On Sep 7, 2012, at 4:07 AM, Steven Bethard wrote:
>>> Also, does Jira let us mark the release that we plan to fix an issue by? I didn't see any way of doing that. If we could do that, it would be an easy query to find out what needs to be done for what release.
>>
>> Yep, you just create upcoming release versions, then set the "Fix version" attribute for the
>> issue to that version.
>
> Ok, I thought about setting the "Fix version", but that looked like the version in which it actually got fixed, not the version in which we intend to fix it. But I guess eventually those should be the same, so it probably does make sense to use that for both.
>
Yep "Fix version" means version you intend to fix in (or the actual version it's fixed in): one and the same. "Affects version" usually is listed
in the situation that the bug is discovered with a particular version *after the fact* that is, after it was released.
Cheers,
Chris
> On Sep 7, 2012, at 4:50 PM, Masanz, James J. wrote:
>> I propose the following:
>>
>> 2.6-incubating
>> CTAKES-7 Pre-Migration- Update/Migrate current cTAKES documentation
>> CTAKES-13 Pre-Migration- Create cTAKES 2.6 release (what would have been 2.6 in SF)
>> CTAKES-14 TimeMention is missing feature for what is being manually annotated as "class"
>> CTAKES-19 ctakes constituency parser does not generate function tags
>> CTAKES-24 extraneous jars in cTAKES 2.5
>> CTAKES-33 Add Relation Extractor
>> CTAKES-36 remove generated types from source tree
>> CTAKES-42 user guide - Note that test1.xml uses CDA not plaintext AE
>>
>> 3.0-incubating
>> CTAKES-12 Upgrade to cTAKES components to latest Lucene version.
>> CTAKES-16 use uimaFIT's selectCovered() instead of UIMA's subiterator
>> CTAKES-18 add XxxxEntity|EventMention types for other NEs similar to MedicationEventMention
>> CTAKES-25 retrain rest of models using OpenNLP 1.5
>> CTAKES-27 Upgrade cTAKES dependencies/libraries
>> CTAKES-28 Externalize dictionarylookup/UMLS password to password file or variable
>> CTAKES-30 Maven integration of cTAKES components
>> CTAKES-31 constrainToWindow assumes tokens are not sorted
>> CTAKES-32 dictionary lookup creates new LookupTokens many times
>> CTAKES-35 SyntaxAttributeCalculator.java hardcodes file names
>> CTAKES-38 Orange book is not the most recent
>> CTAKES-39 Upgrade LVG to a later version
>> CTAKES-44 Tokenizer does not handle Windows-style newlines
>> CTAKES-47 codes and OUI in CreateLuceneIndexForSnomedLikeSample.java
>> CTAKES-48 negation annotator - Sentence type used in code not in descr
>> CTAKES-50 Remove UIMA Deprecated references in Annotators
>> CTAKES-52 Context sensitive tokenizer misses certain kinds of time expressions
>> CTAKES-53 move UMLS out of Apache distribution
>> CTAKES-54 rename packages to org.apache.ctakes
>> CTAKES-55 rename modules consistently
>
>
> This all looks basically good. My only concern would be CTAKES-53 - don't we have to remove UMLS to be able to release from Apache? My understanding was that otherwise we can't release due to licensing conflicts.
>
> Steve
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RE: release plans?
Posted by "Chen, Pei" <Pe...@childrens.harvard.edu>.
Yup, I believe think that was agreed upon in the below thread (create a 2.6-incubating release exactly as what was tagged in SF. We can perform the org.apache repackage as part of 3.0-incubating. Have any bug fixes and development going forward in subsequent releases (3.1 and going forward...)
http://markmail.org/search/+list:org.apache.incubator.ctakes-dev#query:list%3Aorg.apache.incubator.ctakes-dev%20from%3A%22J%C3%B6rn%20Kottmann%22+page:2+mid:4f7t76746i44wn2m+state:results
Steve: I also added you as Committer/PMC groups in JIRA so you should be able to see the other available actions in Jira now.
--Pei
> -----Original Message-----
> From: Masanz, James J. [mailto:Masanz.James@mayo.edu]
> Sent: Monday, September 10, 2012 12:54 PM
> To: ctakes-dev@incubator.apache.org
> Subject: RE: release plans?
>
>
> My understanding was that while in incubator, we are given time to fix
> licensing issues.
> So I would defer CTAKES-53 until 3.0-incubating or 3.1-incubating so we can
> get 2.6-incubating out the door.
>
>
> > This all looks basically good. My only concern would be CTAKES-53 -
> don't we
> > have to remove UMLS to be able to release from Apache? My
> understanding
> > was that otherwise we can't release due to licensing conflicts.
> >
> > Steve
RE: release plans?
Posted by "Masanz, James J." <Ma...@mayo.edu>.
My understanding was that while in incubator, we are given time to fix
licensing issues.
So I would defer CTAKES-53 until 3.0-incubating or 3.1-incubating so we
can get 2.6-incubating out the door.
> This all looks basically good. My only concern would be CTAKES-53 -
don't we
> have to remove UMLS to be able to release from Apache? My
understanding
> was that otherwise we can't release due to licensing conflicts.
>
> Steve
Re: release plans?
Posted by Steven Bethard <st...@Colorado.EDU>.
On Sep 7, 2012, at 6:30 PM, Mattmann, Chris A (388J) wrote:
> On Sep 7, 2012, at 4:07 AM, Steven Bethard wrote:
>> Also, does Jira let us mark the release that we plan to fix an issue by? I didn't see any way of doing that. If we could do that, it would be an easy query to find out what needs to be done for what release.
>
> Yep, you just create upcoming release versions, then set the "Fix version" attribute for the
> issue to that version.
Ok, I thought about setting the "Fix version", but that looked like the version in which it actually got fixed, not the version in which we intend to fix it. But I guess eventually those should be the same, so it probably does make sense to use that for both.
On Sep 7, 2012, at 4:50 PM, Masanz, James J. wrote:
> I propose the following:
>
> 2.6-incubating
> CTAKES-7 Pre-Migration- Update/Migrate current cTAKES documentation
> CTAKES-13 Pre-Migration- Create cTAKES 2.6 release (what would have been 2.6 in SF)
> CTAKES-14 TimeMention is missing feature for what is being manually annotated as "class"
> CTAKES-19 ctakes constituency parser does not generate function tags
> CTAKES-24 extraneous jars in cTAKES 2.5
> CTAKES-33 Add Relation Extractor
> CTAKES-36 remove generated types from source tree
> CTAKES-42 user guide - Note that test1.xml uses CDA not plaintext AE
>
> 3.0-incubating
> CTAKES-12 Upgrade to cTAKES components to latest Lucene version.
> CTAKES-16 use uimaFIT's selectCovered() instead of UIMA's subiterator
> CTAKES-18 add XxxxEntity|EventMention types for other NEs similar to MedicationEventMention
> CTAKES-25 retrain rest of models using OpenNLP 1.5
> CTAKES-27 Upgrade cTAKES dependencies/libraries
> CTAKES-28 Externalize dictionarylookup/UMLS password to password file or variable
> CTAKES-30 Maven integration of cTAKES components
> CTAKES-31 constrainToWindow assumes tokens are not sorted
> CTAKES-32 dictionary lookup creates new LookupTokens many times
> CTAKES-35 SyntaxAttributeCalculator.java hardcodes file names
> CTAKES-38 Orange book is not the most recent
> CTAKES-39 Upgrade LVG to a later version
> CTAKES-44 Tokenizer does not handle Windows-style newlines
> CTAKES-47 codes and OUI in CreateLuceneIndexForSnomedLikeSample.java
> CTAKES-48 negation annotator - Sentence type used in code not in descr
> CTAKES-50 Remove UIMA Deprecated references in Annotators
> CTAKES-52 Context sensitive tokenizer misses certain kinds of time expressions
> CTAKES-53 move UMLS out of Apache distribution
> CTAKES-54 rename packages to org.apache.ctakes
> CTAKES-55 rename modules consistently
This all looks basically good. My only concern would be CTAKES-53 - don't we have to remove UMLS to be able to release from Apache? My understanding was that otherwise we can't release due to licensing conflicts.
Steve
Re: release plans?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Steve,
On Sep 7, 2012, at 4:07 AM, Steven Bethard wrote:
> [...snip...]
>
> Also, does Jira let us mark the release that we plan to fix an issue by? I didn't see any way of doing that. If we could do that, it would be an easy query to find out what needs to be done for what release.
Yep, you just create upcoming release versions, then set the "Fix version" attribute for the
issue to that version.
So concretely, if you have version 3.0 of cTAKES, you create that version in JIRA, then
say you have CTAKES-xxx you set its Fix version to 3.0. Then in the JIRA roadmap tab/panel
you can see a list of upcoming issues that are set to Fix versions.
HTH!
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++