Re: [openstack-dev] [TC] [Infra] Terms of service for hosted projects
Excerpts from Jeremy Stanley's message of 2018-06-06 20:09:36 +: > On 2018-06-06 14:52:04 -0400 (-0400), Zane Bitter wrote: > > On 29/05/18 13:37, Jeremy Stanley wrote: > > > On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote: > [...] > > > > * If the repo is a fork of another project, there must be (public) > > > > evidence of an attempt to co-ordinate with the upstream first. > > > > > > I don't recall this ever being mandated, though the project-config > > > reviewers do often provide suggestions to project creators such as > > > places in the existing community with which they might consider > > > cooperating/collaborating. > > > > We're mandating it for StarlingX, aren't we? > > This goes back to depending on what you mean by "we" but assuming > you mean those of us who were in the community track Forum room at > the end of the day on Thursday, a number of us seemed to be in > support of that idea including Dean (who was going to do the work to > make it happen) and Jonathan (as OSF executive director). Far from a > mandate, and definitely a rare enough situation that recording a > hard and fast rule is not a useful way to spend our valuable time. > > > AIUI we haven't otherwise forked anything that was still maintained > > (although we've forked plenty of libraries after establishing that the > > upstream was moribund). > > All the Debian packaging, when we were hosting it (before it got > retired and moved back to Debian's repository hosting) was > implemented as forks of our Git repositories. The Infra team also > maintains a fork of Gerrit (for the purposes of backporting bug > fixes from later versions until we're ready to upgrade what we're > running), and has some forks of other things which are basically > dead upstream (lodgeit) or where we're stuck carrying support for > very old versions of stuff that upstream has since moved on from > (puppet-apache). Forks are not necessarily inherently bad, and > usually the story around each one is somewhat unique. Yeah, if I had realized the Debian packaging repos had changes beyond packaging I wouldn't have supported hosting them at the time. Because the gerrit fork is for the use of this community with our deployment, we do try to upstream fixes, and we don't intend to release it separately under our own distribution, I see that as reasonable. I'm trying to look at this from the perspective of the Golden Rule [1]. We not treat other projects in ways we don't want to be treated ourselves, regardless of whether we're doing it out in the open. I don't want the OpenStack community to have the reputation of forking instead of collaborating. [1] https://en.wikipedia.org/wiki/Golden_Rule > > > > Neither of those appears to be documented (specifically, > > > > https://governance.openstack.org/tc/reference/licensing.html only > > > > specifies licensing requirements for official projects, libraries > > > > imported by official projects, and software used by the Infra > > > > team). > > > > > > The Infrastructure team has been granted a fair amount of autonomy > > > to determine its operating guidelines, and future plans to separate > > > project hosting further from the OpenStack name (in an attempt to > > > make it more clear that hosting your project in the infrastructure > > > is not an endorsement by OpenStack and doesn't make it "part of > > > OpenStack") make the OpenStack TC governance site a particularly > > > poor choice of venue to document such things. > > > > So clearly in the future this will be the responsibility of the > > Winterscale Infrastructure Council assuming that proposal goes > > ahead. > > > > For now, would it be valuable for the TC to develop some > > guidelines that will provide the WIC with a solid base it can > > evolve from once it takes them over, or should we just leave it up > > to infra's discretion? > [...] > > My opinion is that helping clarify the terms of service > documentation the Infra team is already maintaining is great, but > putting hosting terms of service in the TC governance repo is likely > a poor choice of venue. In the past it has fallen to the Infra team > to help people come to the right conclusions as to what sorts of > behaviors are acceptable, but we've preferred to avoid having lots > of proscriptive rules and beating people into submission with them. > I think we'd all like this to remain a fun and friendly place to get > things done. I want it to be fun, too. One way to ensure that is to try to avoid these situations where one group angers another through some action that the broader community can generally agree is not acceptable to us by writing those policies down. I agree this is ultimately going to be something we rely on the infra team to deal with. I think it's reasonable for the rest of the community to try to help establish the preferences about what policies should be in place. Doug __ OpenSt
Re: [openstack-dev] [TC] [Infra] Terms of service for hosted projects
Excerpts from Anne Bertucio's message of 2018-06-06 12:28:25 -0700: > > Either way, I would like to ensure that someone from > > Kata is communicating with qemu upstream. > > Since probably not too many Kata folks are on the OpenStack dev list > (something to tackle in another thread or OSF all-project meeting), chiming > in to say yup!, we’ve got QEMU upstream folks in the Kata community, and > we’re definitely committed to making sure we communicate with other > communities about these things (be it QEMU or another group in the future). > > > Anne Bertucio > OpenStack Foundation > a...@openstack.org | irc: annabelleB Thanks for confirming that, Anne! Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TC] [Infra] Terms of service for hosted projects
On 2018-06-06 15:16:59 -0400 (-0400), Doug Hellmann wrote: [...] > Kata also has a qemu fork, but that is under the kata-containers > github org and not our infrastructure. I'm not sure someone outside > of our community would differentiate between the two, but maybe > they would. [...] The Kata community (currently) hosts all their work in GitHub rather than our infrastructure, so I'm not sure that's an altogether useful distinction. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TC] [Infra] Terms of service for hosted projects
On 2018-06-06 14:52:04 -0400 (-0400), Zane Bitter wrote: > On 29/05/18 13:37, Jeremy Stanley wrote: > > On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote: [...] > > > * If the repo is a fork of another project, there must be (public) > > > evidence of an attempt to co-ordinate with the upstream first. > > > > I don't recall this ever being mandated, though the project-config > > reviewers do often provide suggestions to project creators such as > > places in the existing community with which they might consider > > cooperating/collaborating. > > We're mandating it for StarlingX, aren't we? This goes back to depending on what you mean by "we" but assuming you mean those of us who were in the community track Forum room at the end of the day on Thursday, a number of us seemed to be in support of that idea including Dean (who was going to do the work to make it happen) and Jonathan (as OSF executive director). Far from a mandate, and definitely a rare enough situation that recording a hard and fast rule is not a useful way to spend our valuable time. > AIUI we haven't otherwise forked anything that was still maintained > (although we've forked plenty of libraries after establishing that the > upstream was moribund). All the Debian packaging, when we were hosting it (before it got retired and moved back to Debian's repository hosting) was implemented as forks of our Git repositories. The Infra team also maintains a fork of Gerrit (for the purposes of backporting bug fixes from later versions until we're ready to upgrade what we're running), and has some forks of other things which are basically dead upstream (lodgeit) or where we're stuck carrying support for very old versions of stuff that upstream has since moved on from (puppet-apache). Forks are not necessarily inherently bad, and usually the story around each one is somewhat unique. > > > Neither of those appears to be documented (specifically, > > > https://governance.openstack.org/tc/reference/licensing.html only > > > specifies licensing requirements for official projects, libraries > > > imported by official projects, and software used by the Infra > > > team). > > > > The Infrastructure team has been granted a fair amount of autonomy > > to determine its operating guidelines, and future plans to separate > > project hosting further from the OpenStack name (in an attempt to > > make it more clear that hosting your project in the infrastructure > > is not an endorsement by OpenStack and doesn't make it "part of > > OpenStack") make the OpenStack TC governance site a particularly > > poor choice of venue to document such things. > > So clearly in the future this will be the responsibility of the > Winterscale Infrastructure Council assuming that proposal goes > ahead. > > For now, would it be valuable for the TC to develop some > guidelines that will provide the WIC with a solid base it can > evolve from once it takes them over, or should we just leave it up > to infra's discretion? [...] My opinion is that helping clarify the terms of service documentation the Infra team is already maintaining is great, but putting hosting terms of service in the TC governance repo is likely a poor choice of venue. In the past it has fallen to the Infra team to help people come to the right conclusions as to what sorts of behaviors are acceptable, but we've preferred to avoid having lots of proscriptive rules and beating people into submission with them. I think we'd all like this to remain a fun and friendly place to get things done. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TC] [Infra] Terms of service for hosted projects
> Either way, I would like to ensure that someone from > Kata is communicating with qemu upstream. Since probably not too many Kata folks are on the OpenStack dev list (something to tackle in another thread or OSF all-project meeting), chiming in to say yup!, we’ve got QEMU upstream folks in the Kata community, and we’re definitely committed to making sure we communicate with other communities about these things (be it QEMU or another group in the future). Anne Bertucio OpenStack Foundation a...@openstack.org | irc: annabelleB > On Jun 6, 2018, at 12:16 PM, Doug Hellmann wrote: > > Excerpts from Zane Bitter's message of 2018-06-06 14:52:04 -0400: >> On 29/05/18 13:37, Jeremy Stanley wrote: >>> On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote: We allow various open source projects that are not an official part of OpenStack or necessarily used by OpenStack to be hosted on OpenStack infrastructure - previously under the 'StackForge' branding, but now without separate branding. Do we document anywhere the terms of service under which we offer such hosting? >>> >>> We do so minimally here: >>> >>> https://docs.openstack.org/infra/system-config/unofficial_project_hosting.html >>> >>> It's linked from this section of the Project Creator’s Guide in the >>> Infra Manual: >>> >>> https://docs.openstack.org/infra/manual/creators.html#decide-status-of-your-project >>> >>> But yes, we should probably add some clarity to that document and >>> see about making sure it's linked more prominently. We also maintain >>> some guidelines for reviewers of changes to the >>> openstack-infra/project-config repository, which has a bit to say >>> about new repository creation changes: >>> >>> https://git.openstack.org/cgit/openstack-infra/project-config/tree/REVIEWING.rst >>> It is my understanding that the infra team will enforce the following conditions when a repo import request is received: * The repo must be licensed under an OSI-approved open source license. >>> >>> That has been our custom, but we should add a statement to this >>> effect in the aforementioned document. >>> * If the repo is a fork of another project, there must be (public) evidence of an attempt to co-ordinate with the upstream first. >>> >>> I don't recall this ever being mandated, though the project-config >>> reviewers do often provide suggestions to project creators such as >>> places in the existing community with which they might consider >>> cooperating/collaborating. >> >> We're mandating it for StarlingX, aren't we? > > We suggested that it would make importing the repositories more > palatable, and Dean said he would do it. Which isn't quite the same > as making it a requirement. > >> >> AIUI we haven't otherwise forked anything that was still maintained >> (although we've forked plenty of libraries after establishing that the >> upstream was moribund). > > Kata has a fork of the kernel, but that feels less controversial > because the kernel community expects forks as part of their contribution > process. > > Kata also has a qemu fork, but that is under the kata-containers > github org and not our infrastructure. I'm not sure someone outside > of our community would differentiate between the two, but maybe > they would. Either way, I would like to ensure that someone from > Kata is communicating with qemu upstream. > >> Neither of those appears to be documented (specifically, https://governance.openstack.org/tc/reference/licensing.html only specifies licensing requirements for official projects, libraries imported by official projects, and software used by the Infra team). >>> >>> The Infrastructure team has been granted a fair amount of autonomy >>> to determine its operating guidelines, and future plans to separate >>> project hosting further from the OpenStack name (in an attempt to >>> make it more clear that hosting your project in the infrastructure >>> is not an endorsement by OpenStack and doesn't make it "part of >>> OpenStack") make the OpenStack TC governance site a particularly >>> poor choice of venue to document such things. >> >> So clearly in the future this will be the responsibility of the >> Winterscale Infrastructure Council assuming that proposal goes ahead. >> >> For now, would it be valuable for the TC to develop some guidelines that >> will provide the WIC with a solid base it can evolve from once it takes >> them over, or should we just leave it up to infra's discretion? >> In addition, I think we should require projects hosted on our infrastructure to agree to other policies: * Adhere to the OpenStack Foundation Code of Conduct. >>> >>> This seems like a reasonable addition to our hosting requirements. >>> * Not misrepresent their relationship to the official OpenStack project or the Foundation. Ideally we'd come up with language that they *can* use to
Re: [openstack-dev] [TC] [Infra] Terms of service for hosted projects
Excerpts from Zane Bitter's message of 2018-06-06 14:52:04 -0400: > On 29/05/18 13:37, Jeremy Stanley wrote: > > On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote: > >> We allow various open source projects that are not an official > >> part of OpenStack or necessarily used by OpenStack to be hosted on > >> OpenStack infrastructure - previously under the 'StackForge' > >> branding, but now without separate branding. Do we document > >> anywhere the terms of service under which we offer such hosting? > > > > We do so minimally here: > > > > https://docs.openstack.org/infra/system-config/unofficial_project_hosting.html > > > > It's linked from this section of the Project Creator’s Guide in the > > Infra Manual: > > > > https://docs.openstack.org/infra/manual/creators.html#decide-status-of-your-project > > > > But yes, we should probably add some clarity to that document and > > see about making sure it's linked more prominently. We also maintain > > some guidelines for reviewers of changes to the > > openstack-infra/project-config repository, which has a bit to say > > about new repository creation changes: > > > > https://git.openstack.org/cgit/openstack-infra/project-config/tree/REVIEWING.rst > > > >> It is my understanding that the infra team will enforce the > >> following conditions when a repo import request is received: > >> > >> * The repo must be licensed under an OSI-approved open source > >> license. > > > > That has been our custom, but we should add a statement to this > > effect in the aforementioned document. > > > >> * If the repo is a fork of another project, there must be (public) > >> evidence of an attempt to co-ordinate with the upstream first. > > > > I don't recall this ever being mandated, though the project-config > > reviewers do often provide suggestions to project creators such as > > places in the existing community with which they might consider > > cooperating/collaborating. > > We're mandating it for StarlingX, aren't we? We suggested that it would make importing the repositories more palatable, and Dean said he would do it. Which isn't quite the same as making it a requirement. > > AIUI we haven't otherwise forked anything that was still maintained > (although we've forked plenty of libraries after establishing that the > upstream was moribund). Kata has a fork of the kernel, but that feels less controversial because the kernel community expects forks as part of their contribution process. Kata also has a qemu fork, but that is under the kata-containers github org and not our infrastructure. I'm not sure someone outside of our community would differentiate between the two, but maybe they would. Either way, I would like to ensure that someone from Kata is communicating with qemu upstream. > > >> Neither of those appears to be documented (specifically, > >> https://governance.openstack.org/tc/reference/licensing.html only > >> specifies licensing requirements for official projects, libraries > >> imported by official projects, and software used by the Infra > >> team). > > > > The Infrastructure team has been granted a fair amount of autonomy > > to determine its operating guidelines, and future plans to separate > > project hosting further from the OpenStack name (in an attempt to > > make it more clear that hosting your project in the infrastructure > > is not an endorsement by OpenStack and doesn't make it "part of > > OpenStack") make the OpenStack TC governance site a particularly > > poor choice of venue to document such things. > > So clearly in the future this will be the responsibility of the > Winterscale Infrastructure Council assuming that proposal goes ahead. > > For now, would it be valuable for the TC to develop some guidelines that > will provide the WIC with a solid base it can evolve from once it takes > them over, or should we just leave it up to infra's discretion? > > >> In addition, I think we should require projects hosted on our > >> infrastructure to agree to other policies: > >> > >> * Adhere to the OpenStack Foundation Code of Conduct. > > > > This seems like a reasonable addition to our hosting requirements. > > > >> * Not misrepresent their relationship to the official OpenStack > >> project or the Foundation. Ideally we'd come up with language that > >> they *can* use to describe their status, such as "hosted on the > >> OpenStack infrastructure". > > > > Also a great suggestion. We sort of say that in the "what being an > > unoffocial project is not" bullet list, but it could use some > > fleshing out. > > > >> If we don't have place where this kind of thing is documented > >> already, I'll submit a review adding one. Does anybody have any > >> ideas about a process for ensuring that projects have read and > >> agreed to the terms when we add them? > > > > Adding process forcing active confirmation of such rules seems like > > a lot of unnecessary overhead/red tape/bureaucracy. As it stands, > > we're working
Re: [openstack-dev] [TC] [Infra] Terms of service for hosted projects
On 29/05/18 13:37, Jeremy Stanley wrote: On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote: We allow various open source projects that are not an official part of OpenStack or necessarily used by OpenStack to be hosted on OpenStack infrastructure - previously under the 'StackForge' branding, but now without separate branding. Do we document anywhere the terms of service under which we offer such hosting? We do so minimally here: https://docs.openstack.org/infra/system-config/unofficial_project_hosting.html It's linked from this section of the Project Creator’s Guide in the Infra Manual: https://docs.openstack.org/infra/manual/creators.html#decide-status-of-your-project But yes, we should probably add some clarity to that document and see about making sure it's linked more prominently. We also maintain some guidelines for reviewers of changes to the openstack-infra/project-config repository, which has a bit to say about new repository creation changes: https://git.openstack.org/cgit/openstack-infra/project-config/tree/REVIEWING.rst It is my understanding that the infra team will enforce the following conditions when a repo import request is received: * The repo must be licensed under an OSI-approved open source license. That has been our custom, but we should add a statement to this effect in the aforementioned document. * If the repo is a fork of another project, there must be (public) evidence of an attempt to co-ordinate with the upstream first. I don't recall this ever being mandated, though the project-config reviewers do often provide suggestions to project creators such as places in the existing community with which they might consider cooperating/collaborating. We're mandating it for StarlingX, aren't we? AIUI we haven't otherwise forked anything that was still maintained (although we've forked plenty of libraries after establishing that the upstream was moribund). Neither of those appears to be documented (specifically, https://governance.openstack.org/tc/reference/licensing.html only specifies licensing requirements for official projects, libraries imported by official projects, and software used by the Infra team). The Infrastructure team has been granted a fair amount of autonomy to determine its operating guidelines, and future plans to separate project hosting further from the OpenStack name (in an attempt to make it more clear that hosting your project in the infrastructure is not an endorsement by OpenStack and doesn't make it "part of OpenStack") make the OpenStack TC governance site a particularly poor choice of venue to document such things. So clearly in the future this will be the responsibility of the Winterscale Infrastructure Council assuming that proposal goes ahead. For now, would it be valuable for the TC to develop some guidelines that will provide the WIC with a solid base it can evolve from once it takes them over, or should we just leave it up to infra's discretion? In addition, I think we should require projects hosted on our infrastructure to agree to other policies: * Adhere to the OpenStack Foundation Code of Conduct. This seems like a reasonable addition to our hosting requirements. * Not misrepresent their relationship to the official OpenStack project or the Foundation. Ideally we'd come up with language that they *can* use to describe their status, such as "hosted on the OpenStack infrastructure". Also a great suggestion. We sort of say that in the "what being an unoffocial project is not" bullet list, but it could use some fleshing out. If we don't have place where this kind of thing is documented already, I'll submit a review adding one. Does anybody have any ideas about a process for ensuring that projects have read and agreed to the terms when we add them? Adding process forcing active confirmation of such rules seems like a lot of unnecessary overhead/red tape/bureaucracy. As it stands, we're working to get rid of active agreement to the ICLA in favor of simply asserting the DCO in commit messages, so I'm not a fan of adding some new agreement people have to directly acknowledge along with associated automation and policing. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TC] [Infra] Terms of service for hosted projects
Jeremy Stanley wrote: On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote: It is my understanding that the infra team will enforce the following conditions when a repo import request is received: * The repo must be licensed under an OSI-approved open source license. That has been our custom, but we should add a statement to this effect in the aforementioned document. * If the repo is a fork of another project, there must be (public) evidence of an attempt to co-ordinate with the upstream first. I don't recall this ever being mandated, though the project-config reviewers do often provide suggestions to project creators such as places in the existing community with which they might consider cooperating/collaborating. Right, that was never a rule (for Stackforge or the current "non-official project hosting" space), and I doubt very much we have enforced it in the past. FWIW we currently host forks of gitdm, gerrit, as well as copies of all sorts of JS code under xstatic-*. That said, I think consulting upstream in case of code copies/forks is a good practice to add in the future. [...] In addition, I think we should require projects hosted on our infrastructure to agree to other policies: * Adhere to the OpenStack Foundation Code of Conduct. This seems like a reasonable addition to our hosting requirements. * Not misrepresent their relationship to the official OpenStack project or the Foundation. Ideally we'd come up with language that they *can* use to describe their status, such as "hosted on the OpenStack infrastructure". Also a great suggestion. We sort of say that in the "what being an unoffocial project is not" bullet list, but it could use some fleshing out. "The OpenStack infrastructure" is likely to be changed in the near future to a more neutral name, but I would keep the "hosted on" language to describe the relationship. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TC] [Infra] Terms of service for hosted projects
On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote: > We allow various open source projects that are not an official > part of OpenStack or necessarily used by OpenStack to be hosted on > OpenStack infrastructure - previously under the 'StackForge' > branding, but now without separate branding. Do we document > anywhere the terms of service under which we offer such hosting? We do so minimally here: https://docs.openstack.org/infra/system-config/unofficial_project_hosting.html It's linked from this section of the Project Creator’s Guide in the Infra Manual: https://docs.openstack.org/infra/manual/creators.html#decide-status-of-your-project But yes, we should probably add some clarity to that document and see about making sure it's linked more prominently. We also maintain some guidelines for reviewers of changes to the openstack-infra/project-config repository, which has a bit to say about new repository creation changes: https://git.openstack.org/cgit/openstack-infra/project-config/tree/REVIEWING.rst > It is my understanding that the infra team will enforce the > following conditions when a repo import request is received: > > * The repo must be licensed under an OSI-approved open source > license. That has been our custom, but we should add a statement to this effect in the aforementioned document. > * If the repo is a fork of another project, there must be (public) > evidence of an attempt to co-ordinate with the upstream first. I don't recall this ever being mandated, though the project-config reviewers do often provide suggestions to project creators such as places in the existing community with which they might consider cooperating/collaborating. > Neither of those appears to be documented (specifically, > https://governance.openstack.org/tc/reference/licensing.html only > specifies licensing requirements for official projects, libraries > imported by official projects, and software used by the Infra > team). The Infrastructure team has been granted a fair amount of autonomy to determine its operating guidelines, and future plans to separate project hosting further from the OpenStack name (in an attempt to make it more clear that hosting your project in the infrastructure is not an endorsement by OpenStack and doesn't make it "part of OpenStack") make the OpenStack TC governance site a particularly poor choice of venue to document such things. > In addition, I think we should require projects hosted on our > infrastructure to agree to other policies: > > * Adhere to the OpenStack Foundation Code of Conduct. This seems like a reasonable addition to our hosting requirements. > * Not misrepresent their relationship to the official OpenStack > project or the Foundation. Ideally we'd come up with language that > they *can* use to describe their status, such as "hosted on the > OpenStack infrastructure". Also a great suggestion. We sort of say that in the "what being an unoffocial project is not" bullet list, but it could use some fleshing out. > If we don't have place where this kind of thing is documented > already, I'll submit a review adding one. Does anybody have any > ideas about a process for ensuring that projects have read and > agreed to the terms when we add them? Adding process forcing active confirmation of such rules seems like a lot of unnecessary overhead/red tape/bureaucracy. As it stands, we're working to get rid of active agreement to the ICLA in favor of simply asserting the DCO in commit messages, so I'm not a fan of adding some new agreement people have to directly acknowledge along with associated automation and policing. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
