You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ctakes.apache.org by "Savova, Guergana" <Gu...@childrens.harvard.edu.INVALID> on 2023/03/08 18:20:17 UTC

RE: It is Official! Steps toward a cTAKES 5.0 release. [EXTERNAL]

+1 on waiting.
--Guergana

From: Bethard, Steven - (bethard) <be...@arizona.edu>
Sent: Wednesday, March 8, 2023 1:19 PM
To: dev@ctakes.apache.org; user@ctakes.apache.org
Subject: Re: It is Official! Steps toward a cTAKES 5.0 release. [EXTERNAL]

* External Email - Caution *

+1 on waiting for the new distribution platform (and continuing to search for a primary Release Manager).

On 3/8/23, 06:29, "Finan, Sean" wrote:

External Email

Hi all Apache cTAKES developers and users,

I have news on the release front ...

The Apache Infrastructure team is working on a new Artifact Distribution Platform.  It will be used to upload and promote release artifacts, sign keys, and host distributions in a fashion that is informative and attractive to a user.

Some of the old/current items that are part of an Apache project release are going to be "legacy" and there are some new metadata items that go with a release artifact.

I see two paths moving forward:


  1.   We push on with a release of cTAKES 5.0 and release in the current style.
  2.   We wait a couple of months until the Apache Infrastructure team has the new Artifact Distribution Platform ready and use it to release.

For #1 please keep in mind that we still haven't had a volunteer for the primary Release Manager.  Gandhi Rajan has volunteered to be co-RM but it will be a two-person job.

Either way can create Release Candidate source branches on GitHub to be tested and have issues posted on the cTAKES GitHub issues list.

This manner of Release Candidate testing would be a deviation from the method of creating Release Candidate artifacts including binary installations and putting them in a Subversion (svn) repository online.
We can probably place "binary installation" artifacts on GitHub, but somebody will need to check on space limits and other rules before we can make any promises there.  If there is some barrier there then testers would need to test binary installations by build/packaging locally on their system - which is a good thing to have tested anyway.

So, please post any thoughts or questions in reply to this email and we can try to figure out where to go from here.

Many thanks,

Sean

________________________________
From: Finan, Sean <Se...@childrens.harvard.edu.INVALID>>
Sent: Monday, February 20, 2023 5:12 PM
To: dev@ctakes.apache.org<ma...@ctakes.apache.org> <de...@ctakes.apache.org>>; user@ctakes.apache.org<ma...@ctakes.apache.org> <us...@ctakes.apache.org>>
Subject: It is Official! Steps toward a cTAKES 5.0 release. [EXTERNAL] [SUSPICIOUS]

* External Email - Caution *


Hi all,

The cTAKES Project Management Committee has voted that it is time to officially begin the release process for cTAKES 5.0

It has been almost 6 years since version 4.0.0 was released, and with a worldwide user count estimated in the thousands, a new release will be extremely valuable.

Releasing cTAKES 5.0 will involve some work, and the project needs volunteers to assist in the process.

The most important thing right now is the appointment of a Release Manager (RM).
While the position is not to be taken lightly and does involve work, it can be a great experience (and a resume builder).

We need a cTAKES committer to be the RM, but I am going to split the general responsibilities below.
I am doing this because I believe that any user familiar with cTAKES can be a co-RM.

Requiring a committer:
1.  Creating Release Candidates of the code.
2.  Deploying and Signing the actual Official Release.

Not requiring a committer:
1.  Coordinating people performing documentation, testing and bug fixing.
2.  Communicating progress with the developer list.

I am sure that I am forgetting something, but those are the 4 tasks that I can think of right now.

If you would like to be the Release Manager (or a co-RM), please volunteer on the dev@ctakes.apache.org<ma...@ctakes.apache.org> mailing list.

Other tasks that must be performed for a release include:
1.  Testing the release candidates.
3.  Contributing documentation.
2.  Writing fixes for bugs that can be fixed for the release.
4.  Updating the release information on ctakes.apache.org

Anybody can test release candidates.  There are countless pipelines that can be built and tested, but I think that we should try to cover the 'most commonly used' pipelines.  If you run any pipeline, please report success - even if you don't run it specifically for release testing.
Documentation can be contributed by any user.  A cTAKES committer is required to actually push the documentation to the wiki, readme, release notes, etc. Sending out markdown, images, plain text or just recommendations is open to all users.
While only committers can actually push changes to cTAKES code, any user can contribute fixes by creating code patches or even just copy-pasting code in an email.
Updating the ctakes.apache.org website will require a committer, but non-committer assistance is possible just like it is for bug fixes.

One person (Tim Miller) has already volunteered to perform testing and another (Dennis Johns) is currently working on the GitHub wiki.
I don't think that people need to officially volunteer to perform last 4 listed tasks, but it may be beneficial to identify areas that you would like to cover in order to prevent duplicated work.

I suspect that I am forgetting at least some minor items, but they will come to light when encountered.

I urge you all to take part in the release process.  You can earn good karma, become famous as a cTAKES power user, and perhaps be nominated as a Committer!

Thank you all,

Sean