Re: CHANGES.txt?
Hi All, I hope all are agreeing to remove CHANGE.txt file from ZK project repository. I believe, ZOOKEEPER-2672 jira needs to be concluded(to avoid confusions) before cutting 3.4.10 release. I'm planning to remove CHANGE.txt file in 2 days time frame, 8 February 2017, 6:00 PM (PST), if there is no objection. Thanks! Thanks & Regards, Rakesh On Thu, Feb 2, 2017 at 9:06 PM, Rakesh Radhakrishnan <rake...@apache.org> wrote: > +1 for removing the CHANGE.txt file. > > I agree to rely on source control (github) revision logs instead of > CHANGE.txt moving forward. > > Note: Jira issue ZOOKEEPER-2672 will be used to remove this file. > > Thanks, > Rakesh > > > On Sat, Dec 17, 2016 at 3:59 AM, Michael Han <h...@cloudera.com> wrote: > >> See https://www.mail-archive.com/dev@zookeeper.apache.org/msg37108.html >> >> I think there was no decision explicitly made but looks like every one was >> OK to head towards the direction of removing CHANGE.TXT. >> >> On Fri, Dec 16, 2016 at 3:14 AM, Flavio Junqueira <f...@apache.org> wrote: >> >> > Could anyone remind me of what we decided for CHANGES.txt? Are we >> supposed >> > to add resolved jiras to it or are we going to rely on the git log? >> > >> > I have committed ZK-761 to master without the change to CHANGES.txt, but >> > then I noticed that some commits are going in with it, so I did it to >> the >> > 3.5 branch. I want to know if I need to make it consistent or not. >> > >> > -Flavio >> >> >> >> >> -- >> Cheers >> Michael. >> > >
Re: CHANGES.txt?
+1 for removing the CHANGE.txt file. I agree to rely on source control (github) revision logs instead of CHANGE.txt moving forward. Note: Jira issue ZOOKEEPER-2672 will be used to remove this file. Thanks, Rakesh On Sat, Dec 17, 2016 at 3:59 AM, Michael Han <h...@cloudera.com> wrote: > See https://www.mail-archive.com/dev@zookeeper.apache.org/msg37108.html > > I think there was no decision explicitly made but looks like every one was > OK to head towards the direction of removing CHANGE.TXT. > > On Fri, Dec 16, 2016 at 3:14 AM, Flavio Junqueira <f...@apache.org> wrote: > > > Could anyone remind me of what we decided for CHANGES.txt? Are we > supposed > > to add resolved jiras to it or are we going to rely on the git log? > > > > I have committed ZK-761 to master without the change to CHANGES.txt, but > > then I noticed that some commits are going in with it, so I did it to the > > 3.5 branch. I want to know if I need to make it consistent or not. > > > > -Flavio > > > > > -- > Cheers > Michael. >
Re: CHANGES.txt?
See https://www.mail-archive.com/dev@zookeeper.apache.org/msg37108.html I think there was no decision explicitly made but looks like every one was OK to head towards the direction of removing CHANGE.TXT. On Fri, Dec 16, 2016 at 3:14 AM, Flavio Junqueira <f...@apache.org> wrote: > Could anyone remind me of what we decided for CHANGES.txt? Are we supposed > to add resolved jiras to it or are we going to rely on the git log? > > I have committed ZK-761 to master without the change to CHANGES.txt, but > then I noticed that some commits are going in with it, so I did it to the > 3.5 branch. I want to know if I need to make it consistent or not. > > -Flavio -- Cheers Michael.
CHANGES.txt?
Could anyone remind me of what we decided for CHANGES.txt? Are we supposed to add resolved jiras to it or are we going to rely on the git log? I have committed ZK-761 to master without the change to CHANGES.txt, but then I noticed that some commits are going in with it, so I did it to the 3.5 branch. I want to know if I need to make it consistent or not. -Flavio
Re: CHANGES.txt inconsistency
Thank you, Flavio. Yes, this probably explains the "missing" minor releases. --Chris Nauroth On 7/24/16, 8:09 AM, "Flavio Junqueira" <f...@apache.org> wrote: > On 21 Jul 2016, at 23:59, Chris Nauroth <cnaur...@hortonworks.com> wrote: > > While working on the 3.5.2-alpha release, I noticed that CHANGES.txt in trunk is not completely synchronized with the 3.5 release line. In branch-3.5, we have sections for releases 3.5.0, 3.5.1 and 3.5.2 (added by me), each indicating their respective release dates. In trunk, release 3.5.0 is mentioned, but not release 3.5.1. I have not yet added anything about 3.5.2, because I wasn't sure if the omission of 3.5.1 was an oversight or intentional. > > More generally, it appears that on any given branch, CHANGES.txt does not comprehensively cover the prior major release lines. On branch-3.5, CHANGES.txt mentions release 3.4.0, release 3.3.0, etc., but not any of the subsequent releases in those lines, like the recent 3.4.8. In the first paragraph, you mention that trunk mentions 3.5.0, but not 3.5.1. On the 3.5 branch, we mention 3.3.0 and 3.4.0, but not the subsequent release. I think in both cases it is just an artifact of starting a new trunk branch as soon as we cut the first release of a branch. There is no inconsistency afaict. For example, when we cut the 3.6.0 release, we will start a new trunk and trunk will have a mention to 3.6.0, but not subsequent releases of the 3.6 branch. > > Is this something we need to correct? Is it even worthwhile to keep maintaining CHANGES.txt, or is it not worth the effort? FWIW, other projects like Hadoop and HBase have abandoned maintaining CHANGES.txt files and instead rely on the revision log for patch attribution and various forms of automation for generating release notes. > I'd be fine with using the revision log. -Flavio
Re: CHANGES.txt inconsistency
Hadoop utilizes a script from Yetus that generates release notes automatically by querying JIRA, in particular the optional Release Note field on each JIRA issue. http://yetus.apache.org/documentation/0.3.0/releasedocmaker/ This doesn’t require additional maintenance of a CHANGES.txt file. Now that I’ve performed the ZooKeeper release management process once, it appears to me that there currently is no real dependency on the CHANGES.txt file to provide any user-facing information. We copy our release notes HTML out of JIRA’s view and paste it into our site docs during the release. For patch attribution, revision control is authoritative, and I don’t think the choice of git vs. svn makes a difference as long as we are diligent about crediting the correct author in the commit message. We’ve talked a bit before about trying to improve the build toolchain, with the general feeling that we should migrate to Maven first and then consider using Yetus for its new pre-commit capabilities. However, I don’t think any of that needs to be a pre-requisite for dropping CHANGES.txt. The one place where I see CHANGES.txt impacting a built deliverable is that we currently bundle it into the distribution tarball. If we feel it important to have a file showing patch attribution within that tarball, then I suppose we need to keep it. Personally, I think it’s OK to say source control is the system of record for that. --Chris Nauroth On 7/22/16, 8:49 PM, "Patrick Hunt" <ph...@apache.org> wrote: On Thu, Jul 21, 2016 at 3:59 PM, Chris Nauroth <cnaur...@hortonworks.com> wrote: > While working on the 3.5.2-alpha release, I noticed that CHANGES.txt in > trunk is not completely synchronized with the 3.5 release line. In > branch-3.5, we have sections for releases 3.5.0, 3.5.1 and 3.5.2 (added by > me), each indicating their respective release dates. In trunk, release > 3.5.0 is mentioned, but not release 3.5.1. I have not yet added anything > about 3.5.2, because I wasn't sure if the omission of 3.5.1 was an > oversight or intentional. > > More generally, it appears that on any given branch, CHANGES.txt does not > comprehensively cover the prior major release lines. On branch-3.5, > CHANGES.txt mentions release 3.4.0, release 3.3.0, etc., but not any of the > subsequent releases in those lines, like the recent 3.4.8. > > Is this something we need to correct? Is it even worthwhile to keep > maintaining CHANGES.txt, or is it not worth the effort? FWIW, other > projects like Hadoop and HBase have abandoned maintaining CHANGES.txt files > and instead rely on the revision log for patch attribution and various > forms of automation for generating release notes. > > It's been like that as far as I can remember. I don't see why we couldn't adopt the same approach as used by the other teams, if that makes the result better and our lives easier. It's a real pain, and very error prone, to try and keep the changes.txt up to date aside from the issues you mentioned as it's maintained "by hand" for each commit. What do hadoop/hbase do wrt to this information? Do we need to move to git (as these other teams have done) or can we do this with svn? Patrick
Re: CHANGES.txt inconsistency
On Thu, Jul 21, 2016 at 3:59 PM, Chris Nauroth <cnaur...@hortonworks.com> wrote: > While working on the 3.5.2-alpha release, I noticed that CHANGES.txt in > trunk is not completely synchronized with the 3.5 release line. In > branch-3.5, we have sections for releases 3.5.0, 3.5.1 and 3.5.2 (added by > me), each indicating their respective release dates. In trunk, release > 3.5.0 is mentioned, but not release 3.5.1. I have not yet added anything > about 3.5.2, because I wasn't sure if the omission of 3.5.1 was an > oversight or intentional. > > More generally, it appears that on any given branch, CHANGES.txt does not > comprehensively cover the prior major release lines. On branch-3.5, > CHANGES.txt mentions release 3.4.0, release 3.3.0, etc., but not any of the > subsequent releases in those lines, like the recent 3.4.8. > > Is this something we need to correct? Is it even worthwhile to keep > maintaining CHANGES.txt, or is it not worth the effort? FWIW, other > projects like Hadoop and HBase have abandoned maintaining CHANGES.txt files > and instead rely on the revision log for patch attribution and various > forms of automation for generating release notes. > > It's been like that as far as I can remember. I don't see why we couldn't adopt the same approach as used by the other teams, if that makes the result better and our lives easier. It's a real pain, and very error prone, to try and keep the changes.txt up to date aside from the issues you mentioned as it's maintained "by hand" for each commit. What do hadoop/hbase do wrt to this information? Do we need to move to git (as these other teams have done) or can we do this with svn? Patrick
CHANGES.txt inconsistency
While working on the 3.5.2-alpha release, I noticed that CHANGES.txt in trunk is not completely synchronized with the 3.5 release line. In branch-3.5, we have sections for releases 3.5.0, 3.5.1 and 3.5.2 (added by me), each indicating their respective release dates. In trunk, release 3.5.0 is mentioned, but not release 3.5.1. I have not yet added anything about 3.5.2, because I wasn't sure if the omission of 3.5.1 was an oversight or intentional. More generally, it appears that on any given branch, CHANGES.txt does not comprehensively cover the prior major release lines. On branch-3.5, CHANGES.txt mentions release 3.4.0, release 3.3.0, etc., but not any of the subsequent releases in those lines, like the recent 3.4.8. Is this something we need to correct? Is it even worthwhile to keep maintaining CHANGES.txt, or is it not worth the effort? FWIW, other projects like Hadoop and HBase have abandoned maintaining CHANGES.txt files and instead rely on the revision log for patch attribution and various forms of automation for generating release notes. --Chris Nauroth
Re: svn commit: r1747408 - in /zookeeper/trunk: CHANGES.txt src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
Hey Pat,
On 14 June 2016 at 21:18, Patrick Hunt <ph...@apache.org> wrote:
> Raul, what's the status on this? Seems like trunk was committed but not
> 3.5? We don't want to lose track.
>
Yup - I was waiting on Chris before pushing to 3.5.
@Chris: may I push?
-rgs
>
> Patrick
>
> On Wed, Jun 8, 2016 at 8:43 AM, <r...@apache.org> wrote:
>
>> Author: rgs
>> Date: Wed Jun 8 15:43:15 2016
>> New Revision: 1747408
>>
>> URL: http://svn.apache.org/viewvc?rev=1747408=rev
>> Log:
>> ZOOKEEPER-2442: Socket leak in QuorumCnxManager connectOne
>> (Michael Han via rgs)
>>
>> Modified:
>> zookeeper/trunk/CHANGES.txt
>>
>> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
>>
>> Modified: zookeeper/trunk/CHANGES.txt
>> URL:
>> http://svn.apache.org/viewvc/zookeeper/trunk/CHANGES.txt?rev=1747408=1747407=1747408=diff
>>
>> ==
>> --- zookeeper/trunk/CHANGES.txt (original)
>> +++ zookeeper/trunk/CHANGES.txt Wed Jun 8 15:43:15 2016
>> @@ -308,6 +308,9 @@ BUGFIXES:
>>ZOOKEEPER-2405: getTGT() in Login.java mishandles confidential
>>information (Michael Han via phunt)
>>
>> + ZOOKEEPER-2442: Socket leak in QuorumCnxManager connectOne
>> + (Michael Han via rgs)
>> +
>> IMPROVEMENTS:
>>ZOOKEEPER-2024 Major throughput improvement with mixed workloads (Kfir
>> Lev-Ari via shralex)
>>
>>
>> Modified:
>> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
>> URL:
>> http://svn.apache.org/viewvc/zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java?rev=1747408=1747407=1747408=diff
>>
>> ==
>> ---
>> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
>> (original)
>> +++
>> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
>> Wed Jun 8 15:43:15 2016
>> @@ -237,9 +237,7 @@ public class QuorumCnxManager {
>> * @param sid
>> */
>> public void testInitiateConnection(long sid) throws Exception {
>> -if (LOG.isDebugEnabled()) {
>> -LOG.debug("Opening channel to server " + sid);
>> -}
>> +LOG.debug("Opening channel to server " + sid);
>> Socket sock = new Socket();
>> setSockOpts(sock);
>> sock.connect(self.getVotingView().get(sid).electionAddr, cnxTO);
>> @@ -434,17 +432,14 @@ public class QuorumCnxManager {
>> LOG.debug("There is a connection already for server " + sid);
>> return true;
>> }
>> -try {
>>
>> - if (LOG.isDebugEnabled()) {
>> - LOG.debug("Opening channel to server " + sid);
>> - }
>> - Socket sock = new Socket();
>> +Socket sock = null;
>> +try {
>> + LOG.debug("Opening channel to server " + sid);
>> + sock = new Socket();
>> setSockOpts(sock);
>> sock.connect(electionAddr, cnxTO);
>> - if (LOG.isDebugEnabled()) {
>> - LOG.debug("Connected to server " + sid);
>> - }
>> + LOG.debug("Connected to server " + sid);
>> initiateConnection(sock, sid);
>> return true;
>> } catch (UnresolvedAddressException e) {
>> @@ -454,11 +449,13 @@ public class QuorumCnxManager {
>> // detail.
>> LOG.warn("Cannot open channel to " + sid
>> + " at election address " + electionAddr, e);
>> + closeSocket(sock);
>> throw e;
>> } catch (IOException e) {
>> LOG.warn("Cannot open channel to " + sid
>> + " at election address " + electionAddr,
>> e);
>> + closeSocket(sock);
>> return false;
>> }
>>
>> @@ -574,6 +571,10 @@ public class QuorumCnxManager {
>> *Reference to socket
>> */
>> private void closeSocket(Socket sock) {
>> +if (sock == null) {
>> +return;
>> +}
>> +
>>
Re: svn commit: r1747408 - in /zookeeper/trunk: CHANGES.txt src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
Raul, what's the status on this? Seems like trunk was committed but not
3.5? We don't want to lose track.
Patrick
On Wed, Jun 8, 2016 at 8:43 AM, <r...@apache.org> wrote:
> Author: rgs
> Date: Wed Jun 8 15:43:15 2016
> New Revision: 1747408
>
> URL: http://svn.apache.org/viewvc?rev=1747408=rev
> Log:
> ZOOKEEPER-2442: Socket leak in QuorumCnxManager connectOne
> (Michael Han via rgs)
>
> Modified:
> zookeeper/trunk/CHANGES.txt
>
> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
>
> Modified: zookeeper/trunk/CHANGES.txt
> URL:
> http://svn.apache.org/viewvc/zookeeper/trunk/CHANGES.txt?rev=1747408=1747407=1747408=diff
>
> ======
> --- zookeeper/trunk/CHANGES.txt (original)
> +++ zookeeper/trunk/CHANGES.txt Wed Jun 8 15:43:15 2016
> @@ -308,6 +308,9 @@ BUGFIXES:
>ZOOKEEPER-2405: getTGT() in Login.java mishandles confidential
>information (Michael Han via phunt)
>
> + ZOOKEEPER-2442: Socket leak in QuorumCnxManager connectOne
> + (Michael Han via rgs)
> +
> IMPROVEMENTS:
>ZOOKEEPER-2024 Major throughput improvement with mixed workloads (Kfir
> Lev-Ari via shralex)
>
>
> Modified:
> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
> URL:
> http://svn.apache.org/viewvc/zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java?rev=1747408=1747407=1747408=diff
>
> ==
> ---
> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
> (original)
> +++
> zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
> Wed Jun 8 15:43:15 2016
> @@ -237,9 +237,7 @@ public class QuorumCnxManager {
> * @param sid
> */
> public void testInitiateConnection(long sid) throws Exception {
> -if (LOG.isDebugEnabled()) {
> -LOG.debug("Opening channel to server " + sid);
> -}
> +LOG.debug("Opening channel to server " + sid);
> Socket sock = new Socket();
> setSockOpts(sock);
> sock.connect(self.getVotingView().get(sid).electionAddr, cnxTO);
> @@ -434,17 +432,14 @@ public class QuorumCnxManager {
> LOG.debug("There is a connection already for server " + sid);
> return true;
> }
> -try {
>
> - if (LOG.isDebugEnabled()) {
> - LOG.debug("Opening channel to server " + sid);
> - }
> - Socket sock = new Socket();
> +Socket sock = null;
> +try {
> + LOG.debug("Opening channel to server " + sid);
> + sock = new Socket();
> setSockOpts(sock);
> sock.connect(electionAddr, cnxTO);
> - if (LOG.isDebugEnabled()) {
> - LOG.debug("Connected to server " + sid);
> - }
> + LOG.debug("Connected to server " + sid);
> initiateConnection(sock, sid);
> return true;
> } catch (UnresolvedAddressException e) {
> @@ -454,11 +449,13 @@ public class QuorumCnxManager {
> // detail.
> LOG.warn("Cannot open channel to " + sid
> + " at election address " + electionAddr, e);
> + closeSocket(sock);
> throw e;
> } catch (IOException e) {
> LOG.warn("Cannot open channel to " + sid
> + " at election address " + electionAddr,
> e);
> + closeSocket(sock);
> return false;
> }
>
> @@ -574,6 +571,10 @@ public class QuorumCnxManager {
> *Reference to socket
> */
> private void closeSocket(Socket sock) {
> +if (sock == null) {
> +return;
> +}
> +
> try {
> sock.close();
> } catch (IOException ie) {
> @@ -614,7 +615,7 @@ public class QuorumCnxManager {
> public void run() {
> int numRetries = 0;
> InetSocketAddress addr;
> -
> +Socket client = null;
> while((!shutdown) && (numRetries < 3)){
> try {
> ss = new ServerSocket();
> @@ -632,7 +633,7 @@ public class QuorumCnxManager {
> setName(addr.toString());
> ss.bind(addr);
> while (
Re: CHANGES.txt
We can extract the same information from svn log, although there it is flat and not as organized as in changes.txt (e.g., per branch). The release notes we have been publishing per release does not contain the patch contributor or the committer who checked it in. Perhaps there is a way of doing it through jira directly, though. -Flavio On Sunday, May 17, 2015 5:09 AM, Michi Mutsuzaki mutsuz...@gmail.com wrote: Do we still need to manually maintain CHANGES.txt? I didn't realize that jira can generate release notes.
CHANGES.txt
Do we still need to manually maintain CHANGES.txt? I didn't realize that jira can generate release notes.
Re: 4.2.1 issues in CHANGES.txt
We usually will maintain in Hadoop like that. That is why I asked. see in Hadoop trunk about branch releases: Release 2.0.3-alpha - 2013-02-06 That seems strange to me. Trunk for us is not a descendant of 4.2.1. Their history diverged at the time 4.2 was branched. The changes in 4.2.1 are also in trunk, but they happened in different commits, so they were put in the CHANGES.txt section for trunk. Putting them in a 4.2.1 section in the trunk CHANGES.txt was suggest that the 4.2.1 history is a prefix of trunk history, which is not true. -Ivan
4.2.1 issues in CHANGES.txt
Hi All, I think we should add 4.2.1 fixed issues into released version category in CHANGES.txt right? I did not see 4.2.1 released issues separately in CHANGES.txt file. Regards, Uma
Re: 4.2.1 issues in CHANGES.txt
Uma, 4.2.1 release belongs to 4.2 branch. so its release note is updated in branch-4.2 CHANGES.txt. -Sijie On Thu, Mar 21, 2013 at 6:22 AM, Uma Maheswara Rao G mahesw...@huawei.comwrote: Hi All, I think we should add 4.2.1 fixed issues into released version category in CHANGES.txt right? I did not see 4.2.1 released issues separately in CHANGES.txt file. Regards, Uma
Re: 4.2.1 issues in CHANGES.txt
OK, Thanks Sijie. We usually will maintain in Hadoop like that. That is why I asked. see in Hadoop trunk about branch releases: Release 2.0.3-alpha - 2013-02-06 INCOMPATIBLE CHANGES HDFS-4122. Cleanup HDFS logs and reduce the size of logged messages. (suresh) Regards, Uma On Thu, Mar 21, 2013 at 10:38 PM, Sijie Guo guosi...@gmail.com wrote: Uma, 4.2.1 release belongs to 4.2 branch. so its release note is updated in branch-4.2 CHANGES.txt. -Sijie On Thu, Mar 21, 2013 at 6:22 AM, Uma Maheswara Rao G mahesw...@huawei.comwrote: Hi All, I think we should add 4.2.1 fixed issues into released version category in CHANGES.txt right? I did not see 4.2.1 released issues separately in CHANGES.txt file. Regards, Uma
Re: CHANGES.txt
The CHNAGES.txt file has served us well in the hadoop land as well. +1. dhruba On Thu, May 19, 2011 at 7:59 AM, Benjamin Reed br...@apache.org wrote: i agree. we need to add a CHANGES.txt. ben On Thu, May 19, 2011 at 1:35 AM, Flavio Junqueira f...@yahoo-inc.com wrote: Hi, One quick question: should we have a CHANGES.txt file containing committed jiras as we have for zookeeper? If so, should it be per component or global? My preference is to have this file updated upon every commit and have it on the project root, covering all components. This way will be easier when producing new releases. -Flavio -- Connect to me at http://www.facebook.com/dhruba
