From magnus.ihse.bursie at oracle.com Fri Nov 7 07:43:00 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 07 Nov 2014 08:43:00 +0100 Subject: RFR: CODETOOLS-7901088 webrev -f does not work on nawk Message-ID: <545C7804.4080403@oracle.com> Webrev -f does not work when using nawk, due to an incorrect substr based on 0 instead of 1 as index to the first position. (See prior discussion on webrev-dev). Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901088 Patch inline: diff --git a/webrev.ksh b/webrev.ksh --- a/webrev.ksh +++ b/webrev.ksh @@ -1420,7 +1420,7 @@ # the AWK code which still tries to handle both cases # hg tstatus -mdn $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v "hgroot=$hgroot" ' - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); tree=substr(tree,0,length(tree)-2); next} + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); tree=substr(tree,1,length(tree)-2); next} $1 != "" {n=index($1,tree); if (n != 1) { printf("%s/%s\n",tree,$1)} /Magnus From daniel.fuchs at oracle.com Fri Nov 7 11:33:28 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 07 Nov 2014 12:33:28 +0100 Subject: RFR: CODETOOLS-7901088 webrev -f does not work on nawk In-Reply-To: <545C937E.50109@oracle.com> References: <545C7804.4080403@oracle.com> <545C937E.50109@oracle.com> Message-ID: <545CAE08.5010509@oracle.com> Hi Magnus, With the below changes webrev is working satisfactorily on my machine - which has gawk. Please note that I'm not a (R)eviewer for CODE-TOOLS. best regards, -- daniel On 07/11/14 10:40, Daniel Fuchs wrote: > Hi Magnus, > > Thanks for finding the issue! > I see the same mistake in the function 'outgoing_from_mercurial_forest' > and twice again in the function fstatus - so it seems there are a few > other places to modify: > > ----------------------------- > diff --git a/webrev.ksh b/webrev.ksh > --- a/webrev.ksh > +++ b/webrev.ksh > @@ -1306,7 +1306,7 @@ function outgoing_from_mercurial_forest > /^comparing/ {next} > /^no changes/ {next} > /^searching/ {next} > - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,0,length(tree)-2); > + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,1,length(tree)-2); > if (tree == "") { tree="."; } > trees[ntree++] = tree; > revs[tree]=-1; > @@ -1420,7 +1420,7 @@ function fstatus > # the AWK code which still tries to handle both cases > # > hg tstatus -mdn $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v > "hgroot=$hgroot" ' > - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,0,length(tree)-2); next} > + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,1,length(tree)-2); next} > $1 != "" {n=index($1,tree); > if (n != 1) > { printf("%s/%s\n",tree,$1)} > @@ -1464,7 +1464,7 @@ function fstatus > # > > hg tstatus -aC $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v > "hgroot=$hgroot" ' > - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,0,length(tree)-2); next} > + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,1,length(tree)-2); next} > /^A .*/ {n=index($2,tree); > if (n != 1) > { printf("A %s/%s\n",tree,$2)} > @@ -1504,7 +1504,7 @@ function fstatus > done > done > hg tstatus -rn $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v > "hgroot=$hgroot" ' > - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,0,length(tree)-2); next} > + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,1,length(tree)-2); next} > $1 != "" {n=index($1,tree); > if (n != 1) > { printf("%s/%s\n",tree,$1)} > ----------------------------- > > The machine I am currently on doesn't work well with trees > (it has an old Mercurial) - I will test your patch in a few moments > on a more recent system and will let you know the result! > > best regards, > > -- daniel > > On 11/7/14 8:43 AM, Magnus Ihse Bursie wrote: >> Webrev -f does not work when using nawk, due to an incorrect substr >> based on 0 instead of 1 as index to the first position. (See prior >> discussion on webrev-dev). >> >> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901088 >> Patch inline: >> >> diff --git a/webrev.ksh b/webrev.ksh >> --- a/webrev.ksh >> +++ b/webrev.ksh >> @@ -1420,7 +1420,7 @@ >> # the AWK code which still tries to handle both cases >> # >> hg tstatus -mdn $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v >> "hgroot=$hgroot" ' >> - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); >> tree=substr(tree,0,length(tree)-2); next} >> + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); >> tree=substr(tree,1,length(tree)-2); next} >> $1 != "" {n=index($1,tree); >> if (n != 1) >> { printf("%s/%s\n",tree,$1)} >> >> /Magnus >> > From daniel.fuchs at oracle.com Fri Nov 7 09:40:14 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 07 Nov 2014 10:40:14 +0100 Subject: RFR: CODETOOLS-7901088 webrev -f does not work on nawk In-Reply-To: <545C7804.4080403@oracle.com> References: <545C7804.4080403@oracle.com> Message-ID: <545C937E.50109@oracle.com> Hi Magnus, Thanks for finding the issue! I see the same mistake in the function 'outgoing_from_mercurial_forest' and twice again in the function fstatus - so it seems there are a few other places to modify: ----------------------------- diff --git a/webrev.ksh b/webrev.ksh --- a/webrev.ksh +++ b/webrev.ksh @@ -1306,7 +1306,7 @@ function outgoing_from_mercurial_forest /^comparing/ {next} /^no changes/ {next} /^searching/ {next} - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); tree=substr(tree,0,length(tree)-2); + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); tree=substr(tree,1,length(tree)-2); if (tree == "") { tree="."; } trees[ntree++] = tree; revs[tree]=-1; @@ -1420,7 +1420,7 @@ function fstatus # the AWK code which still tries to handle both cases # hg tstatus -mdn $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v "hgroot=$hgroot" ' - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); tree=substr(tree,0,length(tree)-2); next} + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); tree=substr(tree,1,length(tree)-2); next} $1 != "" {n=index($1,tree); if (n != 1) { printf("%s/%s\n",tree,$1)} @@ -1464,7 +1464,7 @@ function fstatus # hg tstatus -aC $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v "hgroot=$hgroot" ' - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); tree=substr(tree,0,length(tree)-2); next} + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); tree=substr(tree,1,length(tree)-2); next} /^A .*/ {n=index($2,tree); if (n != 1) { printf("A %s/%s\n",tree,$2)} @@ -1504,7 +1504,7 @@ function fstatus done done hg tstatus -rn $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v "hgroot=$hgroot" ' - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); tree=substr(tree,0,length(tree)-2); next} + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); tree=substr(tree,1,length(tree)-2); next} $1 != "" {n=index($1,tree); if (n != 1) { printf("%s/%s\n",tree,$1)} ----------------------------- The machine I am currently on doesn't work well with trees (it has an old Mercurial) - I will test your patch in a few moments on a more recent system and will let you know the result! best regards, -- daniel On 11/7/14 8:43 AM, Magnus Ihse Bursie wrote: > Webrev -f does not work when using nawk, due to an incorrect substr > based on 0 instead of 1 as index to the first position. (See prior > discussion on webrev-dev). > > Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901088 > Patch inline: > > diff --git a/webrev.ksh b/webrev.ksh > --- a/webrev.ksh > +++ b/webrev.ksh > @@ -1420,7 +1420,7 @@ > # the AWK code which still tries to handle both cases > # > hg tstatus -mdn $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v > "hgroot=$hgroot" ' > - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,0,length(tree)-2); next} > + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,1,length(tree)-2); next} > $1 != "" {n=index($1,tree); > if (n != 1) > { printf("%s/%s\n",tree,$1)} > > /Magnus > From daniel.fuchs at oracle.com Fri Nov 7 09:43:10 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 07 Nov 2014 10:43:10 +0100 Subject: RFR: CODETOOLS-7901088 webrev -f does not work on nawk In-Reply-To: <545C937E.50109@oracle.com> References: <545C7804.4080403@oracle.com> <545C937E.50109@oracle.com> Message-ID: <545C942E.10403@oracle.com> Oh - and you should update the version number as well: - WEBREV_UPDATED=25.6-hg+openjdk.java.net + WEBREV_UPDATED=25.7-hg+openjdk.java.net best regards, -- daniel On 11/7/14 10:40 AM, Daniel Fuchs wrote: > Hi Magnus, > > Thanks for finding the issue! > I see the same mistake in the function 'outgoing_from_mercurial_forest' > and twice again in the function fstatus - so it seems there are a few > other places to modify: > > ----------------------------- > diff --git a/webrev.ksh b/webrev.ksh > --- a/webrev.ksh > +++ b/webrev.ksh > @@ -1306,7 +1306,7 @@ function outgoing_from_mercurial_forest > /^comparing/ {next} > /^no changes/ {next} > /^searching/ {next} > - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,0,length(tree)-2); > + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,1,length(tree)-2); > if (tree == "") { tree="."; } > trees[ntree++] = tree; > revs[tree]=-1; > @@ -1420,7 +1420,7 @@ function fstatus > # the AWK code which still tries to handle both cases > # > hg tstatus -mdn $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v > "hgroot=$hgroot" ' > - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,0,length(tree)-2); next} > + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,1,length(tree)-2); next} > $1 != "" {n=index($1,tree); > if (n != 1) > { printf("%s/%s\n",tree,$1)} > @@ -1464,7 +1464,7 @@ function fstatus > # > > hg tstatus -aC $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v > "hgroot=$hgroot" ' > - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,0,length(tree)-2); next} > + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,1,length(tree)-2); next} > /^A .*/ {n=index($2,tree); > if (n != 1) > { printf("A %s/%s\n",tree,$2)} > @@ -1504,7 +1504,7 @@ function fstatus > done > done > hg tstatus -rn $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v > "hgroot=$hgroot" ' > - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,0,length(tree)-2); next} > + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); > tree=substr(tree,1,length(tree)-2); next} > $1 != "" {n=index($1,tree); > if (n != 1) > { printf("%s/%s\n",tree,$1)} > ----------------------------- > > The machine I am currently on doesn't work well with trees > (it has an old Mercurial) - I will test your patch in a few moments > on a more recent system and will let you know the result! > > best regards, > > -- daniel > > On 11/7/14 8:43 AM, Magnus Ihse Bursie wrote: >> Webrev -f does not work when using nawk, due to an incorrect substr >> based on 0 instead of 1 as index to the first position. (See prior >> discussion on webrev-dev). >> >> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901088 >> Patch inline: >> >> diff --git a/webrev.ksh b/webrev.ksh >> --- a/webrev.ksh >> +++ b/webrev.ksh >> @@ -1420,7 +1420,7 @@ >> # the AWK code which still tries to handle both cases >> # >> hg tstatus -mdn $FSTAT_OPT 2>/dev/null | $FILTER | $AWK -v >> "hgroot=$hgroot" ' >> - /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); >> tree=substr(tree,0,length(tree)-2); next} >> + /^\[.*\]:$/ {tree=substr($1,length(hgroot)+3); >> tree=substr(tree,1,length(tree)-2); next} >> $1 != "" {n=index($1,tree); >> if (n != 1) >> { printf("%s/%s\n",tree,$1)} >> >> /Magnus >> > From kevin.looney at oracle.com Tue Nov 11 18:10:15 2014 From: kevin.looney at oracle.com (Kevin Looney) Date: Tue, 11 Nov 2014 10:10:15 -0800 Subject: New CodeTools Committer: Alexey Fedorchenko In-Reply-To: <535EBEFC.50508@oracle.com> References: <535EBEFC.50508@oracle.com> Message-ID: <54625107.8040109@oracle.com> |**I hereby nominate Alexey Fedorchenko to CodeTools Committer. Alexey is the lead of the JCov Code Tools project, and is skilled in the design and implementation of code coverage tools. Alexey has participated in the commercial implementation of JCov, and was primarily responsible for the Open Source introduction of JCov into OpenJDK: Code Tools. Alexey has had Author rights for some time and has by proxy submitted substantial code changes, see: | ||http://hg.openjdk.java.net/code-tools/jcov/search/?rev=alexey.fedorchenko| Votes are due by November 252014 PDT (11/25/14). Only current CodeTools Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Kevin Looney [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote | -- kevin.looney at oracle.com From staffan.larsen at oracle.com Tue Nov 11 20:42:42 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 11 Nov 2014 21:42:42 +0100 Subject: jtreg nightly build version change In-Reply-To: <52DEA245.9050303@oracle.com> References: <52DD6129.1010703@oracle.com> <52DEA245.9050303@oracle.com> Message-ID: <26FBE2E8-0D66-479B-BF60-D3F138712A19@oracle.com> I think the latest tag is -b10: changeset: 119:5be369356d9f user: jjg date: Fri Oct 24 11:57:32 2014 -0700 summary: Added tag jtreg4.1-b10 for changeset 8c3179c3ebda /Staffan > On 21 jan 2014, at 17:37, Jonathan Gibbons wrote: > > Martin, > > Right now, the latest tag in the repo should be jtreg4.1-b08. It seems to be it would be good if your build could reflect that. There should be enough hooks in the build script to allow you to set the version. > > -- Jon > > On 01/20/2014 09:54 AM, Martijn Verburg wrote: >> Hi Jonathan, >> >> Thanks for the info. In that case I'll change the build to produce a 4.2.0-SNAPSHOT following the traditional model. I guess we can then work on the build script to allow it to produce formal releases (such as 4.2.0) to Maven central. >> >> I don't have permission to raise an issue directly in JBUG for this, are you able to or does it still need to go through the bugs.sun... method? >> >> >> >> Cheers, >> Martijn >> >> >> On 20 January 2014 17:47, Jonathan Gibbons >> wrote: >> >> On 01/18/2014 05:29 AM, Martijn Verburg wrote: >> >> Hi all, >> >> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >> now produces a Maven compatible 5.0.0-SNAPSHOT version of jtreg. >> >> This was to make the download and install for the Virtual >> Machines we're producing for the build-farm as well as making >> jtreg Maven repo compatible. >> >> IIRC jtreg was last released as version 4.3? Hopefully 5.0.0 >> is the next logical number. >> >> Probably needs a conversation about how to deal with >> versioning and if jtreg can be uploaded to Maven Central or >> not (any legal barriers?). >> >> Cheers, >> Martijn >> >> >> Martijn, >> >> jtreg has never been 4.3. I think you're confusing it with the >> version of JTHarness that it uses. >> >> For a while now, jtreg has been using jtreg 4.1 bNN where NN is a >> small interger, currently 08. This was more significant when we >> (Oracle) were producing binary builds. Now that we are no longer >> doing that, I think we will start advancing the jtreg number in a >> more conventional fashion. >> >> I had hoped to combine the advance to 4.2 with a major update to >> the jtreg documentation, but that seems to be never quite high >> enough priority to have anything happen :-( >> >> -- Jon From sadhak001 at gmail.com Fri Nov 21 23:22:50 2014 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 21 Nov 2014 23:22:50 +0000 Subject: jtreg nightly build version change In-Reply-To: <26FBE2E8-0D66-479B-BF60-D3F138712A19@oracle.com> References: <52DD6129.1010703@oracle.com> <52DEA245.9050303@oracle.com> <26FBE2E8-0D66-479B-BF60-D3F138712A19@oracle.com> Message-ID: Sorry guys just catching up with mails, I check Cloudbees and b10 is reflected on the latest build. I'm guessing this is sorted now. Cheers, Mani On Tue, Nov 11, 2014 at 8:42 PM, Staffan Larsen wrote: > I think the latest tag is -b10: > > changeset: 119:5be369356d9f > user: jjg > date: Fri Oct 24 11:57:32 2014 -0700 > summary: Added tag jtreg4.1-b10 for changeset 8c3179c3ebda > > /Staffan > > > On 21 jan 2014, at 17:37, Jonathan Gibbons > wrote: > > > > Martin, > > > > Right now, the latest tag in the repo should be jtreg4.1-b08. It seems > to be it would be good if your build could reflect that. There should be > enough hooks in the build script to allow you to set the version. > > > > -- Jon > > > > On 01/20/2014 09:54 AM, Martijn Verburg wrote: > >> Hi Jonathan, > >> > >> Thanks for the info. In that case I'll change the build to produce a > 4.2.0-SNAPSHOT following the traditional model. I guess we can then work on > the build script to allow it to produce formal releases (such as 4.2.0) to > Maven central. > >> > >> I don't have permission to raise an issue directly in JBUG for this, > are you able to or does it still need to go through the bugs.sun... method? > >> > >> > >> > >> Cheers, > >> Martijn > >> > >> > >> On 20 January 2014 17:47, Jonathan Gibbons >> wrote: > >> > >> On 01/18/2014 05:29 AM, Martijn Verburg wrote: > >> > >> Hi all, > >> > >> > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > >> now produces a Maven compatible 5.0.0-SNAPSHOT version of jtreg. > >> > >> This was to make the download and install for the Virtual > >> Machines we're producing for the build-farm as well as making > >> jtreg Maven repo compatible. > >> > >> IIRC jtreg was last released as version 4.3? Hopefully 5.0.0 > >> is the next logical number. > >> > >> Probably needs a conversation about how to deal with > >> versioning and if jtreg can be uploaded to Maven Central or > >> not (any legal barriers?). > >> > >> Cheers, > >> Martijn > >> > >> > >> Martijn, > >> > >> jtreg has never been 4.3. I think you're confusing it with the > >> version of JTHarness that it uses. > >> > >> For a while now, jtreg has been using jtreg 4.1 bNN where NN is a > >> small interger, currently 08. This was more significant when we > >> (Oracle) were producing binary builds. Now that we are no longer > >> doing that, I think we will start advancing the jtreg number in a > >> more conventional fashion. > >> > >> I had hoped to combine the advance to 4.2 with a major update to > >> the jtreg documentation, but that seems to be never quite high > >> enough priority to have anything happen :-( > >> > >> -- Jon > > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From jonathan.gibbons at oracle.com Mon Nov 24 22:45:29 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 24 Nov 2014 14:45:29 -0800 Subject: New CodeTools Committer: Alexey Fedorchenko In-Reply-To: <54625107.8040109@oracle.com> References: <535EBEFC.50508@oracle.com> <54625107.8040109@oracle.com> Message-ID: <5473B509.7000408@oracle.com> Vote: yes -- Jon On 11/11/2014 10:10 AM, Kevin Looney wrote: > |**I hereby nominate Alexey Fedorchenko to CodeTools Committer. > > > Alexey is the lead of the JCov Code Tools project, and is > skilled in the design and implementation of code coverage tools. Alexey > has participated in the commercial implementation of JCov, and was > primarily responsible for the Open Source introduction of JCov into > OpenJDK: Code Tools. Alexey has had Author rights for some time > and has by proxy submitted substantial code changes, see: > | > ||http://hg.openjdk.java.net/code-tools/jcov/search/?rev=alexey.fedorchenko| > > > Votes are due by November 252014 PDT (11/25/14). > > Only current CodeTools Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > > Thanks, > Kevin Looney > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > | > From brian.kurotsuchi at oracle.com Tue Nov 25 08:11:07 2014 From: brian.kurotsuchi at oracle.com (Brian Kurotsuchi) Date: Tue, 25 Nov 2014 01:11:07 -0700 Subject: New CodeTools Committer: Alexey Fedorchenko In-Reply-To: <54625107.8040109@oracle.com> References: <535EBEFC.50508@oracle.com> <54625107.8040109@oracle.com> Message-ID: <5474399B.7030902@oracle.com> Vote: yes On 11/11/14 11:10, Kevin Looney wrote: > |**I hereby nominate Alexey Fedorchenko to CodeTools Committer. > > > Alexey is the lead of the JCov Code Tools project, and is > skilled in the design and implementation of code coverage tools. Alexey > has participated in the commercial implementation of JCov, and was > primarily responsible for the Open Source introduction of JCov into > OpenJDK: Code Tools. Alexey has had Author rights for some time > and has by proxy submitted substantial code changes, see: > | > ||http://hg.openjdk.java.net/code-tools/jcov/search/?rev=alexey.fedorchenko| > > > Votes are due by November 252014 PDT (11/25/14). > > Only current CodeTools Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > > Thanks, > Kevin Looney > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > | > From Mikhail.Ershov at oracle.com Tue Nov 25 13:11:17 2014 From: Mikhail.Ershov at oracle.com (Mikhail Ershov) Date: Tue, 25 Nov 2014 16:11:17 +0300 Subject: New CodeTools Committer: Alexey Fedorchenko In-Reply-To: <54625107.8040109@oracle.com> References: <535EBEFC.50508@oracle.com> <54625107.8040109@oracle.com> Message-ID: <54747FF5.1010004@oracle.com> Vote: yes Mike On 11.11.2014 21:10, Kevin Looney wrote: > |**I hereby nominate Alexey Fedorchenko to CodeTools Committer. > > > Alexey is the lead of the JCov Code Tools project, and is > skilled in the design and implementation of code coverage tools. Alexey > has participated in the commercial implementation of JCov, and was > primarily responsible for the Open Source introduction of JCov into > OpenJDK: Code Tools. Alexey has had Author rights for some time > and has by proxy submitted substantial code changes, see: > | > ||http://hg.openjdk.java.net/code-tools/jcov/search/?rev=alexey.fedorchenko| > > > Votes are due by November 252014 PDT (11/25/14). > > Only current CodeTools Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > > Thanks, > Kevin Looney > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > | > From kevin.looney at oracle.com Tue Nov 25 17:02:26 2014 From: kevin.looney at oracle.com (Kevin Looney) Date: Tue, 25 Nov 2014 09:02:26 -0800 Subject: Result: New CodeTools Committer: Alexey Fedorchenko Message-ID: <5474B622.7060503@oracle.com> Voting for Alexey Fedorchenko [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Kevin Looney [1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2014-November/000103.html -- kevin.looney at oracle.com