[GitHub] [incubator] justinmclean opened a new pull request #26: reorganise menus
justinmclean opened a new pull request #26: reorganise menus URL: https://github.com/apache/incubator/pull/26 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[GitHub] [incubator] justinmclean merged pull request #26: reorganise menus
justinmclean merged pull request #26: reorganise menus URL: https://github.com/apache/incubator/pull/26 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
option (D) combined with (E) And encourage mentors to vote on dev@ makes sense to me On Fri, Aug 9, 2019 at 3:24 PM Justin Mclean wrote: > Hi, > > > (D) will still require 2 more IPMC vote? > > (E) will be like (B) in that it will need mentors or other IPMC to vote > in > > podling dev@? > > All releases require 3 (or more) +1 votes by a PMC so yes they would > require 3 IPMC votes. > > 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 Druid (incubating) 0.15.1 [RC2]
Hi, +1 (binding) I checked: - incubating in name - signatures and hashes fine - LICENSE is fine - NOTICE may need a little work - No unexpected binary files - Source files have ASF headers - Can compile from source NOTICE mentions using code From Apache Hive, Apache Lucerne, Apache Hadoop and Apache Calcite. Only Calcite is mentioned in your NOTICE file and all of those projects have NOTICE files, Jets3t contains a NOTICE file [3] so I think more needs to go in your NOTICE file. I am sort of curious how this is licensed [1] and if that should go in LICENSE? (which I don’t think is an issue) and if you had permission from the people to use and distribute the content in [2] Thanks, Justin 1. core/src/test/resources/loremipsum.txt 2. apache-druid-0.15.1-incubating-src/examples/quickstart/tutorial/wikiticker-2015-09-12-sampled.json.gz 3. https://bitbucket.org/jmurty/jets3t/src/default/NOTICE.txt - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] IPMC votes on releases
Hi, > (D) will still require 2 more IPMC vote? > (E) will be like (B) in that it will need mentors or other IPMC to vote in > podling dev@? All releases require 3 (or more) +1 votes by a PMC so yes they would require 3 IPMC votes. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Mentor signoff on podling reports (due August 13)
Links for those who missed the memo (like me) The current report: https://cwiki.apache.org/confluence/display/INCUBATOR/August2019 The next report: https://cwiki.apache.org/confluence/display/INCUBATOR/September2019 On Thu, Aug 8, 2019 at 4:44 PM Justin Mclean wrote: > HI, > > Of the podlings that have reported these are currently missing any mentor > signoff: > Doris > ECharts > Edgent > Milagro > PageSpeed > Livy > > This is due August 13, so you still have a few days to do this. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [DISCUSS] IPMC votes on releases
(D) will still require 2 more IPMC vote? (E) will be like (B) in that it will need mentors or other IPMC to vote in podling dev@? On Thu, Aug 8, 2019 at 10:04 PM Justin Mclean wrote: > Hi, > > One of the incubator pain points is the double voting on releases first by > the podling and then by the IPMC. > > Historically there been a lot of discussion about this and a couple of > proposals to try and change it, but none have been accepted. There have > been proposals on alternative ways to vote and to ask for guidances which > have been accepted, but podlings don’t seem to take these options up. I’m > hoping the recent DISCLAIMER-WIP is one that is used more by podlings, and > go some way to helping podling get releases out, but time will tell. > > When consider what to do about this, please keep this in mind: > 1. Only PMC members can have binding votes on releases (it’s in our > bylaws) so a minimum of 3 IPMC votes are require to make a release. > 2. Podlings are not TLP and don’t have a PMC and PPMC members votes are > not binding on releases. > 3. The IPMC picks up some serious issues in (about 1 in 5) releases by > checking this way. This is mostly, but not always, on the early releases. > > So option (A) would be to get the Bylaws changed and treat podlings as > TLPs. > > Another option (B) is to get all mentors to vote on every release. We’ve > tried this via various means and it seems only a couple of podlings can > manage this. > > One (perhaps not carefully considered) option (C) would be to vote in all > PPMC members as IPMC and make PPMC members IPMC members when projects are > first created rather than incubator committers. If we did this we could > optionally gate graduation on a review of a podlings releases but that may > be unpopular. There have also been complaints in the past that he IPMC is > too large, so increasing the IPMC size this way may also not be popular. > > A variation on (C) let call it option (D) would be to vote in podling > release mangers into the IPMC after they have done a number of releases > along with podling committers that provide good feedback on a number of > release candidates. That way when starting out a podling is likely to need > the IPMC help, but one they have a few releases under their belts they will > have enough IPMC votes without having to reply on mentors or other IPMC > members. It would also encourage more careful voting on releases, If you > just go +1 with giving some detail you’re not going to be voted into the > IPMC. This wouldn't require any bylaws or policy change, we could just go > ahead and do it. It would require the mentors help in identifying good > candidates. > > One further idea I have is (E) is that if a podling does have 3 IPMC votes > on it dev list and are using the DISCLAIMER-WIP disclaimer, they can just > notify the IPMC that they are making a release, the IPMC can review it and > and any issues or feedback found can incorporated into the next release or > before graduation as per [1]. This may mean that there’s a risk that a > release has to be taken down and redone - (see issues that are blockers in > that ticket), but most issues found over the notification it would be > business as usual. > > So IMO options (A) and (C) above seem unlikely to happen, and (B) isn’t > really working, but option (D) combined with (E) along with the recent > DISCLAIMER-WIP I think could would improve the situation. > > Does anyone have any other ideas they care to share? > > Thanks, > Justin > > 1. https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-469 > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
