[GitHub] [incubator] justinmclean opened a new pull request #28: fix link
justinmclean opened a new pull request #28: fix link URL: https://github.com/apache/incubator/pull/28 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 #28: fix link
justinmclean merged pull request #28: fix link URL: https://github.com/apache/incubator/pull/28 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
Hi, > But, assuming that each podling has three active mentors, each podling should > have 3 +1 IPMC vote before the RC goes to general@ and then is, as Sebb says > below basically a "lazy" consensus vote as 3 +1 are present and if no one > throws in a -1 it will pass regularly and is a regular release. Sadly only about 10% of votes come to the incubator with 3 +1 IPMC votes, even on projects with three or more active mentors not all vote for a number of reasons. > So from my perspective we should really work on the Mentor activity then the > "voting" problem becomes minor. It's certainly an issue, it improved a lot of the last few years but mentors could still be more involved in some projects. > Also I think our current practice of just saying "Interesting project, count > me in as Mentor" is not good as this leads exactly to the situation I > described above. It can do yes. > So I would suggest to make the Mentor assignment somewhat binding, e.g. by > IPMC Vote or some other process and to force in the "activity" of mentors. > I have no detailed idea how this should be done but if Mentors regularily do > not vote on Podling releases and do not signoff podling reports this is a > sign that perhaps another mentor has to step in. Reports signing off is tracked. I use to keep track on inactive mentors, there's a strong correlation between not been active and not signing off 3 reports in a row, Also if mentors are missing podlings can put that in their report (there’s a question on that) and ask for more mentors. Thanks, Justin - 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 #27: Add some links to some other Apache Way / incubator talks
justinmclean merged pull request #27: Add some links to some other Apache Way / incubator talks URL: https://github.com/apache/incubator/pull/27 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 opened a new pull request #27: Add some links to some other Apache Way / incubator talks
justinmclean opened a new pull request #27: Add some links to some other Apache Way / incubator talks URL: https://github.com/apache/incubator/pull/27 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
Hi, > Option (F): stop calling them official ASF releases, which means PMC votes > are not required. In that case voting would not be required and they wouldn’t have to follow ASF policy. If they are not official releases then we probably can’t release or distribute them on ASF infrastructure. We do allow connivance binaries but they still have to follow ASF policy and have to be made from the source of an official release. In this scenario how do podlings learn what is required to make official releases? Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Incubation Proposal of MesaTEE
On Sat, Aug 10, 2019 at 2:13 AM Mingshen Sun wrote: > > > > == Continuous Integration Service == > > > > > > MesaTEE currently uses self-hosted continuous integration (CI) service > > > which can > > > help developers to automatically test commits. The CI service involves > > > several > > > nodes which support Intel SGX. We would like to continue doing so. > > > > This may not be possible, what would the project do if that was the case? > > Have you discussed this with your proposed mentors or infra? > > About the CI infrastructure, actually, the "self-hosted CI" is not our > internal infra, we are using a open source CI service (Drone CI) with > our servers/NUC with SGX supported. To answer your questions, we have > several solutions: > - we can use simulation mode for basic CI testing (by using existing > infra in Apache for example). And before merging a pull request, full > testing on a SGX supported machine is required > - donating our SGX machines for CI services to Apache is another > option we may consider, but this should be further discussed > I don't see the hosting of CI on an external service or hardware as a big issue, we have a lot of projects that are currently using Travis CI, and others, like Spark, running their CI on a bunch of machines hosted at Berkley. Having said that, I believe the results of the CI (e.g. log, etc) should be visible to all which is what happens with Travis CI and the spark ci today. Having said that, all the possible next steps mentioned above are also possible, but IMHO not a requirement. -- Luciano Resende http://twitter.com/lresende1975 http://lresende.blogspot.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Incubation Proposal of MesaTEE
I’d most likely be interested in mentoring this project, but I’m not that experienced in incubator mentorship. If we have another more experienced mentor to work with us, I’d be happy to mentor as well. On Sat, Aug 10, 2019 at 04:13, Mingshen Sun wrote: > Thanks Justin, regarding to your questions: > > On Thu, Aug 8, 2019 at 2:46 AM Justin Mclean > wrote: > > > > Hi, > > > > Thanks for the proposal, it sound like a really interesting project. > > > > > == Core Developers == > > > > > > Current core developers work at Baidu. We are confident that > incubation will > > > help us grow a diverse community in an open and collaborative way. > > > > > > The risk of abandonment of MesaTEE is low. MesaTEE has been incubated > at Baidu > > > for over two years. Baidu is committed to the further development of > the project > > > and will keep investing resources towards the Apache processes and > community > > > building, during the incubation period. > > > > Incubation can sometimes take 2 years or more. Given few people with > experience at Apache are involved with this project and the core developers > are from one company, it may take longer that indicated in this proposal. > > We understand the incubation could take 2 years or more. Recently, we > have already received some pull requests from third-parties. > Therefore, during the incubation period, we will try to > attract/involved engineers from other companies as constant > committers. > > > > > > == Continuous Integration Service == > > > > > > MesaTEE currently uses self-hosted continuous integration (CI) service > which can > > > help developers to automatically test commits. The CI service involves > several > > > nodes which support Intel SGX. We would like to continue doing so. > > > > This may not be possible, what would the project do if that was the > case? Have you discussed this with your proposed mentors or infra? > > About the CI infrastructure, actually, the "self-hosted CI" is not our > internal infra, we are using a open source CI service (Drone CI) with > our servers/NUC with SGX supported. To answer your questions, we have > several solutions: > - we can use simulation mode for basic CI testing (by using existing > infra in Apache for example). And before merging a pull request, full > testing on a SGX supported machine is required > - donating our SGX machines for CI services to Apache is another > option we may consider, but this should be further discussed > > > > * Zhijie Shen > > > > Is not currently an IPMC member, only IPMC members can officially be > mentors. > > > > Of the three mentors listed 2 have never been mentors to my knowledge, > have they been involved with any other projects going through the > incubating process at Apache? The third mentor may be a little overextended > given the number of podlings they mentors. Having only one experienced > mentor may be a risk to the project. What will you do if your mentors go > missing or unable to help? > > I have talked with Zhijie Shen. He is very interested in helping us. > Currently, he is a member of incubator and can apply for IPMC. In > addition to Zhijie Shen, Jianyong Dai, and Luciano Resende, Furkan > Kamaci also volunteered to become one of our mentors after posting > this proposal in the mailing list. We understand this is a large > project and need experienced mentors. We are very open to include more > mentors who are interested in the project. > > - > Mingshen > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Matt Sicker
Re: [DISCUSS] IPMC votes on releases
Option (F): stop calling them official ASF releases, which means PMC votes are not required. On Fri, Aug 9, 2019 at 12:04 AM 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 > >
Re: [DISCUSS] IPMC votes on releases
Hi, > If the IPMC members have +1ed the vote on the dev list, won't these > votes count if the vote is continued on the general@ list? Yep they count. > Do they really have to re-affirm their votes? It’s good if they do but not a requirement, it’s best of the email contains how many IPMC votes they already have. Thanks, Justin
Re: [DISCUSS] IPMC votes on releases
Hi, > Another variation/option for those using the WIP disclaimer might be that > since the WIP disclaimer kind of says this release doesn't have "full > official" status from an ASF point of view then one way of thinking about > it is that perhaps full official IPMC endorsement is less of a requirement > so IPMC voting could be 3 days but lazy. I like the idea but this wouldn’t be in line with the current ASF bylaws. I think they would need to be changed for this to happen. > I have no problem giving +1 to (E) at all but in reality, it is almost no > effort for the 3 mentioned IPMC members on the dev list to just +1 the IPMC > vote, so are we picking up the real problem podlings? Only about 10%(?) of podlings manage to get 3 +1 votes from mentors/IPMC members on their dev lists. even podlings with 3 active mentors can’t always get 3 +1 votes, some podlings have 6 mentors and still can’t get 3 +1 votes on their releases.. 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
Hi, thanks Justin for bringing that up. I have perhaps a different perspective than many others because I was / am mostly active in several podlings and just very recently became IPMC member (no apache member). But, assuming that each podling has three active mentors, each podling should have 3 +1 IPMC vote before the RC goes to general@ and then is, as Sebb says below basically a "lazy" consensus vote as 3 +1 are present and if no one throws in a -1 it will pass regularly and is a regular release. This brings me to the point. The assumption "three active mentors" is pretty strong. In the podlings I have been active with I observed three categories of Mentors: - generally present (best!) - usually not present but active in VOTE threads or report signoff (so-so) - not active at all So from my perspective we should really work on the Mentor activity then the "voting" problem becomes minor. I have no opinion of whether ASF Members should be allowed to simply step into IPMC or not (Members should be expected to bring everything which is needed for a valuable decision making, I guess). But, I think its to "easy" to become mentor of a project. So I would rather argue that not each IPMC member should automatically become a possible Mentor. To become Mentor should be based on the experience / track record in "the apache way" as already stated by others like Sheng. Also I think our current practice of just saying "Interesting project, count me in as Mentor" is not good as this leads exactly to the situation I described above. So I would suggest to make the Mentor assignment somewhat binding, e.g. by IPMC Vote or some other process and to force in the "activity" of mentors. I have no detailed idea how this should be done but if Mentors regularily do not vote on Podling releases and do not signoff podling reports this is a sign that perhaps another mentor has to step in. If we ensure that each podling always has 3 ACTIVE mentors, than most IPMC Release Votes become LAZY votes. This should, from my perspective, be the main goal to focus on. Julian Am 10.08.19, 13:55 schrieb "sebb" : On Sat, 10 Aug 2019 at 12:45, Paul King wrote: > > Another variation/option for those using the WIP disclaimer might be that > since the WIP disclaimer kind of says this release doesn't have "full > official" status from an ASF point of view then one way of thinking about > it is that perhaps full official IPMC endorsement is less of a requirement > so IPMC voting could be 3 days but lazy. If you don't get more -1 votes > than +1 votes after 3 days, you can go ahead and publish. Outside WIP > disclaimer projects, if there are projects which are repeatedly not getting > enough IPMC votes, then IPMC membership by an experienced PPMC member could > be considered as an option, so +1 for your (D) I believe. > > I have no problem giving +1 to (E) at all but in reality, it is almost no > effort for the 3 mentioned IPMC members on the dev list to just +1 the IPMC > vote, so are we picking up the real problem podlings? If the IPMC members have +1ed the vote on the dev list, won't these votes count if the vote is continued on the general@ list? Do they really have to re-affirm their votes? I agree that the issue seems to be more about podlings with insufficient/inactive IPMC reviewers. > On Fri, Aug 9, 2019 at 3: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
Re: [DISCUSS] IPMC votes on releases
On Sat, 10 Aug 2019 at 12:45, Paul King wrote: > > Another variation/option for those using the WIP disclaimer might be that > since the WIP disclaimer kind of says this release doesn't have "full > official" status from an ASF point of view then one way of thinking about > it is that perhaps full official IPMC endorsement is less of a requirement > so IPMC voting could be 3 days but lazy. If you don't get more -1 votes > than +1 votes after 3 days, you can go ahead and publish. Outside WIP > disclaimer projects, if there are projects which are repeatedly not getting > enough IPMC votes, then IPMC membership by an experienced PPMC member could > be considered as an option, so +1 for your (D) I believe. > > I have no problem giving +1 to (E) at all but in reality, it is almost no > effort for the 3 mentioned IPMC members on the dev list to just +1 the IPMC > vote, so are we picking up the real problem podlings? If the IPMC members have +1ed the vote on the dev list, won't these votes count if the vote is continued on the general@ list? Do they really have to re-affirm their votes? I agree that the issue seems to be more about podlings with insufficient/inactive IPMC reviewers. > On Fri, Aug 9, 2019 at 3: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.apa
Re: [DISCUSS] IPMC votes on releases
Another variation/option for those using the WIP disclaimer might be that since the WIP disclaimer kind of says this release doesn't have "full official" status from an ASF point of view then one way of thinking about it is that perhaps full official IPMC endorsement is less of a requirement so IPMC voting could be 3 days but lazy. If you don't get more -1 votes than +1 votes after 3 days, you can go ahead and publish. Outside WIP disclaimer projects, if there are projects which are repeatedly not getting enough IPMC votes, then IPMC membership by an experienced PPMC member could be considered as an option, so +1 for your (D) I believe. I have no problem giving +1 to (E) at all but in reality, it is almost no effort for the 3 mentioned IPMC members on the dev list to just +1 the IPMC vote, so are we picking up the real problem podlings? On Fri, Aug 9, 2019 at 3: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 > >
Re: [DISCUSS] Incubation Proposal of MesaTEE
Thanks Justin, regarding to your questions: On Thu, Aug 8, 2019 at 2:46 AM Justin Mclean wrote: > > Hi, > > Thanks for the proposal, it sound like a really interesting project. > > > == Core Developers == > > > > Current core developers work at Baidu. We are confident that incubation will > > help us grow a diverse community in an open and collaborative way. > > > > The risk of abandonment of MesaTEE is low. MesaTEE has been incubated at > > Baidu > > for over two years. Baidu is committed to the further development of the > > project > > and will keep investing resources towards the Apache processes and community > > building, during the incubation period. > > Incubation can sometimes take 2 years or more. Given few people with > experience at Apache are involved with this project and the core developers > are from one company, it may take longer that indicated in this proposal. We understand the incubation could take 2 years or more. Recently, we have already received some pull requests from third-parties. Therefore, during the incubation period, we will try to attract/involved engineers from other companies as constant committers. > > > == Continuous Integration Service == > > > > MesaTEE currently uses self-hosted continuous integration (CI) service > > which can > > help developers to automatically test commits. The CI service involves > > several > > nodes which support Intel SGX. We would like to continue doing so. > > This may not be possible, what would the project do if that was the case? > Have you discussed this with your proposed mentors or infra? About the CI infrastructure, actually, the "self-hosted CI" is not our internal infra, we are using a open source CI service (Drone CI) with our servers/NUC with SGX supported. To answer your questions, we have several solutions: - we can use simulation mode for basic CI testing (by using existing infra in Apache for example). And before merging a pull request, full testing on a SGX supported machine is required - donating our SGX machines for CI services to Apache is another option we may consider, but this should be further discussed > > * Zhijie Shen > > Is not currently an IPMC member, only IPMC members can officially be mentors. > > Of the three mentors listed 2 have never been mentors to my knowledge, have > they been involved with any other projects going through the incubating > process at Apache? The third mentor may be a little overextended given the > number of podlings they mentors. Having only one experienced mentor may be a > risk to the project. What will you do if your mentors go missing or unable to > help? I have talked with Zhijie Shen. He is very interested in helping us. Currently, he is a member of incubator and can apply for IPMC. In addition to Zhijie Shen, Jianyong Dai, and Luciano Resende, Furkan Kamaci also volunteered to become one of our mentors after posting this proposal in the mailing list. We understand this is a large project and need experienced mentors. We are very open to include more mentors who are interested in the project. - Mingshen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
