Re: [VOTE] Apache MXNet (incubating) 1.3.0 release RC0

[Sergio Fernández]

+1 (binding)

So far I've checked:
* signatures and digests (md5 checksums can be removed)
* source releases file layouts
* matched git tags and commit ids
* incubator suffix and disclaimer
* LICENSE & NOTICE files look good
* no binary files in the source release
* clean build (osx 10.12.6)

I'd like to state this is a just a legal binding vote, which is what we
check at this stage. Functionally speaking the podling is responsible of
the good state of every release. I remark that because from the dev@ vote I
can't see that feeling represented unanimously by the community.


On Fri, Sep 7, 2018, 11:36 Roshani Nagmote 
wrote:

> Hi all,
>
> This is a call for releasing Apache MXNet (incubating) 1.3.0, release
> candidate RC0.
>
> Apache MXNet (incubating) community has voted and approved the release.
>
> Vote thread:
>
> *
> https://lists.apache.org/thread.html/8ad6f14811be465cdf663d6962980fd95e12193626292631a21ec6f1@%3Cdev.mxnet.apache.org%3E
> <
> https://lists.apache.org/thread.html/8ad6f14811be465cdf663d6962980fd95e12193626292631a21ec6f1@%3Cdev.mxnet.apache.org%3E
> >*
>
> Results thread:
>
> *
> https://lists.apache.org/thread.html/8dad26e9a485180a3dd36f2b54de24395b626a57b5e847bc99dda0e9@%3Cdev.mxnet.apache.org%3E
> <
> https://lists.apache.org/thread.html/8dad26e9a485180a3dd36f2b54de24395b626a57b5e847bc99dda0e9@%3Cdev.mxnet.apache.org%3E
> >*
>
> The source tarball, including signatures, digests etc. can be found at:
>
> *https://dist.apache.org/repos/dist/dev/incubator/mxnet/1.3.0.rc0/
> *
>
> The release tag can be found here:
>
> *https://github.com/apache/incubator-mxnet/releases/tag/1.3.0.rc0
> *
>
> The release hash is b3be92f4a48bce62a5a8424271871c2f81c8f7f1 and can be
> found here:
>
> *
> https://github.com/apache/incubator-mxnet/commit/b3be92f4a48bce62a5a8424271871c2f81c8f7f1
> <
> https://github.com/apache/incubator-mxnet/commit/b3be92f4a48bce62a5a8424271871c2f81c8f7f1
> >*
>
> Release artifacts are signed with the following key:
>
> CB91 64C7 6A80 3D86 1DE1  6E5B 9105 2D92 2E28 A38F
>
>
> KEYS file available:
>
> https://dist.apache.org/repos/dist/dev/incubator/mxnet/KEYS
>
> The vote will end on Tuesday, September 11th, 11:30am PDT or until the
> necessary number of votes is reached.
>
> [ ] +1 Release this package as 1.3.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because ...
>
> Thanks,
> Roshani
>

Re: No more incubator report timeline emails?

[Justin Mclean]

Hi,

Yep sorry my fault, I can see that they should be run manually the last 
Wednesday of the month.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Default project guidelines

[Justin Mclean]

Hi,

There been some discussion on bylaws/guidelines recently and it was suggest 
that the IPMC document a default set for projects to use. So I’ve come up with 
a default set of guidelines [1]  using links to existing content when I could 
find it. I tried to make it as minimal as possible. Feedback and edits welcome. 

Most of the project guidelines and bylaws include 2/3 Majority or even 2/3 lazy 
major for removal of PMC members or committers, but given that these terms are 
not defined in the Glossary I just went with consensus approval, there are 
(very) rare events and only the board can remove a PMC member.

There is a lot of confusion if the approval should be censuses or majority for 
adding or removing people in the various projects guidelines/bylaws. Consensus 
seem more common so I went with that - that may be wrong.

One other surprising thing is that most allow committers to veto code changes, 
strictly speaking I think it’s only PMC members who can do that  but I can’t 
see that causing an issue as good reasons are required for a valid veto.

Thanks,
Justin

1. https://wiki.apache.org/incubator/DefaultProjectGuidelines
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE]- Release Apache Weex (Incubating) 0.19.0 [RC4]

[Willem Jiang]

Hi Hanks，

I  just checked the release vote mail, it's just for rc3 not for the rc4.
Can you update the link for voted mail?


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Fri, Sep 7, 2018 at 5:51 PM Hanks Zhang  wrote:
>
> Dear IPMC members,
>
> This is a call for the vote to release Apache Weex (Incubating) version
> 0.19.0.
>
> The Apache Weex community has voted on and approved a proposal to release
> Apache Weex (Incubating) version 0.19.0.
>
> We now kindly request the Incubator PMC members to review and vote on this
> incubator release.
>
> Apache Weex (incubating) is a framework for building Mobile cross-platform
> UIs.
>
> Vote thread:
>
> https://lists.apache.org/thread.html/40d49fa7338680253be47382c26150a1730992611a26267648f2@%3Cdev.weex.apache.org%3E
>
> Vote result thread:
>
> https://lists.apache.org/thread.html/47988b39c4748f01efac6010b9c239a094fb332e5cea51e6b0460c0b@%3Cdev.weex.apache.org%3E
>
> The tag to be voted upon:
>
> https://github.com/apache/incubator-weex/commits/0.19.0-rc4
>
> The source code artifacts can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.19.0/RC4/apache-weex-incubating-0.19.0-RC4-src.tar.gz
>
> The SHA-512 checksum for apache-weex-incubating-0.19.0-RC4-src.tar.gz:
>
> E41BB93D 26BCAB55 F39BF11B 91649221 92A56671 9D076C1A 60182569 E3F29D05
> 026F73CC
>  D09B4F31 2E3012AD A3B00599 B647CD36 E7E0DD8A 19A9D0B3 362C9FFD
>
> The signature of this artifact can be found at:
>
> https://dist.apache.org/repos/dist/dev/incubator/weex/0.19.0/RC4/apache-weex-incubating-0.19.0-RC4-src.tar.gz.asc
>
> The artifacts have been signed with Key: 4FD8BC09C7E9DB81, which can be
>
> found in the keys file:
>
> https://dist.apache.org/repos/dist/release/incubator/weex/KEYS
>
> The compile documentation can be found at:
>
> https://github.com/apache/incubator-weex/blob/0.19.0-rc4/HOW-TO-BUILD.md
>
> Weex is a project that contains iOS, Android and Web code. So it may be a
>
> little complicated to prepare the compiling environment.
>
> Release note about this version:
>
> https://issues.apache.org/jira/projects/WEEX/issues/WEEX-464
>
> The vote will be open for at least 72 hours or until a necessary number of
>
> votes are reached.
>
> Please vote accordingly:
>
> [ ] +1 approve
>
> [ ] +0 no opinion
>
> [ ] -1 disapprove with the reason

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New podlings reporting schedule is monthly for 3 months

[Justin Mclean]

HI,

> I'm a bit curious about why this was sent, so I'll bite.

Because a new podling didn’t report monthly for the first 3 months as they are 
required to.

> I'm a mentor on a brand new podling.  The report template should have been
> generated on 8/29, the day before this podling was accepted into the
> incubator.  Yet for some reason, they had a report due.

The reporting schedule can be modified (if needed) in the podlings.xml file.

Thanks,
Justin


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New podlings reporting schedule is monthly for 3 months

[Luciano Resende]

I am probably on a similar situation with a new podling that I delayed the
setup a bit due to conferences. We will start reporting next month.

On Sun, Sep 9, 2018 at 8:20 PM John D. Ament  wrote:

> I'm a bit curious about why this was sent, so I'll bite.
>
> I'm a mentor on a brand new podling.  The report template should have been
> generated on 8/29, the day before this podling was accepted into the
> incubator.  Yet for some reason, they had a report due.  I'm not actually
> sure why this was the case.  Did we incorrectly add them?It looks like Mick
> added them without any prompting, but I'm not sure if there was any off
> list discussion about it.
>
> I would think if the report is generated on time (which September was)
> podlings added to the incubator would optionally report that month,
> otherwise, the next month.  In this specific podling's case, this would
> have meant their reporting group would be group 1 not group 3.
>
> John
>
> On Fri, Sep 7, 2018 at 8:38 PM Justin Mclean 
> wrote:
>
> > Hi,
> >
> > Just a reminder that new podling need to report monthly for the first 3
> > reports, then quarterly after that. [1]
> >
> > Thanks,
> > Justin
> >
> > 1. https://incubator.apache.org/guides/ppmc.html
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>


-- 
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: No more incubator report timeline emails?

[Justin Mclean]

HI,

> I've noticed in the past few months, the incubator report timeline emails
> have stopped. 

I’m not sure they were automated.

I’ve posted the draft for this month  here which includes the dates due, but in 
future I include the dates in the email to this list so people know without 
looking at the wiki.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator release checklist

[???? Sheng Wu]

Hi Justin


Good checklist, like it. 


--
Sheng Wu
Apache SkyWalking 


 




-- Original --
From:  "justin";
Date:  Mon, Sep 10, 2018 08:31 AM
To:  "general";

Subject:  Incubator release checklist



HI,

As part of the workshop I ran recently I had people look at a real release and 
go though a checklist before voting on it, it my be of some help other people 
checking releases. I??ve just added a version of it to the incubator wiki. [1] 
Feedback welcome.

Thanks,
Justin

1. https://wiki.apache.org/incubator/IncubatorReleaseChecklist#preview
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New podlings reporting schedule is monthly for 3 months

[John D. Ament]

I'm a bit curious about why this was sent, so I'll bite.

I'm a mentor on a brand new podling.  The report template should have been
generated on 8/29, the day before this podling was accepted into the
incubator.  Yet for some reason, they had a report due.  I'm not actually
sure why this was the case.  Did we incorrectly add them?It looks like Mick
added them without any prompting, but I'm not sure if there was any off
list discussion about it.

I would think if the report is generated on time (which September was)
podlings added to the incubator would optionally report that month,
otherwise, the next month.  In this specific podling's case, this would
have meant their reporting group would be group 1 not group 3.

John

On Fri, Sep 7, 2018 at 8:38 PM Justin Mclean 
wrote:

> Hi,
>
> Just a reminder that new podling need to report monthly for the first 3
> reports, then quarterly after that. [1]
>
> Thanks,
> Justin
>
> 1. https://incubator.apache.org/guides/ppmc.html
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

No more incubator report timeline emails?

[John D. Ament]

Hi,

I've noticed in the past few months, the incubator report timeline emails
have stopped.  I had previously used this as a reminder as a mentor to
ensure my podlings were reporting (since in all honesty, I'm not subscribed
to all the dev lists).

Is there a reason this was dropped? I see that sending it is still a part
of the report runbook.

Thanks,

John

Re: Incubator release checklist

[Justin Mclean]

Hi,

> Great, some of these are accomplished by one line commands, maybe would be
> good to add those into the checklist as well.

Mostly, but It's going to vary from project to project depending on on the 
build process and technology and a lot of it is manual observation.  We could 
possibly come up with a list for Java projects which may be helpful.

I do use some tools / simple scripts to help me and speed up the process but 
they only mostly save me a little typing.

For instance:

function rat() {
  java -Xms1024m -Xmx1024m -jar ~/Downloads/apache-rat-0.11/apache-rat-0.11.jar 
$1
}

function search() {
  find . -type f -exec grep -i "$1" {} \; -print
}

function verify() {
 for file in *.asc; do gpg --verify $file; done
}

function sha512() {
 for arg in $*; do shasum -a 512 $arg; done
}

function untxt() {
 find . -name '*.txt' | while read f; do mv "$f" "${f/\.txt/}"; done
}

And I usually do stuff like this on a release:
grep “ B  “ rat.txt | grep -v “\.png” | grep -v ...
search copyright | sort -u > copy.txt 
search GPL 
search BSD

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator release checklist

[Luciano Resende]

On Sun, Sep 9, 2018 at 5:31 PM Justin Mclean 
wrote:

> HI,
>
> As part of the workshop I ran recently I had people look at a real release
> and go though a checklist before voting on it, it my be of some help other
> people checking releases. I’ve just added a version of it to the incubator
> wiki. [1] Feedback welcome.
>
> Thanks,
> Justin
>
> 1. https://wiki.apache.org/incubator/IncubatorReleaseChecklist#preview
> -
>

Great, some of these are accomplished by one line commands, maybe would be
good to add those into the checklist as well.

-- 
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: Incubator Workshop

[Willem Jiang]

Yeah, I'm totally agree with that.
>From my experience, I really learn a lot by checking the mail thread
discussion and verifying the kit myself with the help of checklist.
Maybe we can encourage the people to participate the vote in the
general@incubator to get the field experience.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Sep 10, 2018 at 8:49 AM Justin Mclean  wrote:
>
> Hi,
>
> > I think an online version would be really helpful.
> > As for the self-paced version, I think just making the recording available
> > later should be enough.
>
> The reason I suggested a self paced one it that includes a number of 
> activities, checking a real release, voting on committers and teh like. I 
> think that some people will get more out of it if they are active participant 
> rather than just watching a video of me talking and my slides.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Workshop

[Justin Mclean]

Hi,

> I think an online version would be really helpful.
> As for the self-paced version, I think just making the recording available
> later should be enough.

The reason I suggested a self paced one it that includes a number of 
activities, checking a real release, voting on committers and teh like. I think 
that some people will get more out of it if they are active participant rather 
than just watching a video of me talking and my slides.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator Workshop

[Yaniv Rodenski]

Hi Justin,

I think an online version would be really helpful.
As for the self-paced version, I think just making the recording available
later should be enough.

Cheers,
Yaniv

On Mon, 10 Sep 2018 at 10:30 am, Justin Mclean 
wrote:

> Hi,
>
> A few month back I ran an incubator workshop at FOSS backstage that
> covered making and voting on releases and voting on committers into the
> projects. It had several exercises
>
> Would anyone be interested in either a:
> 1) Online self-paced version
> 2) Online live version (i.e. me going through it) with Q+A at the end.
> This could be recorded and put up for other to watch after it’s taken place.
>
> Now I’m probably talking to the wrong audience here, and this email might
> be better if it was sent out to podlings dev lists, and in particular ones
> new to the incubator? If the mentors of  those prolongs think it would be
> of interest please forward this email.
>
> The workshop didn’t cover entry into graduation, naming, IP clearance,
> trademarks, branding or graduation process. Which I’d like to expand on and
> it would be great to have some help on producing content for that.
>
> Thanks,
> Justin

-- 
Yaniv Rodenski

+61 477 778 405
ya...@shinto.io

Incubator release checklist

[Justin Mclean]

HI,

As part of the workshop I ran recently I had people look at a real release and 
go though a checklist before voting on it, it my be of some help other people 
checking releases. I’ve just added a version of it to the incubator wiki. [1] 
Feedback welcome.

Thanks,
Justin

1. https://wiki.apache.org/incubator/IncubatorReleaseChecklist#preview
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Incubator Workshop

[Justin Mclean]

Hi,

A few month back I ran an incubator workshop at FOSS backstage that covered 
making and voting on releases and voting on committers into the projects. It 
had several exercises

Would anyone be interested in either a:
1) Online self-paced version
2) Online live version (i.e. me going through it) with Q+A at the end. This 
could be recorded and put up for other to watch after it’s taken place.

Now I’m probably talking to the wrong audience here, and this email might be 
better if it was sent out to podlings dev lists, and in particular ones new to 
the incubator? If the mentors of  those prolongs think it would be of interest 
please forward this email.

The workshop didn’t cover entry into graduation, naming, IP clearance, 
trademarks, branding or graduation process. Which I’d like to expand on and it 
would be great to have some help on producing content for that.

Thanks,
Justin

Re: [VOTE] Release Apache SkyWalking (incubating) version 5.0.0-RC2

[Ignasi Barrera]

That's why I meant when I said finding the build instructions was
trivial enough that I thought it should not block a release.

The README contains a clear link to the Documentation (which is a link
to a local file), and that file is a very comprehensive index with
direct links to architecture, testing, building, etc. Even if the
compiling link is broken it is so trivial to find the build
instructions that I find the comment "unable to build from source" a
bit strict.

I mean, people used to build from source often have a file describing
the typical "./configure && make && make install", and often have to
spend some time reading through the different configure options to
properly configure the software for their platform. It is OK and
usually assumed that building from source will get some time, and I
find this concrete case to be very trivial. It is just an inconvenient
broken link, that has a proper replacement that is trivial to find.


This said, (and I'm asking for some advice here as it's the first
project I help mentoring) I think we should not block the release for
this reason and I'd vote +1, but I don't know if the IPMC vote is more
targetted to non-mentors, which could have a potentially different
perspective of the project just by overseeing it from the distance.


On Sun, 9 Sep 2018 at 10:47, Justin Mclean  wrote:
>
> Hi,
>
> > Justin, given that the next release will provide this information so 
> > clearly from the base directory, knowing that the next release will be in 
> > order, are you ok with letting this release pass through?
>
> That is not up to me, that is up for other IPMC members to vote +1 on it.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Email to be sent to inactive mentors

[Adina Crainiceanu]

Justin,

Can you please remove Josh Elser from the list of inactive mentors for Rya?
He only missed the last report and he is always available when we have
questions.

Thank you,
Adina


On Sat, Sep 8, 2018 at 8:52 PM, Justin Mclean 
wrote:

> Hi,
>
> There been several discussions over several month on what to do about
> missing mentors. In some case have a missing mentors is not an issue and
> there’s other mentors that can help, whoever currently we have a number of
> podling with only one or two active mentors and the board has concerns
> about the rate of report sign off and missing podling reports. (Both of
> which could be a sign of inactive mentors).
>
> Here the draft email I’m going to send out late next week (baring any
> objections) to all inactive mentors (as listed in this document [2] with no
> activity for a podling). Feedback on the text below welcome.
>
> Given there will be 60 or so emails sent out, how do we want to handle
> this and the replies? It’s going to generate a lot of noise on the list. I
> could make it more generic and contain it to one thread but then we are
> likely to get mentors asking what podlings we are asking abut or mentors
> that are active in other podlings objecting thinking that they are active.
> Also should the replies go to general@ or private@, given people may have
> personal reasons for not being active and may not want to share that in a
> public list.
>
> It may be better to send off list (from my apache.org email address) and
> bring back a summary here to reduce the amount of on-list noise.
>
> If we don’t get a reply within a week I would suggest removing them as
> mentors and ask the podling to start looking for another mentor if needed.
> They can ask to be added back  as a mentor at any future point by asking
> their PPMC or asking here.
>
> The email to be sent:
>
> ———
> Hi ,
>
> I can see you are are the mentor of  and haven’t been signing
> off reports on a frequent basis or active on the mailing list in the last 6
> months. We’re grateful that you stood up as a volunteer to mentor this
> project, but things change and you may no longer be in the position to be
> able to mentor this podling.
>
> Could you respond to this email and indicate if you wish to continue as a
> mentor or step down.
>
> Here’s a reminder of what mentors are expected to do. [1]
>
> Thanks,
> Justin Mclean (V.P. Incubator)
>
> 1. https://incubator.apache.org/policy/roles_and_
> responsibilities.html#mentor
>
> ———
>
> Thanks,
> Justin
>
> 2. https://docs.google.com/spreadsheets/d/1oR2kymzDTLOy-
> P-QLYM1wlHFES6LG9X-V2SMgwohvR4/edit?usp=sharing
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Email to be sent to inactive mentors

[Justin Mclean]

Hi,

> I honestly don't have the time to mentor them in an official capacity - if 
> I'm listed as anything but champion, then yes, remove me as a mentor. I'll 
> continue in a low-capacity to provide help when I can, but I have other 
> priorities first and foremost :)

Done and sorted.

Thanks,
Justin

Re: Email to be sent to inactive mentors

[Daniel Gruno]

On 09/09/2018 11:33 AM, Justin Mclean wrote:

HI,


There seems to be a bit of confusion here. I am not a mentor for Annotator, yet 
I am listed as one.


You listed as one here. [1]

It get it’s info (I believe) from the podling.xml files which has this in it 
for Annotator:
 
 Nick Kew
 Brian McCallister
 Daniel Gruno
 Jim Jagielski
 

Is that information perhaps out of date or incorrect? You are also listed as 
the champion.
Daniel Gruno


I did champion it (and offer advice/help on occasion), but AIUI the champion's 
duties officially stop once the project has entered incubation and gotten set 
up.


They can be the case, but some champions also continue on as mentors.

I take it from that that you would like to be removed as a mentor and not sent 
the email?


I honestly don't have the time to mentor them in an official capacity - 
if I'm listed as anything but champion, then yes, remove me as a mentor. 
I'll continue in a low-capacity to provide help when I can, but I have 
other priorities first and foremost :)




Thanks,
Justin

1. https://whimsy.apache.org/roster/ppmc/annotator


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Email to be sent to inactive mentors

[Justin Mclean]

HI,

> There seems to be a bit of confusion here. I am not a mentor for Annotator, 
> yet I am listed as one.

You listed as one here. [1]

It get it’s info (I believe) from the podling.xml files which has this in it 
for Annotator:

Nick Kew
Brian McCallister
Daniel Gruno
Jim Jagielski


Is that information perhaps out of date or incorrect? You are also listed as 
the champion.
Daniel Gruno

> I did champion it (and offer advice/help on occasion), but AIUI the 
> champion's duties officially stop once the project has entered incubation and 
> gotten set up.

They can be the case, but some champions also continue on as mentors.

I take it from that that you would like to be removed as a mentor and not sent 
the email?

Thanks,
Justin

1. https://whimsy.apache.org/roster/ppmc/annotator


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Email to be sent to inactive mentors

[Daniel Gruno]

There seems to be a bit of confusion here. I am not a mentor for 
Annotator, yet I am listed as one. I did champion it (and offer 
advice/help on occasion), but AIUI the champion's duties officially stop 
once the project has entered incubation and gotten set up. If this is 
not the case, then our policies should be updated to reflect this, as it 
seems wrong to assume duties we did not explicitly ask people to take on.


With regards,
Daniel.

On 09/09/2018 11:14 AM, Justin Mclean wrote:

Hi,


Perhaps add some recognition in the text of the email that there may
be activity that we are unaware of? (Unlikely, but it seems rude to
presume.)


I guess it’s possible you can mentor by just watching and only directing were 
needed, so if everything going well there may be no need for any interaction. 
People can use different email address or names online and could of been missed 
when I searched the email lists. So yes if possible one or two people may be 
incorrectly sent this email.

I’ll add:

Of course it may be that we've got it wrong for one reason or another and you 
are actually active, if that’s the case apologies in advance, and we’re happy 
for you to continue as a mentor of your podling(s).


I strongly support your efforts to hold mentors accountable. Thanks
for doing it, Justin!


Thanks. I think it’s got to the point were some action needs to be taken, 
rather than keep discussing it :-)

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Email to be sent to inactive mentors

[Justin Mclean]

Hi,

> Perhaps add some recognition in the text of the email that there may
> be activity that we are unaware of? (Unlikely, but it seems rude to
> presume.)

I guess it’s possible you can mentor by just watching and only directing were 
needed, so if everything going well there may be no need for any interaction. 
People can use different email address or names online and could of been missed 
when I searched the email lists. So yes if possible one or two people may be 
incorrectly sent this email.

I’ll add:

Of course it may be that we've got it wrong for one reason or another and you 
are actually active, if that’s the case apologies in advance, and we’re happy 
for you to continue as a mentor of your podling(s).

> I strongly support your efforts to hold mentors accountable. Thanks
> for doing it, Justin!

Thanks. I think it’s got to the point were some action needs to be taken, 
rather than keep discussing it :-)

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache SkyWalking (incubating) version 5.0.0-RC2

[Justin Mclean]

Hi,

> Justin, given that the next release will provide this information so clearly 
> from the base directory, knowing that the next release will be in order, are 
> you ok with letting this release pass through?

That is not up to me, that is up for other IPMC members to vote +1 on it.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Dubbo (Incubating) 2.6.3 [RC5]

[Willem Jiang]

Sorry, I just got some time back to this thread.
I just went through the dev discussion of the dubbo and found out
dubbo community are planning the next release cut by discussion the
bug fix list first.  I'm sure we could do it better in the next
release.

Here are my +1 for this vote.
I can build the code from source.
The artifacts were signed with right key.

For the UT test error, is only related to system property setting
which will not effect the end user.
Just a quick note for binary release,  it only includes the dubbo
jars. It could be more convenience for the end user if we can include
the third party dependencies jars in the binary release.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Sep 7, 2018 at 9:57 AM Jun Liu  wrote:
>
> > I just checked the commit, it relates to system property setting, the
> > fix is quite simple.
> > I also checked the CI build, it looks like the CI is green[1]
> >
> > But my question is this fix was merged into 2.6.x branch for three
> > weeks ago,  why didn't we do the cherry pick it into 2.6.3 release
> > branch last week?
> > In Apache projects we maintain 2~3 different branches at the same
> > time, cherry pick the fix acrocess different branches is a common
> > practice.
>
> Thanks for the constructive advice and I agree that check and synchronizing 
> between different branches are one important aspect we should pay more 
> attention to. I will bring this discussion to the dev community to attract 
> more committer’s and contributor’s attention later.
>
> For this specific issue, since it’s a known UT bug, I tend to fix it in the 
> next release and continue with this RC vote.
>
> Saying about UT, I’d like to discuss a little bit more about it here: 
> currently, we have some UTs (3-4 as I know) that are not stable enough 
> themselves, which means they cannot verify features as expected or they may 
> sometimes mis-warn us with failures limited to their own bad logic, and even 
> worse over time, we may be less alert to UT failures. I would suggest we fix 
> these unstable UTs as soon as possible, or at least, if they are not on the 
> schedule now, we should list all these unstable UTs and the possible failures 
> and reasons for failure to reduce the confusion of developers and verifiers.
>
> > I know Dubbo team takes almost 1 month to cut this round release,  but
> > it's like a pain of growing. ServiceComb took more than a month to cut
> > the first around release. We can do the release better if we learn
> > something from it.  Please revisit your release guide and checklist
> > again, and encourage community to vote -1 once he find something
> > wrong.
>
> The first release was relatively smooth. But in this release, with all the 
> problems encountered, we have learned that there’re still some things lacking 
> in the community to guarantee regular Apache releases with high quality and 
> efficiency. The Dubbo community has worked on with the following aspects to 
> improve that:
> * How to prepare an Apache release [1].
> * The checklist for release candidate [1].
> * Release script to automate the release process [2].
>
> [1]. http://dubbo.apache.org/en-us/blog/prepare-an-apache-release.html
> [2]. https://github.com/apache/incubator-dubbo/blob/2.6.x/release.sh
>
> Best regards,
> Jun
>
> > On 6 Sep 2018, at 06:37, Willem Jiang  wrote:
> >
> > I just checked the commit, it relates to system property setting, the
> > fix is quite simple.
> > I also checked the CI build, it looks like the CI is green[1]
> >
> > But my question is this fix was merged into 2.6.x branch for three
> > weeks ago,  why didn't we do the cherry pick it into 2.6.3 release
> > branch last week?
> > In Apache projects we maintain 2~3 different branches at the same
> > time, cherry pick the fix acrocess different branches is a common
> > practice.
> > As someone already observered the test failure in earlier RC, we need
> > to put some efforts on it (issue tracking) to make sure we fix it in
> > the next RC.
> >
> > I know Dubbo team takes almost 1 month to cut this round release,  but
> > it's like a pain of growing. ServiceComb took more than a month to cut
> > the first around release. We can do the release better if we learn
> > something from it.  Please revisit your release guide and checklist
> > again, and encourage community to vote -1 once he find something
> > wrong.
> >
> > [1]https://travis-ci.org/apache/incubator-dubbo/builds/420912788
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> > On Wed, Sep 5, 2018 at 6:39 PM Jerrick Zhu  wrote:
> >>
> >> On Wed, Sep 5, 2018 at 6:10 PM Mark Thomas  wrote:
> >>
> >>> On 03/09/18 03:32, Jun Liu wrote:
> >>>
> >>> 
> >>>
>  Please vote accordingly:
>  [X] +1 approve
>  [ ] +0 no opinion
>  [ ] -1 disapprove with the reason
> >>>
> >>> Notes:
> >>> ==
> >>>
> >>> Hash and signature match.
> >>>
> >>> Source zip matches Git tag (apart from expected differences of
> >>> 

Re: [VOTE] Release Apache SkyWalking (incubating) version 5.0.0-RC2

[Mick Semb Wever]

> First of all, there is a direct link to that build page, in README of 
> master and 5.x branches. See 
> https://github.com/apache/incubator-skywalking#compiling-project
> We have both links to document and compiling guide.


This is excellent in my opinion.
>From the terminal I can read the README.md which clearly states:

> # Compiling project
> Follow this [document](docs/en/guides/How-to-build.md).

Then opening, again from the terminal, `docs/en/guides/How-to-build.md` gives 
me everything i need to know.

Justin, given that the next release will provide this information so clearly 
from the base directory, knowing that the next release will be in order, are 
you ok with letting this release pass through?

regards,
Mick

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org