Re: (Re)introduce myself - James Masanz

[James Masanz]

tember report had the line item:
> > - Committee will schedule a release as soon as they feel it's ready;
> previously pushed back as there hasn't been major features/changes to code
> base yet.  Committers will be able to volunteer to be RM as soon as
> committee/community is ready for a new release.
>
> I understand that because of the report you may personally feel like you
> are under the gun to get something out there asap.  As Murali is (I
> believe) your employee/coworker you may have faith that he will get things
> done.  But I would like to point out the plural in your statement
> "Committers will be able ..."  It seems that James is allowed to volunteer
> to be an RM.  I would also like to remind that 3 months ago I volunteered
> to be Co-RM and would love to have James' help - not just because he has
> previously been part of the release process, but also because he is one of
> the original visionaries of ctakes!
>
> Please take this kindly,
> Sean
>
>
> -Original Message-
> From: Pei Chen [mailto:pei.c...@wiredinformatics.com]
> Sent: Friday, January 27, 2017 2:29 PM
> To: dev@ctakes.apache.org
> Subject: Re: (Re)introduce myself - James Masanz
>
> Welcome back James!  Good to hear from you again.
> Out of respect for the others in the community who already volunteered to
> be RM, I do not see an need for BCH to override existing volunteers. Unless
> they unable or unwilling.
> Would you/others agree?
>
> Sent from my iPhone
>
> > On Jan 27, 2017, at 2:23 PM, James Masanz <masanz.ja...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > I'm James Masanz -- if you've been on the dev list for more than a
> > couple years, you might recognize my name from my previous
> > contributions to cTAKES, which include having been a release manager.
> >
> > I've joined the Boston Children's Hospital NLP team. I will be
> > devoting significant energy to the next release of cTAKES, and I
> > volunteer to be the release manager for it.
> >
> > My initial thoughts are that we could make the "fast dictionary
> > lookup" be the default dictionary lookup, incorporate the dictionary
> > GUI from sandbox, and call the release 4.0. I'm also interested in
> > migrating the Wiki away from Confluence to Apache's moin-moin
> > instance. I'm sure there are other things to include in the next release
> as well.
> >
> > You'll be hearing more from me over the next few weeks as I review the
> > list of issues in Jira and get caught up with details of what's been
> > going on while I was less active here.
> >
> > One thing I would like to track for release candidates would be a list
> > of what is tested on which platforms, which could be as simple as a
> > post with a matrix of src/bin/other vs. linux/windows/mac, and making
> > sure we have at least one volunteer to test the install and run of a
> > pipeline for each entry in the table. Future releases might expand on
> > that to include tracking multiple pipelines across environments, etc.
> >
> > I'm happy I'm returning to being active in the cTAKES community!
> >
> > -- James
>

Re: (Re)introduce myself - James Masanz

[Andrey Kurdumov]

Hi James,

Good to hear that +1 member join the cTakes.
Hopefully we will see new release soon.



2017-01-29 0:38 GMT+06:00 Finan, Sean <sean.fi...@childrens.harvard.edu>:

> Hi Pei,
>
> I am a little taken back by your statement:
> > I do not see an need for BCH to override existing volunteers.
>
> From what James  wrote, I don't get the feeling that he is trying to
> override other RM volunteers or in any way take control of the release.
> His email stated specifically that he is volunteering to be the release
> manager, not demanding the position.  Also, since by his own admission
> James has been away, he may not be aware that anybody else has fully
> assumed the role.  Is that indeed the case?  Because I had volunteered to
> be Co-RM ...  For the benefit of James and others, some background is below.
>
> On October 14th Murali Nagendranath volunteered to be the RM for a 3.2.3
> release.  I replied:
> > Hi Murali,  I appreciate the volunteerism!   When a release is
> being cut, I would like to be heavily involved.  Co-release managers?
>
> My offer to share the burden received no reply.
>
> Six or so weeks later on December 5th Murali asked the devlist:
> > I wanted to check to see if there are objections to creating a 3.2.3 tag
> of trunk now to prepare for a 3.2.3-rc1?
>
> This got some pushback, which should be a valued part of the open
> process.  Positive movement was made over the next 48 hours to start to get
> things rolling toward resolving the noted problems with an immediate
> release - in large part by you (cheers).
>
> 9 days later on December 14th you wrote a report to the Apache board
> containing:
> >## Issues:
> >- The majority of the committee has been working very hard to push
> forward the next release since has been almost 2 years since the last
> release as pointed out in the last report.  There are volunteers and an RM
> already stepped forward and started the process. However, there is a small
> group which differs in opinion and prefers to delay/block the critical
> minor/patch release
>
> To be honest, I'm not sure that this is an accurate representation of the
> efforts, number of RM volunteers or size and impact of a new ctakes
> release.   It doesn't seem to paint the "small group" in a very favorable
> light.  I am not trying to antagonize, I am just going over what is
> publicly available in the devlist emails.
>
>
> In a deeper exploration of the history, this was not the first round of
> discussion on a 3.2.3 release.  Over a year ago on November 18th 2015 you
> tried to get the ball rolling:
> > It looks like there have been a lot of progress in Jira's.  What do
> folks think of preparing a cut for the next release- would be nice to get
> one more out before holidays/end of the year?
> >I'll be happy to volunteer to be RM again.
>
> I agreed with your assessment, thought that the software was in a good
> state for a release, and was happy that you volunteered to be RM as I
> indicated the next day:
> >Hi Pei, thanks ...
> > I say in my bazaar way: release early, release often ...
> > +1 for bumps and release ...
>
> I think that we all had great expectations, and your December report to
> the Apache board included:
> > - The committee is actively preparing for the next release 3.2.3
> (Tentatively targeted for Dec)
>
> Unfortunately by the March report to the Apache board the release was not
> cut:
> >- The committee is actively preparing features for the next release
> 3.2.3.  Folks are continuing after a busy holiday quarter.
>
> By the time of the June report the project was (probably) no longer in a
> releasable state, and your report contained no mention of it.  The
> September report had the line item:
> > - Committee will schedule a release as soon as they feel it's ready;
> previously pushed back as there hasn't been major features/changes to code
> base yet.  Committers will be able to volunteer to be RM as soon as
> committee/community is ready for a new release.
>
> I understand that because of the report you may personally feel like you
> are under the gun to get something out there asap.  As Murali is (I
> believe) your employee/coworker you may have faith that he will get things
> done.  But I would like to point out the plural in your statement
> "Committers will be able ..."  It seems that James is allowed to volunteer
> to be an RM.  I would also like to remind that 3 months ago I volunteered
> to be Co-RM and would love to have James' help - not just because he has
> previously been part of the release process, but also because he is one of
> the original visionaries of ctakes!
>
> Please take this kin

RE: (Re)introduce myself - James Masanz

[Finan, Sean]

Hi Pei,

I am a little taken back by your statement:
> I do not see an need for BCH to override existing volunteers.

>From what James  wrote, I don't get the feeling that he is trying to override 
>other RM volunteers or in any way take control of the release.  His email 
>stated specifically that he is volunteering to be the release manager, not 
>demanding the position.  Also, since by his own admission James has been away, 
>he may not be aware that anybody else has fully assumed the role.  Is that 
>indeed the case?  Because I had volunteered to be Co-RM ...  For the benefit 
>of James and others, some background is below.

On October 14th Murali Nagendranath volunteered to be the RM for a 3.2.3 
release.  I replied:
> Hi Murali,  I appreciate the volunteerism!   When a release is being 
> cut, I would like to be heavily involved.  Co-release managers?

My offer to share the burden received no reply.

Six or so weeks later on December 5th Murali asked the devlist:
> I wanted to check to see if there are objections to creating a 3.2.3 tag of 
> trunk now to prepare for a 3.2.3-rc1?

This got some pushback, which should be a valued part of the open process.  
Positive movement was made over the next 48 hours to start to get things 
rolling toward resolving the noted problems with an immediate release - in 
large part by you (cheers).

9 days later on December 14th you wrote a report to the Apache board containing:
>## Issues:
>- The majority of the committee has been working very hard to push forward the 
>next release since has been almost 2 years since the last release as pointed 
>out in the last report.  There are volunteers and an RM already stepped 
>forward and started the process. However, there is a small group which differs 
>in opinion and prefers to delay/block the critical minor/patch release

To be honest, I'm not sure that this is an accurate representation of the 
efforts, number of RM volunteers or size and impact of a new ctakes release.   
It doesn't seem to paint the "small group" in a very favorable light.  I am not 
trying to antagonize, I am just going over what is publicly available in the 
devlist emails.


In a deeper exploration of the history, this was not the first round of 
discussion on a 3.2.3 release.  Over a year ago on November 18th 2015 you tried 
to get the ball rolling:
> It looks like there have been a lot of progress in Jira's.  What do folks 
> think of preparing a cut for the next release- would be nice to get one more 
> out before holidays/end of the year? 
>I'll be happy to volunteer to be RM again.

I agreed with your assessment, thought that the software was in a good state 
for a release, and was happy that you volunteered to be RM as I indicated the 
next day:
>Hi Pei, thanks ...
> I say in my bazaar way: release early, release often ...  
> +1 for bumps and release ...

I think that we all had great expectations, and your December report to the 
Apache board included:
> - The committee is actively preparing for the next release 3.2.3 (Tentatively 
> targeted for Dec)

Unfortunately by the March report to the Apache board the release was not cut:
>- The committee is actively preparing features for the next release 3.2.3.  
>Folks are continuing after a busy holiday quarter.

By the time of the June report the project was (probably) no longer in a 
releasable state, and your report contained no mention of it.  The September 
report had the line item:
> - Committee will schedule a release as soon as they feel it's ready; 
> previously pushed back as there hasn't been major features/changes to code 
> base yet.  Committers will be able to volunteer to be RM as soon as 
> committee/community is ready for a new release.

I understand that because of the report you may personally feel like you are 
under the gun to get something out there asap.  As Murali is (I believe) your 
employee/coworker you may have faith that he will get things done.  But I would 
like to point out the plural in your statement "Committers will be able ..."  
It seems that James is allowed to volunteer to be an RM.  I would also like to 
remind that 3 months ago I volunteered to be Co-RM and would love to have 
James' help - not just because he has previously been part of the release 
process, but also because he is one of the original visionaries of ctakes!

Please take this kindly,
Sean


-Original Message-
From: Pei Chen [mailto:pei.c...@wiredinformatics.com] 
Sent: Friday, January 27, 2017 2:29 PM
To: dev@ctakes.apache.org
Subject: Re: (Re)introduce myself - James Masanz

Welcome back James!  Good to hear from you again. 
Out of respect for the others in the community who already volunteered to be 
RM, I do not see an need for BCH to override existing volunteers. Unless they 
unable or unwilling.
Would you/others agree? 

Sent from my iPhone

> 

Re: (Re)introduce myself - James Masanz

[Pei Chen]

Welcome back James!  Good to hear from you again. 
Out of respect for the others in the community who already volunteered to be 
RM, I do not see an need for BCH to override existing volunteers. Unless they 
unable or unwilling.
Would you/others agree? 

Sent from my iPhone

> On Jan 27, 2017, at 2:23 PM, James Masanz  wrote:
> 
> Hi,
> 
> I'm James Masanz -- if you've been on the dev list for more than a couple
> years, you might recognize my name from my previous contributions to
> cTAKES, which include having been a release manager.
> 
> I've joined the Boston Children's Hospital NLP team. I will be devoting
> significant energy to the next release of cTAKES, and I volunteer to be the
> release manager for it.
> 
> My initial thoughts are that we could make the "fast dictionary lookup" be
> the default dictionary lookup, incorporate the dictionary GUI from sandbox,
> and call the release 4.0. I'm also interested in migrating the Wiki away
> from Confluence to Apache's moin-moin instance. I'm sure there are other
> things to include in the next release as well.
> 
> You'll be hearing more from me over the next few weeks as I review the list
> of issues in Jira and get caught up with details of what's been going on
> while I was less active here.
> 
> One thing I would like to track for release candidates would be a list of
> what is tested on which platforms, which could be as simple as a post with
> a matrix of src/bin/other vs. linux/windows/mac, and making sure we have at
> least one volunteer to test the install and run of a pipeline for each
> entry in the table. Future releases might expand on that to include
> tracking multiple pipelines across environments, etc.
> 
> I'm happy I'm returning to being active in the cTAKES community!
> 
> -- James