I think that using `Signed-off-by` for this purpose is really oblique, and in most or all cases it's just going to be the same as the person who made the commit in the first place, which makes it more or less useless informationally speaking. Could there not instead be a clause which indicates that the mere act of submitting the commit is an attestation of its origin and/or agreement with the DCO? On Thu, Jul 17, 2025 at 9:55 AM Brian Stansberry via wildfly-dev < wildfly-dev(a)lists.jboss.org&gt; wrote: > One of the few requirements that Commonhaus puts on its projects is that > they use either a Developer Certificate of Origin or some kind of > Contributor License Agreement system. This is a reasonable requirement and > I believe some projects associated with WildFly are already using a DCO. > > If you're impatient, skip to #3 below... > > A CLA isn't really practical to administer for an organization of our > scope; a DCO is far simpler. > > There are three things we need to do for a good DCO system. > > 1) Add a dco.txt file in each repository. Commonhaus has a jbang script > "policy-panda"[1] that checks for this when run against a GitHub org. > > You may have noticed that a few days ago I spammed 88 repos in the > wildfly and wildfly-extras GH org with PRs to add this file. In case it is > helpful for other orgs, the script is at [2]. > > 2) Add a reference to the DCO in the CONTRIBUTING.md in each repo. This > is also checked by the Commonhaus policy-panda script. > > Narayana has nice text in [3] that I think is appropriate most anywhere. > (Note that the requested license/copyright header says "The Narayana > Authors". For repos in the wildfly and wildfly-extras orgs it would be "The > WildFly Authors".) > > I don't think we should take immediate action on this, i.e. don't > everyone go off and start editing existing files separately. We can make a > plan. FWIW, my jbang script at [2] can also send up modification PRs, so if > we determine that big sets of repos should all use the same file it may be > helpful. > > 3) DCOs involve an attestation from the person submitting that code that > they agree with the DCO. This is typically done via a 'Signed-off-by' > line in the git commit message. This can be done via the -s flag (lower > case) to the git commit command. > > I expect there will be lots of discussion around the logistics of adding > these signoffs! There already are in the brand new zulip thread around > this. Chatters -- please post a summary of the discussion to this thread as > many WF developers are not actively following zulip! > > Note that the git commit flag for a signoff is "-s" NOT "-S" which is a > different thing that triggers gpg signing of your commit. GPG signing is > not an attestation of a DCO etc. > > Rado has kindly created a WFLY issue[5] to track adding of software > enforcement of the signoff requirement. The details of that are another > topic to discuss. > > [1] https://github.com/commonhaus/foundation/tree/main/templates/panda > [2] https://github.com/bstansberry/git-file-adder > [3] https://github.com/jbosstm/narayana/blob/main/CONTRIBUTING.md > [4] > https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-developers/t... > [5] https://issues.redhat.com/browse/WFLY-20791 > > Best regards, > > -- > Brian Stansberry > Architect, JBoss EAP > WildFly Project Lead > He/Him/His > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > Privacy Statement: https://www.redhat.com/en/about/privacy-policy > List Archives: > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... > -- - DML • he/him

On Thu, Jul 17, 2025 at 4:20 PM Brian Stansberry via wildfly-dev < wildfly-dev(a)lists.jboss.org&gt; wrote: > The clause you mention is the CONTRIBUTING.md thing from my point #2, > with the Narayana version I linked being the example. > > I don't see any indication Commonhaus requires the signoff. > https://github.com/commonhaus/foundation/blob/main/templates/README.md > is where their requirements around this subject are discussed. > > More formal discussions of DCOs that I've seen, e.g. > https://osr.finos.org/docs/bok/artifacts/clas-and-dcos, indicate it's > needed. > > Apache uses CLAs so they are not a source of guidance. Eclipse requires > Signed-off-by blocks, which I believe is done to ensure attestation to > complying with Eclipse requirements like this, but signing the required > Eclipse Contributor Agreement itself also requires attesting to the DCO. > https://www.eclipse.org/legal/eca/ > > I can ask around more about this at Commonhaus if needed. I didn't want > to proactively do that if adding this requirement is non-controversial. > Personally I find having to add a Signed-Off by to a commit message really annoying when you find out at the time of submission that your PR is rejected due to lack of this field and yet the project has no clear definition of it's meaning. Good point. Any implementation of this should involve beefing up the

By making a contribution to this project, I certify that With something like: By contributing to this project I certify the following by using a Signed-Off commit > > > On Thu, Jul 17, 2025 at 10:02 AM David Lloyd <david.lloyd(a)redhat.com&gt; > wrote: > >> I think that using `Signed-off-by` for this purpose is really oblique, >> and in most or all cases it's just going to be the same as the person who >> made the commit in the first place, which makes it more or less useless >> informationally speaking. Could there not instead be a clause which >> indicates that the mere act of submitting the commit is an attestation of >> its origin and/or agreement with the DCO? >> >> >> On Thu, Jul 17, 2025 at 9:55 AM Brian Stansberry via wildfly-dev < >> wildfly-dev(a)lists.jboss.org&gt; wrote: >> >>> One of the few requirements that Commonhaus puts on its projects is >>> that they use either a Developer Certificate of Origin or some kind of >>> Contributor License Agreement system. This is a reasonable requirement and >>> I believe some projects associated with WildFly are already using a DCO. >>> >>> If you're impatient, skip to #3 below... >>> >>> A CLA isn't really practical to administer for an organization of our >>> scope; a DCO is far simpler. >>> >>> There are three things we need to do for a good DCO system. >>> >>> 1) Add a dco.txt file in each repository. Commonhaus has a jbang script >>> "policy-panda"[1] that checks for this when run against a GitHub org. >>> >>> You may have noticed that a few days ago I spammed 88 repos in the >>> wildfly and wildfly-extras GH org with PRs to add this file. In case it is >>> helpful for other orgs, the script is at [2]. >>> >>> 2) Add a reference to the DCO in the CONTRIBUTING.md in each repo. This >>> is also checked by the Commonhaus policy-panda script. >>> >>> Narayana has nice text in [3] that I think is appropriate most >>> anywhere. (Note that the requested license/copyright header says "The >>> Narayana Authors". For repos in the wildfly and wildfly-extras orgs it >>> would be "The WildFly Authors".) >>> >>> I don't think we should take immediate action on this, i.e. don't >>> everyone go off and start editing existing files separately. We can make a >>> plan. FWIW, my jbang script at [2] can also send up modification PRs, so if >>> we determine that big sets of repos should all use the same file it may be >>> helpful. >>> >>> 3) DCOs involve an attestation from the person submitting that code >>> that they agree with the DCO. This is typically done via a 'Signed-off-by' >>> line in the git commit message. This can be done via the -s flag (lower >>> case) to the git commit command. >>> >>> I expect there will be lots of discussion around the logistics of >>> adding these signoffs! There already are in the brand new zulip thread >>> around this. Chatters -- please post a summary of the discussion to this >>> thread as many WF developers are not actively following zulip! >>> >>> Note that the git commit flag for a signoff is "-s" NOT "-S" which is a >>> different thing that triggers gpg signing of your commit. GPG signing is >>> not an attestation of a DCO etc. >>> >>> Rado has kindly created a WFLY issue[5] to track adding of software >>> enforcement of the signoff requirement. The details of that are another >>> topic to discuss. >>> >>> [1] https://github.com/commonhaus/foundation/tree/main/templates/panda >>> [2] https://github.com/bstansberry/git-file-adder >>> [3] https://github.com/jbosstm/narayana/blob/main/CONTRIBUTING.md >>> [4] >>> https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-developers/t... >>> [5] https://issues.redhat.com/browse/WFLY-20791 >>> >>> Best regards, >>> >>> -- >>> Brian Stansberry >>> Architect, JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>> List Archives: >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>> >> >> >> -- >> - DML • he/him >> > > > -- > Brian Stansberry > Architect, JBoss EAP > WildFly Project Lead > He/Him/His > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > Privacy Statement: https://www.redhat.com/en/about/privacy-policy > List Archives: > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >

<https://developercertificate.org/>;. The DCO text is available verbatim in the dco.txt <https://github.com/hibernate/hibernate-orm/blob/main/dco.txt> file in the root directory of the ORM repository.

On Thu, 17 Jul 2025 at 16:59, Brian Stansberry via wildfly-dev < wildfly-dev(a)lists.jboss.org&gt; wrote: > > > On Thu, Jul 17, 2025 at 10:37 AM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> On Thu, Jul 17, 2025 at 4:20 PM Brian Stansberry via wildfly-dev < >> wildfly-dev(a)lists.jboss.org&gt; wrote: >> >>> The clause you mention is the CONTRIBUTING.md thing from my point #2, >>> with the Narayana version I linked being the example. >>> >>> I don't see any indication Commonhaus requires the signoff. >>> https://github.com/commonhaus/foundation/blob/main/templates/README.md >>> is where their requirements around this subject are discussed. >>> >>> More formal discussions of DCOs that I've seen, e.g. >>> https://osr.finos.org/docs/bok/artifacts/clas-and-dcos, indicate it's >>> needed. >>> >>> Apache uses CLAs so they are not a source of guidance. Eclipse requires >>> Signed-off-by blocks, which I believe is done to ensure attestation to >>> complying with Eclipse requirements like this, but signing the required >>> Eclipse Contributor Agreement itself also requires attesting to the DCO. >>> https://www.eclipse.org/legal/eca/ >>> >>> I can ask around more about this at Commonhaus if needed. I didn't want >>> to proactively do that if adding this requirement is non-controversial. >>> >> >> Personally I find having to add a Signed-Off by to a commit message >> really annoying when you find out at the time of submission that your PR is >> rejected due to lack of this field and yet the project has no clear >> definition of it's meaning. >> >> Good point. Any implementation of this should involve beefing up the > CONTRIBUTING.md language to make it clear what "Signed-off by" means. > > But, I just now noticed this interesting bit in the Narayana document: > > "(we adopt the "CoreOS method" approach to using the DCO in which there > is no per-commit signoff ceremony)." > > Googling isn't giving me any details on that, other than convincing > sounding but undocumented AI generated stuff, so hopefully Tom or Mike can > give us more details. > Sure, the wording you can find in our CONTRIBUTING.md followed an option that guidelines provided by the Red Hat Open Source Program Office (if anyone is curious what an OSPO does, please consider to take a look at https://www.redhat.com/en/blog/what-does-open-source-program-office-do). Assessing myself more, I would point you to consider the wording "By contributing to this project you agree...". Perhaps this additional insight helps providing an option for other projects to consider? > > IMO in the DCO it should almost be a case of swapping out this line: >> >> By making a contribution to this project, I certify that >> >> With something like: >> >> By contributing to this project I certify the following by using a Signed-Off commit >> >> >> >>> >>> >>> On Thu, Jul 17, 2025 at 10:02 AM David Lloyd <david.lloyd(a)redhat.com&gt; >>> wrote: >>> >>>> I think that using `Signed-off-by` for this purpose is really oblique, >>>> and in most or all cases it's just going to be the same as the person who >>>> made the commit in the first place, which makes it more or less useless >>>> informationally speaking. Could there not instead be a clause which >>>> indicates that the mere act of submitting the commit is an attestation of >>>> its origin and/or agreement with the DCO? >>>> >>>> >>>> On Thu, Jul 17, 2025 at 9:55 AM Brian Stansberry via wildfly-dev < >>>> wildfly-dev(a)lists.jboss.org&gt; wrote: >>>> >>>>> One of the few requirements that Commonhaus puts on its projects is >>>>> that they use either a Developer Certificate of Origin or some kind of >>>>> Contributor License Agreement system. This is a reasonable requirement and >>>>> I believe some projects associated with WildFly are already using a DCO. >>>>> >>>>> If you're impatient, skip to #3 below... >>>>> >>>>> A CLA isn't really practical to administer for an organization of our >>>>> scope; a DCO is far simpler. >>>>> >>>>> There are three things we need to do for a good DCO system. >>>>> >>>>> 1) Add a dco.txt file in each repository. Commonhaus has a jbang >>>>> script "policy-panda"[1] that checks for this when run against a GitHub org. >>>>> >>>>> You may have noticed that a few days ago I spammed 88 repos in the >>>>> wildfly and wildfly-extras GH org with PRs to add this file. In case it is >>>>> helpful for other orgs, the script is at [2]. >>>>> >>>>> 2) Add a reference to the DCO in the CONTRIBUTING.md in each repo. >>>>> This is also checked by the Commonhaus policy-panda script. >>>>> >>>>> Narayana has nice text in [3] that I think is appropriate most >>>>> anywhere. (Note that the requested license/copyright header says "The >>>>> Narayana Authors". For repos in the wildfly and wildfly-extras orgs it >>>>> would be "The WildFly Authors".) >>>>> >>>>> I don't think we should take immediate action on this, i.e. don't >>>>> everyone go off and start editing existing files separately. We can make a >>>>> plan. FWIW, my jbang script at [2] can also send up modification PRs, so if >>>>> we determine that big sets of repos should all use the same file it may be >>>>> helpful. >>>>> >>>>> 3) DCOs involve an attestation from the person submitting that code >>>>> that they agree with the DCO. This is typically done via a 'Signed-off-by' >>>>> line in the git commit message. This can be done via the -s flag (lower >>>>> case) to the git commit command. >>>>> >>>>> I expect there will be lots of discussion around the logistics of >>>>> adding these signoffs! There already are in the brand new zulip thread >>>>> around this. Chatters -- please post a summary of the discussion to this >>>>> thread as many WF developers are not actively following zulip! >>>>> >>>>> Note that the git commit flag for a signoff is "-s" NOT "-S" which is >>>>> a different thing that triggers gpg signing of your commit. GPG signing is >>>>> not an attestation of a DCO etc. >>>>> >>>>> Rado has kindly created a WFLY issue[5] to track adding of software >>>>> enforcement of the signoff requirement. The details of that are another >>>>> topic to discuss. >>>>> >>>>> [1] >>>>> https://github.com/commonhaus/foundation/tree/main/templates/panda >>>>> [2] https://github.com/bstansberry/git-file-adder >>>>> [3] https://github.com/jbosstm/narayana/blob/main/CONTRIBUTING.md >>>>> [4] >>>>> https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-developers/t... >>>>> [5] https://issues.redhat.com/browse/WFLY-20791 >>>>> >>>>> Best regards, >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Architect, JBoss EAP >>>>> WildFly Project Lead >>>>> He/Him/His >>>>> _______________________________________________ >>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>> List Archives: >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>> >>>> >>>> >>>> -- >>>> - DML • he/him >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Architect, JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>> List Archives: >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>> >> > > -- > Brian Stansberry > Architect, JBoss EAP > WildFly Project Lead > He/Him/His > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > Privacy Statement: https://www.redhat.com/en/about/privacy-policy > List Archives: > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... > _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...

Thanks, Tom and Yoann. So, people with professional knowledge of these things (I've now seen the Red Hat OSPO guidelines Tom mentioned; unfortunately not public but quite clear) have indicated that not requiring Signed-off-by and doing things the way Narayana and Hibernate do is ok. Do we want to do signoffs anyway? Personally, I don't. It would be a lot of logistics I think.

On Thu, Jul 24, 2025 at 5:00 AM Yoann Rodiere <yoann(a)hibernate.org&gt; wrote: > Hey, > > What we've been using in the Hibernate repos is this: > > All contributions are subject to the Developer Certificate of Origin >> (DCO) <https://developercertificate.org/>;. The DCO text is available >> verbatim in the dco.txt >> <https://github.com/hibernate/hibernate-orm/blob/main/dco.txt> file in >> the root directory of the ORM repository. >> > > It's in CONTRIBUTING.md: > https://github.com/hibernate/hibernate-orm/blob/50177c5b2efd0bb84a2fc59bf... > > This is in line with the requirements from Commonhaus at > https://github.com/commonhaus/foundation/blob/main/templates/README.md#co... > > Our assumption -- validated by people who *do* have actual knowledge in > copyright laws -- is that this is enough, and that no sign-off is required > as long as this is listed as a requirement for contributing to our projects. > > @Sanne Grinovero <sanne(a)hibernate.org&gt; would probably know the exact > history behind this. Or tell you if I'm wrong :) But I know we've discussed > it again recently when moving to Commonhaus, and it was confirmed to me > that this was enough, without requiring anything more from contributors. > > Yoann Rodière > Hibernate team > > > On Thu, Jul 24, 2025 at 10:40 AM Tom Jenkinson via wildfly-dev < > wildfly-dev(a)lists.jboss.org&gt; wrote: > >> >> >> On Thu, 17 Jul 2025 at 16:59, Brian Stansberry via wildfly-dev < >> wildfly-dev(a)lists.jboss.org&gt; wrote: >> >>> >>> >>> On Thu, Jul 17, 2025 at 10:37 AM Darran Lofthouse < >>> darran.lofthouse(a)jboss.com&gt; wrote: >>> >>>> On Thu, Jul 17, 2025 at 4:20 PM Brian Stansberry via wildfly-dev < >>>> wildfly-dev(a)lists.jboss.org&gt; wrote: >>>> >>>>> The clause you mention is the CONTRIBUTING.md thing from my point #2, >>>>> with the Narayana version I linked being the example. >>>>> >>>>> I don't see any indication Commonhaus requires the signoff. >>>>> https://github.com/commonhaus/foundation/blob/main/templates/README.md >>>>> is where their requirements around this subject are discussed. >>>>> >>>>> More formal discussions of DCOs that I've seen, e.g. >>>>> https://osr.finos.org/docs/bok/artifacts/clas-and-dcos, indicate >>>>> it's needed. >>>>> >>>>> Apache uses CLAs so they are not a source of guidance. Eclipse >>>>> requires Signed-off-by blocks, which I believe is done to ensure >>>>> attestation to complying with Eclipse requirements like this, but signing >>>>> the required Eclipse Contributor Agreement itself also requires attesting >>>>> to the DCO. https://www.eclipse.org/legal/eca/ >>>>> >>>>> I can ask around more about this at Commonhaus if needed. I didn't >>>>> want to proactively do that if adding this requirement is non-controversial. >>>>> >>>> >>>> Personally I find having to add a Signed-Off by to a commit message >>>> really annoying when you find out at the time of submission that your PR is >>>> rejected due to lack of this field and yet the project has no clear >>>> definition of it's meaning. >>>> >>>> Good point. Any implementation of this should involve beefing up the >>> CONTRIBUTING.md language to make it clear what "Signed-off by" means. >>> >>> But, I just now noticed this interesting bit in the Narayana document: >>> >>> "(we adopt the "CoreOS method" approach to using the DCO in which there >>> is no per-commit signoff ceremony)." >>> >>> Googling isn't giving me any details on that, other than convincing >>> sounding but undocumented AI generated stuff, so hopefully Tom or Mike can >>> give us more details. >>> >> >> Sure, the wording you can find in our CONTRIBUTING.md followed an option >> that guidelines provided by the Red Hat Open Source Program Office (if >> anyone is curious what an OSPO does, please consider to take a look at >> https://www.redhat.com/en/blog/what-does-open-source-program-office-do). >> Assessing myself more, I would point you to consider the wording "By >> contributing to this project you agree...". >> >> Perhaps this additional insight helps providing an option for other >> projects to consider? >> >> >>> >>> IMO in the DCO it should almost be a case of swapping out this line: >>>> >>>> By making a contribution to this project, I certify that >>>> >>>> With something like: >>>> >>>> By contributing to this project I certify the following by using a Signed-Off commit >>>> >>>> >>>> >>>>> >>>>> >>>>> On Thu, Jul 17, 2025 at 10:02 AM David Lloyd <david.lloyd(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> I think that using `Signed-off-by` for this purpose is really >>>>>> oblique, and in most or all cases it's just going to be the same as the >>>>>> person who made the commit in the first place, which makes it more or less >>>>>> useless informationally speaking. Could there not instead be a clause which >>>>>> indicates that the mere act of submitting the commit is an attestation of >>>>>> its origin and/or agreement with the DCO? >>>>>> >>>>>> >>>>>> On Thu, Jul 17, 2025 at 9:55 AM Brian Stansberry via wildfly-dev < >>>>>> wildfly-dev(a)lists.jboss.org&gt; wrote: >>>>>> >>>>>>> One of the few requirements that Commonhaus puts on its projects is >>>>>>> that they use either a Developer Certificate of Origin or some kind of >>>>>>> Contributor License Agreement system. This is a reasonable requirement and >>>>>>> I believe some projects associated with WildFly are already using a DCO. >>>>>>> >>>>>>> If you're impatient, skip to #3 below... >>>>>>> >>>>>>> A CLA isn't really practical to administer for an organization of >>>>>>> our scope; a DCO is far simpler. >>>>>>> >>>>>>> There are three things we need to do for a good DCO system. >>>>>>> >>>>>>> 1) Add a dco.txt file in each repository. Commonhaus has a jbang >>>>>>> script "policy-panda"[1] that checks for this when run against a GitHub org. >>>>>>> >>>>>>> You may have noticed that a few days ago I spammed 88 repos in the >>>>>>> wildfly and wildfly-extras GH org with PRs to add this file. In case it is >>>>>>> helpful for other orgs, the script is at [2]. >>>>>>> >>>>>>> 2) Add a reference to the DCO in the CONTRIBUTING.md in each repo. >>>>>>> This is also checked by the Commonhaus policy-panda script. >>>>>>> >>>>>>> Narayana has nice text in [3] that I think is appropriate most >>>>>>> anywhere. (Note that the requested license/copyright header says "The >>>>>>> Narayana Authors". For repos in the wildfly and wildfly-extras orgs it >>>>>>> would be "The WildFly Authors".) >>>>>>> >>>>>>> I don't think we should take immediate action on this, i.e. don't >>>>>>> everyone go off and start editing existing files separately. We can make a >>>>>>> plan. FWIW, my jbang script at [2] can also send up modification PRs, so if >>>>>>> we determine that big sets of repos should all use the same file it may be >>>>>>> helpful. >>>>>>> >>>>>>> 3) DCOs involve an attestation from the person submitting that code >>>>>>> that they agree with the DCO. This is typically done via a 'Signed-off-by' >>>>>>> line in the git commit message. This can be done via the -s flag (lower >>>>>>> case) to the git commit command. >>>>>>> >>>>>>> I expect there will be lots of discussion around the logistics of >>>>>>> adding these signoffs! There already are in the brand new zulip thread >>>>>>> around this. Chatters -- please post a summary of the discussion to this >>>>>>> thread as many WF developers are not actively following zulip! >>>>>>> >>>>>>> Note that the git commit flag for a signoff is "-s" NOT "-S" which >>>>>>> is a different thing that triggers gpg signing of your commit. GPG signing >>>>>>> is not an attestation of a DCO etc. >>>>>>> >>>>>>> Rado has kindly created a WFLY issue[5] to track adding of software >>>>>>> enforcement of the signoff requirement. The details of that are another >>>>>>> topic to discuss. >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/commonhaus/foundation/tree/main/templates/panda >>>>>>> [2] https://github.com/bstansberry/git-file-adder >>>>>>> [3] https://github.com/jbosstm/narayana/blob/main/CONTRIBUTING.md >>>>>>> [4] >>>>>>> https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-developers/t... >>>>>>> [5] https://issues.redhat.com/browse/WFLY-20791 >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> -- >>>>>>> Brian Stansberry >>>>>>> Architect, JBoss EAP >>>>>>> WildFly Project Lead >>>>>>> He/Him/His >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>>>> List Archives: >>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> - DML • he/him >>>>>> >>>>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Architect, JBoss EAP >>>>> WildFly Project Lead >>>>> He/Him/His >>>>> _______________________________________________ >>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>>>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>>>> List Archives: >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>> >>>> >>> >>> -- >>> Brian Stansberry >>> Architect, JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>> List Archives: >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>> >> _______________________________________________ >> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >> List Archives: >> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >> > -- Brian Stansberry Architect, JBoss EAP WildFly Project Lead He/Him/His _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...

On Thu, Jul 24, 2025 at 2:21 PM Brian Stansberry via wildfly-dev < wildfly-dev(a)lists.jboss.org&gt; wrote: > Thanks, Tom and Yoann. > > So, people with professional knowledge of these things (I've now seen the > Red Hat OSPO guidelines Tom mentioned; unfortunately not public but quite > clear) have indicated that not requiring Signed-off-by and doing things the > way Narayana and Hibernate do is ok. > > Do we want to do signoffs anyway? Personally, I don't. It would be a lot > of logistics I think. > > +1 to "don't want"