Re: Stopping nightly releases to Pypi
Thanks for your detailed responses. Having codebuild execute the recipe that is the apache repository is the same effect and control that you would have in some service such as travis CI. And the builds are fully reproducible. So it's under full control of Apache the same way that any other hosted build solution is. Any modification to the recipe would be executed on next commit, and the builds are fully reproducible. There's no configuration in code build that would be outside of the Apache MXNet repository in this case, since pipeline and the config would be under the git repo. And as you rightly pointed out, the Jenkins master is a weak point to the restricted slaves. This was strongly criticized during the system review and there is precedent of security flaws in the master. Insisting on mixing CI and CD is not a good recommendation for what it has been explained above. Pedro. On Wed, Jan 8, 2020 at 2:41 PM Marco de Abreu wrote: > Correct, I'm not bothered by the s3 bucket but by way how it gets > published. It's not in Jenkins, so it's outside of the projects control. > > The security design due to the restricted nodes makes sure that no third > party can gain access to these machines. They use separate caches, separate > volumes, different instance profiles etc - I personally would consider the > restricted slaves safe. If you're telling me that restricted slaves have > been compromised with a crypto Miner, I'd be happy to discuss that matter > and assist. > > Another attack vector is the Jenkins master, correct. If somebody > infiltrates the Jenkins master, they can use that to jump onto the > restricted slaves. They might modify the created artifacts, but once the > system gets cleaned up, we're good to go again (You might rather want to > consider a virus scan on the machines and created artifacts). > > But now let's say Jenkins master gets comprised. In that case, the > artifacts are not the issue but the credentials. Jenkins contains committer > credentials, which would allow to inject malware into our repository. Don't > forget that a committer can add commits to other PRs, manually fake the CI > status and then squash the PR to basically hide most of the traces. Unless > someone reviews every single commit on master, we're basically out of luck. > > So yeah, that attack vector through the Jenkins master is valid, but > considering that there are bigger risks involved in the system and the > slaves themselves are pretty well protected, I'd not consider CD a severe > issue in relation to the overall risk score of our system. > > So in order to make sure that we're well protected, I'd recommend to spend > a bit of time on adapting the Jenkins pipeline to upload to s3 and then use > all the remaining time to actually harden the Jenkins master and make sure > that everything is constantly kept up to date. Security-wise, I'd consider > that a way better investment than developing a new CD. > > -Marco > > Pedro Larroy schrieb am Mi., 8. Jan. 2020, > 22:49: > > > Marco, if you are fine publishing to an S3 bucket, what's your concern? > > using a codebuild pipeline? The build logs could be push to the s3 bucket > > if this is your concern. > > > > As I said before, having binary releases in the current CI doesn't stand > a > > chance to pass security review as it is today, it's not safe and is a bad > > idea, alternatives are > > 1 -Code Build (you don't support this because it's company owned, did I > > understand this correctly?) > > 2 - Apache owned Jenkins (can you help with this?) > > 3 - Travis CI or similar, which in the end is similar to code build. > > 4- Another Jenkins just for CD (who owns?) > > > > Pedro. > > > > On Wed, Jan 8, 2020 at 1:01 PM Marco de Abreu > > wrote: > > > > > The risk of the current CD via Jenkins is known and was accepted as > part > > of > > > adopting Jenkins. The solution for the initial issue - no longer > > publishing > > > to pypi - is to add a step to the existing CD pipeline which publishes > > the > > > package to the s3 bucket instead of pypi. > > > > > > -Marco > > > > > > Pedro Larroy schrieb am Mi., 8. Jan. > > 2020, > > > 21:55: > > > > > > > I understand your point. But you don't provide an alternative, and > > > building > > > > binary releases from the CI jenkins as it is today is a very bad idea > > > since > > > > it's an unsafe environment. I think it's fair to ask if you are > vetoing > > > > using codebuild for nightly releases you could provide an alternative > > > > solution (for example Apache hosted Jenkins) or anything else. As you > > are > > > > well aware non-committers can't communicate with Apache Infra or make > > > > requests, so the onus is on you or other Apache person to provide a > > > > solution that aligns with Apache values. > > > > > > > > So far I see Sam trying to help with codebuild managed binary > releases > > > and > > > > this is taken as a tinfoil hat corporate conspiracy. It's a pity that > > you > > > > claim
Re: Stopping nightly releases to Pypi
Correct, I'm not bothered by the s3 bucket but by way how it gets published. It's not in Jenkins, so it's outside of the projects control. The security design due to the restricted nodes makes sure that no third party can gain access to these machines. They use separate caches, separate volumes, different instance profiles etc - I personally would consider the restricted slaves safe. If you're telling me that restricted slaves have been compromised with a crypto Miner, I'd be happy to discuss that matter and assist. Another attack vector is the Jenkins master, correct. If somebody infiltrates the Jenkins master, they can use that to jump onto the restricted slaves. They might modify the created artifacts, but once the system gets cleaned up, we're good to go again (You might rather want to consider a virus scan on the machines and created artifacts). But now let's say Jenkins master gets comprised. In that case, the artifacts are not the issue but the credentials. Jenkins contains committer credentials, which would allow to inject malware into our repository. Don't forget that a committer can add commits to other PRs, manually fake the CI status and then squash the PR to basically hide most of the traces. Unless someone reviews every single commit on master, we're basically out of luck. So yeah, that attack vector through the Jenkins master is valid, but considering that there are bigger risks involved in the system and the slaves themselves are pretty well protected, I'd not consider CD a severe issue in relation to the overall risk score of our system. So in order to make sure that we're well protected, I'd recommend to spend a bit of time on adapting the Jenkins pipeline to upload to s3 and then use all the remaining time to actually harden the Jenkins master and make sure that everything is constantly kept up to date. Security-wise, I'd consider that a way better investment than developing a new CD. -Marco Pedro Larroy schrieb am Mi., 8. Jan. 2020, 22:49: > Marco, if you are fine publishing to an S3 bucket, what's your concern? > using a codebuild pipeline? The build logs could be push to the s3 bucket > if this is your concern. > > As I said before, having binary releases in the current CI doesn't stand a > chance to pass security review as it is today, it's not safe and is a bad > idea, alternatives are > 1 -Code Build (you don't support this because it's company owned, did I > understand this correctly?) > 2 - Apache owned Jenkins (can you help with this?) > 3 - Travis CI or similar, which in the end is similar to code build. > 4- Another Jenkins just for CD (who owns?) > > Pedro. > > On Wed, Jan 8, 2020 at 1:01 PM Marco de Abreu > wrote: > > > The risk of the current CD via Jenkins is known and was accepted as part > of > > adopting Jenkins. The solution for the initial issue - no longer > publishing > > to pypi - is to add a step to the existing CD pipeline which publishes > the > > package to the s3 bucket instead of pypi. > > > > -Marco > > > > Pedro Larroy schrieb am Mi., 8. Jan. > 2020, > > 21:55: > > > > > I understand your point. But you don't provide an alternative, and > > building > > > binary releases from the CI jenkins as it is today is a very bad idea > > since > > > it's an unsafe environment. I think it's fair to ask if you are vetoing > > > using codebuild for nightly releases you could provide an alternative > > > solution (for example Apache hosted Jenkins) or anything else. As you > are > > > well aware non-committers can't communicate with Apache Infra or make > > > requests, so the onus is on you or other Apache person to provide a > > > solution that aligns with Apache values. > > > > > > So far I see Sam trying to help with codebuild managed binary releases > > and > > > this is taken as a tinfoil hat corporate conspiracy. It's a pity that > you > > > claim to endorse Apache values but not support what's best for the > > project, > > > which is to have things clean and in working order. I don't think users > > > care where the binary releases are hosted. > > > > > > Pedro. > > > > > > On Sun, Jan 5, 2020 at 5:56 AM Marco de Abreu > > > > wrote: > > > > > > > Apache only cares about source releases as far as official releases > are > > > > concerned. But Apache also cares about it's brand and image. You are > > > right > > > > that anybody can compile an Apache project and distribute it, but > it's > > > > under the PMCs control what can be advertised as official. This > > includes > > > > the following examples: > > > > > > > > - The official MXNet pypi, dockerhub, maven, etc account > > > > - The MXNet website > > > > - anything advertising to be MXNet > > > > > > > > If you publish a binary release and call it > "AwesomeSpaghettiBolognese" > > > > while it's MXNet under the hood, that's totally in line with the > Apache > > > > license. But if you decide to publish an MXNet branded package, then > > > that's > > > > covered by the brand protection. I won't go i
Re: Stopping nightly releases to Pypi
Marco, if you are fine publishing to an S3 bucket, what's your concern? using a codebuild pipeline? The build logs could be push to the s3 bucket if this is your concern. As I said before, having binary releases in the current CI doesn't stand a chance to pass security review as it is today, it's not safe and is a bad idea, alternatives are 1 -Code Build (you don't support this because it's company owned, did I understand this correctly?) 2 - Apache owned Jenkins (can you help with this?) 3 - Travis CI or similar, which in the end is similar to code build. 4- Another Jenkins just for CD (who owns?) Pedro. On Wed, Jan 8, 2020 at 1:01 PM Marco de Abreu wrote: > The risk of the current CD via Jenkins is known and was accepted as part of > adopting Jenkins. The solution for the initial issue - no longer publishing > to pypi - is to add a step to the existing CD pipeline which publishes the > package to the s3 bucket instead of pypi. > > -Marco > > Pedro Larroy schrieb am Mi., 8. Jan. 2020, > 21:55: > > > I understand your point. But you don't provide an alternative, and > building > > binary releases from the CI jenkins as it is today is a very bad idea > since > > it's an unsafe environment. I think it's fair to ask if you are vetoing > > using codebuild for nightly releases you could provide an alternative > > solution (for example Apache hosted Jenkins) or anything else. As you are > > well aware non-committers can't communicate with Apache Infra or make > > requests, so the onus is on you or other Apache person to provide a > > solution that aligns with Apache values. > > > > So far I see Sam trying to help with codebuild managed binary releases > and > > this is taken as a tinfoil hat corporate conspiracy. It's a pity that you > > claim to endorse Apache values but not support what's best for the > project, > > which is to have things clean and in working order. I don't think users > > care where the binary releases are hosted. > > > > Pedro. > > > > On Sun, Jan 5, 2020 at 5:56 AM Marco de Abreu > > wrote: > > > > > Apache only cares about source releases as far as official releases are > > > concerned. But Apache also cares about it's brand and image. You are > > right > > > that anybody can compile an Apache project and distribute it, but it's > > > under the PMCs control what can be advertised as official. This > includes > > > the following examples: > > > > > > - The official MXNet pypi, dockerhub, maven, etc account > > > - The MXNet website > > > - anything advertising to be MXNet > > > > > > If you publish a binary release and call it "AwesomeSpaghettiBolognese" > > > while it's MXNet under the hood, that's totally in line with the Apache > > > license. But if you decide to publish an MXNet branded package, then > > that's > > > covered by the brand protection. I won't go into much more detail about > > > legal reasons since that's not helping this discussion. > > > > > > I personally am vetoing a company-owned distribution channel to be > > > advertised on the MXNet website or any official documentation. Also, > I'd > > > like to make sure that users do not mistake it for being a release that > > is > > > affiliated or endorsed by Apache MXNet. > > > > > > We are taking a step back here and it's a pity to see that some people > > are > > > still not endorsing the Apache values. This will be my last email > > regarding > > > that topic and I will only follow up with actions after the 15th of > > January > > > has been reached. > > > > > > Best regards > > > Marco > > > > > > > > > Pedro Larroy schrieb am Sa., 4. Jan. > > 2020, > > > 02:38: > > > > > > > Hey Marco. > > > > > > > > As far as I have learned from other Apache mailing lists while > lurking > > is > > > > that Apache only cares about making source releases, binaries are a > > > > courtesy to users that some projects decide to do, but I'm not sure I > > > > understand your concerns regarding the PMC and what exactly are you > > > vetoing > > > > here, since everyone can compile, build and package our project as > per > > > the > > > > open source license. I would suggest to have a constructive approach > > and > > > > see how we can make this happen for the best of the project, > specially > > > > since somebody is volunteering to help with this and dedicate > valuable > > > > compute resources and people's time. > > > > > > > > Regarding manual changes I don't see any need to have access to a > code > > > > build control plane for *anybody*, for several reasons, first is that > > > > manual access to production account is a discouraged practice and are > > > best > > > > managed through pipeline deployments, second is that Code build is a > > > hosted > > > > service which is basically just using a build description file to do > > the > > > > work, there's no need to do any manual fiddling or triggering. If all > > the > > > > CD and description files are in the apache repository you can use > your > > > own > > > > account or c
Re: Stopping nightly releases to Pypi
Is not about Jenkins the software, is about the CI environment, which is not secure. Last week there was crypto mining activity on the dev environment, code can be injected on binary releases very easily. It should be a separate instance for CD, so maybe you can facilitate that with Apache as part of your suggestion. On Wed, Jan 8, 2020 at 1:01 PM Marco de Abreu wrote: > The risk of the current CD via Jenkins is known and was accepted as part of > adopting Jenkins. The solution for the initial issue - no longer publishing > to pypi - is to add a step to the existing CD pipeline which publishes the > package to the s3 bucket instead of pypi. > > -Marco > > Pedro Larroy schrieb am Mi., 8. Jan. 2020, > 21:55: > > > I understand your point. But you don't provide an alternative, and > building > > binary releases from the CI jenkins as it is today is a very bad idea > since > > it's an unsafe environment. I think it's fair to ask if you are vetoing > > using codebuild for nightly releases you could provide an alternative > > solution (for example Apache hosted Jenkins) or anything else. As you are > > well aware non-committers can't communicate with Apache Infra or make > > requests, so the onus is on you or other Apache person to provide a > > solution that aligns with Apache values. > > > > So far I see Sam trying to help with codebuild managed binary releases > and > > this is taken as a tinfoil hat corporate conspiracy. It's a pity that you > > claim to endorse Apache values but not support what's best for the > project, > > which is to have things clean and in working order. I don't think users > > care where the binary releases are hosted. > > > > Pedro. > > > > On Sun, Jan 5, 2020 at 5:56 AM Marco de Abreu > > wrote: > > > > > Apache only cares about source releases as far as official releases are > > > concerned. But Apache also cares about it's brand and image. You are > > right > > > that anybody can compile an Apache project and distribute it, but it's > > > under the PMCs control what can be advertised as official. This > includes > > > the following examples: > > > > > > - The official MXNet pypi, dockerhub, maven, etc account > > > - The MXNet website > > > - anything advertising to be MXNet > > > > > > If you publish a binary release and call it "AwesomeSpaghettiBolognese" > > > while it's MXNet under the hood, that's totally in line with the Apache > > > license. But if you decide to publish an MXNet branded package, then > > that's > > > covered by the brand protection. I won't go into much more detail about > > > legal reasons since that's not helping this discussion. > > > > > > I personally am vetoing a company-owned distribution channel to be > > > advertised on the MXNet website or any official documentation. Also, > I'd > > > like to make sure that users do not mistake it for being a release that > > is > > > affiliated or endorsed by Apache MXNet. > > > > > > We are taking a step back here and it's a pity to see that some people > > are > > > still not endorsing the Apache values. This will be my last email > > regarding > > > that topic and I will only follow up with actions after the 15th of > > January > > > has been reached. > > > > > > Best regards > > > Marco > > > > > > > > > Pedro Larroy schrieb am Sa., 4. Jan. > > 2020, > > > 02:38: > > > > > > > Hey Marco. > > > > > > > > As far as I have learned from other Apache mailing lists while > lurking > > is > > > > that Apache only cares about making source releases, binaries are a > > > > courtesy to users that some projects decide to do, but I'm not sure I > > > > understand your concerns regarding the PMC and what exactly are you > > > vetoing > > > > here, since everyone can compile, build and package our project as > per > > > the > > > > open source license. I would suggest to have a constructive approach > > and > > > > see how we can make this happen for the best of the project, > specially > > > > since somebody is volunteering to help with this and dedicate > valuable > > > > compute resources and people's time. > > > > > > > > Regarding manual changes I don't see any need to have access to a > code > > > > build control plane for *anybody*, for several reasons, first is that > > > > manual access to production account is a discouraged practice and are > > > best > > > > managed through pipeline deployments, second is that Code build is a > > > hosted > > > > service which is basically just using a build description file to do > > the > > > > work, there's no need to do any manual fiddling or triggering. If all > > the > > > > CD and description files are in the apache repository you can use > your > > > own > > > > account or compute resources to do your own build flavor if you so > > > desire. > > > > > > > > Is your proposal to host this in Apache infrastructure? Maybe I'm > > > missing > > > > something on this conversation > > > > > > > > Pedro. > > > > > > > > > > > > On Fri, Jan 3, 2020 at 3:21 PM Marco de Abre
Re: Stopping nightly releases to Pypi
Pedro: > binary releases from the CI jenkins as it is today is a very bad idea since it's an unsafe environment Can you clarify this statement? We could grant an Instance Profile to the Jenkins master instance so that it can push artifacts to an S3 bucket. Do you mean that virus or malware could creep into the artifacts? I thought Jenkins builds artifacts only for the master branch, not pull requests, so an adversary would need to slip malware through the eyes of the reviewers. Philip. On Wed, Jan 8, 2020 at 1:01 PM Marco de Abreu wrote: > The risk of the current CD via Jenkins is known and was accepted as part of > adopting Jenkins. The solution for the initial issue - no longer publishing > to pypi - is to add a step to the existing CD pipeline which publishes the > package to the s3 bucket instead of pypi. > > -Marco > > Pedro Larroy schrieb am Mi., 8. Jan. 2020, > 21:55: > > > I understand your point. But you don't provide an alternative, and > building > > binary releases from the CI jenkins as it is today is a very bad idea > since > > it's an unsafe environment. I think it's fair to ask if you are vetoing > > using codebuild for nightly releases you could provide an alternative > > solution (for example Apache hosted Jenkins) or anything else. As you are > > well aware non-committers can't communicate with Apache Infra or make > > requests, so the onus is on you or other Apache person to provide a > > solution that aligns with Apache values. > > > > So far I see Sam trying to help with codebuild managed binary releases > and > > this is taken as a tinfoil hat corporate conspiracy. It's a pity that you > > claim to endorse Apache values but not support what's best for the > project, > > which is to have things clean and in working order. I don't think users > > care where the binary releases are hosted. > > > > Pedro. > > > > On Sun, Jan 5, 2020 at 5:56 AM Marco de Abreu > > wrote: > > > > > Apache only cares about source releases as far as official releases are > > > concerned. But Apache also cares about it's brand and image. You are > > right > > > that anybody can compile an Apache project and distribute it, but it's > > > under the PMCs control what can be advertised as official. This > includes > > > the following examples: > > > > > > - The official MXNet pypi, dockerhub, maven, etc account > > > - The MXNet website > > > - anything advertising to be MXNet > > > > > > If you publish a binary release and call it "AwesomeSpaghettiBolognese" > > > while it's MXNet under the hood, that's totally in line with the Apache > > > license. But if you decide to publish an MXNet branded package, then > > that's > > > covered by the brand protection. I won't go into much more detail about > > > legal reasons since that's not helping this discussion. > > > > > > I personally am vetoing a company-owned distribution channel to be > > > advertised on the MXNet website or any official documentation. Also, > I'd > > > like to make sure that users do not mistake it for being a release that > > is > > > affiliated or endorsed by Apache MXNet. > > > > > > We are taking a step back here and it's a pity to see that some people > > are > > > still not endorsing the Apache values. This will be my last email > > regarding > > > that topic and I will only follow up with actions after the 15th of > > January > > > has been reached. > > > > > > Best regards > > > Marco > > > > > > > > > Pedro Larroy schrieb am Sa., 4. Jan. > > 2020, > > > 02:38: > > > > > > > Hey Marco. > > > > > > > > As far as I have learned from other Apache mailing lists while > lurking > > is > > > > that Apache only cares about making source releases, binaries are a > > > > courtesy to users that some projects decide to do, but I'm not sure I > > > > understand your concerns regarding the PMC and what exactly are you > > > vetoing > > > > here, since everyone can compile, build and package our project as > per > > > the > > > > open source license. I would suggest to have a constructive approach > > and > > > > see how we can make this happen for the best of the project, > specially > > > > since somebody is volunteering to help with this and dedicate > valuable > > > > compute resources and people's time. > > > > > > > > Regarding manual changes I don't see any need to have access to a > code > > > > build control plane for *anybody*, for several reasons, first is that > > > > manual access to production account is a discouraged practice and are > > > best > > > > managed through pipeline deployments, second is that Code build is a > > > hosted > > > > service which is basically just using a build description file to do > > the > > > > work, there's no need to do any manual fiddling or triggering. If all > > the > > > > CD and description files are in the apache repository you can use > your > > > own > > > > account or compute resources to do your own build flavor if you so > > > desire. > > > > > > > > Is your proposal to host this in Apa
Re: Stopping nightly releases to Pypi
The risk of the current CD via Jenkins is known and was accepted as part of adopting Jenkins. The solution for the initial issue - no longer publishing to pypi - is to add a step to the existing CD pipeline which publishes the package to the s3 bucket instead of pypi. -Marco Pedro Larroy schrieb am Mi., 8. Jan. 2020, 21:55: > I understand your point. But you don't provide an alternative, and building > binary releases from the CI jenkins as it is today is a very bad idea since > it's an unsafe environment. I think it's fair to ask if you are vetoing > using codebuild for nightly releases you could provide an alternative > solution (for example Apache hosted Jenkins) or anything else. As you are > well aware non-committers can't communicate with Apache Infra or make > requests, so the onus is on you or other Apache person to provide a > solution that aligns with Apache values. > > So far I see Sam trying to help with codebuild managed binary releases and > this is taken as a tinfoil hat corporate conspiracy. It's a pity that you > claim to endorse Apache values but not support what's best for the project, > which is to have things clean and in working order. I don't think users > care where the binary releases are hosted. > > Pedro. > > On Sun, Jan 5, 2020 at 5:56 AM Marco de Abreu > wrote: > > > Apache only cares about source releases as far as official releases are > > concerned. But Apache also cares about it's brand and image. You are > right > > that anybody can compile an Apache project and distribute it, but it's > > under the PMCs control what can be advertised as official. This includes > > the following examples: > > > > - The official MXNet pypi, dockerhub, maven, etc account > > - The MXNet website > > - anything advertising to be MXNet > > > > If you publish a binary release and call it "AwesomeSpaghettiBolognese" > > while it's MXNet under the hood, that's totally in line with the Apache > > license. But if you decide to publish an MXNet branded package, then > that's > > covered by the brand protection. I won't go into much more detail about > > legal reasons since that's not helping this discussion. > > > > I personally am vetoing a company-owned distribution channel to be > > advertised on the MXNet website or any official documentation. Also, I'd > > like to make sure that users do not mistake it for being a release that > is > > affiliated or endorsed by Apache MXNet. > > > > We are taking a step back here and it's a pity to see that some people > are > > still not endorsing the Apache values. This will be my last email > regarding > > that topic and I will only follow up with actions after the 15th of > January > > has been reached. > > > > Best regards > > Marco > > > > > > Pedro Larroy schrieb am Sa., 4. Jan. > 2020, > > 02:38: > > > > > Hey Marco. > > > > > > As far as I have learned from other Apache mailing lists while lurking > is > > > that Apache only cares about making source releases, binaries are a > > > courtesy to users that some projects decide to do, but I'm not sure I > > > understand your concerns regarding the PMC and what exactly are you > > vetoing > > > here, since everyone can compile, build and package our project as per > > the > > > open source license. I would suggest to have a constructive approach > and > > > see how we can make this happen for the best of the project, specially > > > since somebody is volunteering to help with this and dedicate valuable > > > compute resources and people's time. > > > > > > Regarding manual changes I don't see any need to have access to a code > > > build control plane for *anybody*, for several reasons, first is that > > > manual access to production account is a discouraged practice and are > > best > > > managed through pipeline deployments, second is that Code build is a > > hosted > > > service which is basically just using a build description file to do > the > > > work, there's no need to do any manual fiddling or triggering. If all > the > > > CD and description files are in the apache repository you can use your > > own > > > account or compute resources to do your own build flavor if you so > > desire. > > > > > > Is your proposal to host this in Apache infrastructure? Maybe I'm > > missing > > > something on this conversation > > > > > > Pedro. > > > > > > > > > On Fri, Jan 3, 2020 at 3:21 PM Marco de Abreu > > > > wrote: > > > > > > > Sam, while I understand that this solution was developed out of > > > necessity, > > > > my question why a new system has been developed instead of fixing the > > > > existing one or adapting the solution. CodeBuild is a scheduler in > the > > > same > > > > fashion as Jenkins is. It runs code. So you can adapt it to Jenkins > > > without > > > > much hassle. > > > > > > > > I'm not volunteering for this - why should I? The role of a PMC > member > > is > > > > to steer the direction of the project. Just because a manager points > > > > towards a certain direction, if doesn't
Re: Stopping nightly releases to Pypi
I understand your point. But you don't provide an alternative, and building binary releases from the CI jenkins as it is today is a very bad idea since it's an unsafe environment. I think it's fair to ask if you are vetoing using codebuild for nightly releases you could provide an alternative solution (for example Apache hosted Jenkins) or anything else. As you are well aware non-committers can't communicate with Apache Infra or make requests, so the onus is on you or other Apache person to provide a solution that aligns with Apache values. So far I see Sam trying to help with codebuild managed binary releases and this is taken as a tinfoil hat corporate conspiracy. It's a pity that you claim to endorse Apache values but not support what's best for the project, which is to have things clean and in working order. I don't think users care where the binary releases are hosted. Pedro. On Sun, Jan 5, 2020 at 5:56 AM Marco de Abreu wrote: > Apache only cares about source releases as far as official releases are > concerned. But Apache also cares about it's brand and image. You are right > that anybody can compile an Apache project and distribute it, but it's > under the PMCs control what can be advertised as official. This includes > the following examples: > > - The official MXNet pypi, dockerhub, maven, etc account > - The MXNet website > - anything advertising to be MXNet > > If you publish a binary release and call it "AwesomeSpaghettiBolognese" > while it's MXNet under the hood, that's totally in line with the Apache > license. But if you decide to publish an MXNet branded package, then that's > covered by the brand protection. I won't go into much more detail about > legal reasons since that's not helping this discussion. > > I personally am vetoing a company-owned distribution channel to be > advertised on the MXNet website or any official documentation. Also, I'd > like to make sure that users do not mistake it for being a release that is > affiliated or endorsed by Apache MXNet. > > We are taking a step back here and it's a pity to see that some people are > still not endorsing the Apache values. This will be my last email regarding > that topic and I will only follow up with actions after the 15th of January > has been reached. > > Best regards > Marco > > > Pedro Larroy schrieb am Sa., 4. Jan. 2020, > 02:38: > > > Hey Marco. > > > > As far as I have learned from other Apache mailing lists while lurking is > > that Apache only cares about making source releases, binaries are a > > courtesy to users that some projects decide to do, but I'm not sure I > > understand your concerns regarding the PMC and what exactly are you > vetoing > > here, since everyone can compile, build and package our project as per > the > > open source license. I would suggest to have a constructive approach and > > see how we can make this happen for the best of the project, specially > > since somebody is volunteering to help with this and dedicate valuable > > compute resources and people's time. > > > > Regarding manual changes I don't see any need to have access to a code > > build control plane for *anybody*, for several reasons, first is that > > manual access to production account is a discouraged practice and are > best > > managed through pipeline deployments, second is that Code build is a > hosted > > service which is basically just using a build description file to do the > > work, there's no need to do any manual fiddling or triggering. If all the > > CD and description files are in the apache repository you can use your > own > > account or compute resources to do your own build flavor if you so > desire. > > > > Is your proposal to host this in Apache infrastructure? Maybe I'm > missing > > something on this conversation > > > > Pedro. > > > > > > On Fri, Jan 3, 2020 at 3:21 PM Marco de Abreu > > wrote: > > > > > Sam, while I understand that this solution was developed out of > > necessity, > > > my question why a new system has been developed instead of fixing the > > > existing one or adapting the solution. CodeBuild is a scheduler in the > > same > > > fashion as Jenkins is. It runs code. So you can adapt it to Jenkins > > without > > > much hassle. > > > > > > I'm not volunteering for this - why should I? The role of a PMC member > is > > > to steer the direction of the project. Just because a manager points > > > towards a certain direction, if doesn't mean that they're going to do > it. > > > > > > Apparently there was enough time at some point to develop a new > solution > > > from scratch. It might have been a solution for your internal team and > > > that's fine, but upgrading it "temporarily" to be the advertised way on > > the > > > official website is something different. > > > > > > I won't argue about how the veto can be enforced. I think it's in the > > best > > > interest of the project if we try working on a solution instead of > > spending > > > time on trying to figure out the power of t
