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:[email protected]] Sent: Friday, January 27, 2017 2:29 PM To: [email protected] 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 <[email protected]> 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
