incubator-ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Pei" <Pei.C...@childrens.harvard.edu>
Subject RE: release plans?
Date Mon, 10 Sep 2012 14:12:53 GMT
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: <ctakes-dev@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
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++


Mime
View raw message