[gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

Hello,

Please reply with any topics you wish to be discussed during the next council meeting (this coming Sunday, 2022-05-08).

Current agenda:
1. Roll call
2. Open bugs with council participation
3. Open floor

Apologies for the delay in sending out.

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Arthur Zamarin]

[-- Attachment #1.1: Type: text/plain, Size: 2720 bytes --]

On 03/05/2022 07.39, Sam James wrote:
> Hello,
> 
> Please reply with any topics you wish to be discussed during the next council meeting (this coming Sunday, 2022-05-08).
> 

Hi

After some discussions on #gentoo-qa IRC with ulm, sam and floppym, we
were discussing off by default auto signoff for pkgdev.


Background:

pkgdev [1] is a tool that was supposed to replace repoman by previous
discussions. Currently, I'm the main maintainer of it, and I'm working
on improving it, implementing feature request, etc.
By default, when you use `pkgdev commit`, it automatically adds the arg
`--signoff` to the `git commit` command, so the S-o-b is added, to
comply with GLEP 76 [2].


Change Explanation:

ulm had suggested to turn off *by default* the passing of `--signoff`.
The user need to make a conscious decision that he agrees to sign the
commits.
If I look at the GLEP text, the line "The purpose of the certificate is
to declare that the contribution can be modified and redistributed in
accordance with the project's license" makes me to agree with this idea,
on the legal front.

Of course I don't want to break the flow of all pkgdev user's. Around 2
weeks ago, I have added support for pkgdev configuration support (still
not released), so any user can set "his" defaults. In this case, the
user will need to set it in config file at ~/.config/pkgdev/pkgdev.conf

  [gentoo]
  commit.signoff = true

And all future calls to `pkgdev commit` will auto add the signoff (as
current flow), otherwise the user can selectively pass the arg to
command, as `pkgdev commit --signoff`.


Council Intervention:

This change will force all users to change their flow, or set the
configuration part - meaning it is a semi-breaking change. I have
received some private messages on IRC of requests to not do this change
(they requested to remain anonymous). On the other hand, I agree with
ulm on the necessity of this change to be more "legal".
I see pkgdev as shared Gentoo project and tool, so I don't want to make
disruptive decision for all of us. I want unity.

Therefore I'm asking for a council vote on "change the default signoff
state when committing on an unconfigured system to be turned off". Of
course you can use better wording for this :)

I will take on myself implementing it, and on release of next pkgdev
version, I will send an announcement message of this breaking change, so
most users will be notified, and can easily select wanted flow.


[1] https://github.com/pkgcore/pkgdev
[2] https://www.gentoo.org/glep/glep-0076.html

-- 
Arthur Zamarin
arthurzam@gentoo.org
Gentoo Linux developer (Python, Arch Teams, GURU, pkgcore stack)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Rich Freeman]

On Thu, May 5, 2022 at 3:27 PM Arthur Zamarin <arthurzam@gentoo.org> wrote:
>
> This change will force all users to change their flow, or set the
> configuration part - meaning it is a semi-breaking change.

Since commits to the main repo without the signoff are going to get
rejected anyway, if we decide to go ahead with this would it make
sense to just have it abort by default if the config item or command
line parameter is missing?

If a user really wants to commit without a signoff they can just set
--signoff=false, or the equivalent in the config file.

Basically make it a non-optional parameter.

If this weren't a gentoo-specific tool I'd see making the behavior
more generic, but it seems like if the default is going to be to help
the user to shoot themself in the foot, it should just output some
kind of explanation of the need for the parameter and what it means if
it is not provided.

-- 
Rich

Re: [gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Mike Gilbert]

On Thu, May 5, 2022 at 4:08 PM Rich Freeman <rich0@gentoo.org> wrote:
>
> On Thu, May 5, 2022 at 3:27 PM Arthur Zamarin <arthurzam@gentoo.org> wrote:
> >
> > This change will force all users to change their flow, or set the
> > configuration part - meaning it is a semi-breaking change.
>
> Since commits to the main repo without the signoff are going to get
> rejected anyway, if we decide to go ahead with this would it make
> sense to just have it abort by default if the config item or command
> line parameter is missing?
>
> If a user really wants to commit without a signoff they can just set
> --signoff=false, or the equivalent in the config file.
>
> Basically make it a non-optional parameter.
>
> If this weren't a gentoo-specific tool I'd see making the behavior
> more generic, but it seems like if the default is going to be to help
> the user to shoot themself in the foot, it should just output some
> kind of explanation of the need for the parameter and what it means if
> it is not provided.

I think aborting is a bit extreme.

Maybe a warning for a few releases, similar to how git has handled
behavior changes.

Re: [gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Rich Freeman]

On Thu, May 5, 2022 at 10:07 PM Mike Gilbert <floppym@gentoo.org> wrote:
>
> On Thu, May 5, 2022 at 4:08 PM Rich Freeman <rich0@gentoo.org> wrote:
> >
> > Since commits to the main repo without the signoff are going to get
> > rejected anyway, if we decide to go ahead with this would it make
> > sense to just have it abort by default if the config item or command
> > line parameter is missing?
> >
> > If a user really wants to commit without a signoff they can just set
> > --signoff=false, or the equivalent in the config file.
> >
> > Basically make it a non-optional parameter.
> >
>
> I think aborting is a bit extreme.
>

It isn't meant to be punitive - it is meant to save the user rework.

I get that you can also use it in overlays, but I suspect that 95% of
people who commit to overlays also end up committing or submitting PRs
to the Gentoo repo, and that means that missing a signoff is going to
cause them issues.

So you can either let the operation go through with a 95% chance that
it is wrong, then inform the user there is a 95% chance that they did
the wrong thing and they should go rebase their commit and fix it.  Or
you can just abort and ask them to confirm they really want to do what
they're doing by adding a simple command line option, which just
involves hitting the up arrow and adding it.

> Maybe a warning for a few releases, similar to how git has handled
> behavior changes.

That's great for the existing Gentoo dev who is transitioning, but not
the new contributor or dev who ends up finding out about their mistake
when they go to push a commit, or have their PR rejected for a missing
signoff.

This issue seems likely to hit almost every new user of the tool for
the indefinite future.  It is much easier to avoid the error than to
go back and fix it.

It isn't going to bother me personally one way or another since I
already added this to my config file, so it doesn't matter to me all
that much.  It just seems like not defaulting to shooting yourself in
the foot is a reasonable choice.  If the user wants to add the option
and turn it off then they can still do commits without signoffs if
they don't want to contaminate their repo with harmless headers.

Besides, the whole argument for making this not default to signing
everything is that signing should be a deliberate choice.  In that
case, shouldn't NOT signing ALSO be a deliberate choice?

-- 
Rich

Re: [gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

>>>>> On Fri, 06 May 2022, Rich Freeman wrote:

> Besides, the whole argument for making this not default to signing
> everything is that signing should be a deliberate choice.  In that
> case, shouldn't NOT signing ALSO be a deliberate choice?

The argument goes like this [1]:
"Adding the Signed-off-by trailer to a patch should be a conscious act
and means that you certify you have the rights to submit this work under
the same open source license."

It's not a conscious act if a tool does it automatically in its default
configuration.

We also have a precedent: Repoman required setting the SIGNED_OFF_BY
variable in make.conf before it would add the line to commits. I'm not
aware of any major problems caused by this.

Ulrich

[1] https://git-scm.com/docs/git-config#Documentation/git-config.txt-formatsignOff

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Rich Freeman]

On Fri, May 6, 2022 at 9:27 AM Ulrich Mueller <ulm@gentoo.org> wrote:
>
> The argument goes like this [1]:
> "Adding the Signed-off-by trailer to a patch should be a conscious act
> and means that you certify you have the rights to submit this work under
> the same open source license."
>
> It's not a conscious act if a tool does it automatically in its default
> configuration.

Sure, but nobody in this thread has suggested that it ought to.  This
is about what happens if the user fails to perform the conscious act,
not whether it ought to be conscious.

> We also have a precedent: Repoman required setting the SIGNED_OFF_BY
> variable in make.conf before it would add the line to commits. I'm not
> aware of any major problems caused by this.

There is zero chance of any major problems being caused with any of
the options being discussed here so far (aborting, warning, or no
warning when not signing a commit).  If people want to paint the bike
shed bright green with dark purple polka dots, be my guest.  :)

-- 
Rich

Re: [gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Fri, May 06, 2022 at 03:27:51PM +0200, Ulrich Mueller wrote:
> We also have a precedent: Repoman required setting the SIGNED_OFF_BY
> variable in make.conf before it would add the line to commits. I'm not
> aware of any major problems caused by this.

As far as I'm concern, the only thing I want is a way to enable it
without passing --signoff every time or having to make alias/wrappers.
Can be a opt-in, I just need a way to actually opt-in.

Wish I could just add it to my .git/config per-tree as needed
and pkgdev wouldn't even have to worry about it, but that's a
not a thing with git without aliases :(

If pkgdev ever gets a configuration file, guess it could eventually
have per-repos configuration too (+be used for opt-in). Was never
fond of repoman using make.conf / env vars.

-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Ionen Wolkens]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

On Fri, May 06, 2022 at 10:13:48AM -0400, Ionen Wolkens wrote:
> If pkgdev ever gets a configuration file, guess it could eventually
> have per-repos configuration too (+be used for opt-in). Was never
> fond of repoman using make.conf / env vars.

Actually, I missed that this is already implemented in live
version :)

-- 
ionen

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Arthur Zamarin]

[-- Attachment #1.1: Type: text/plain, Size: 1441 bytes --]

On 05/05/2022 23.08, Rich Freeman wrote:
> On Thu, May 5, 2022 at 3:27 PM Arthur Zamarin <arthurzam@gentoo.org> wrote:
>>
>> This change will force all users to change their flow, or set the
>> configuration part - meaning it is a semi-breaking change.
> 
> Since commits to the main repo without the signoff are going to get
> rejected anyway, if we decide to go ahead with this would it make
> sense to just have it abort by default if the config item or command
> line parameter is missing?
> 
> If a user really wants to commit without a signoff they can just set
> --signoff=false, or the equivalent in the config file.
> 
> Basically make it a non-optional parameter.

Just a small addition. Sign-off is a "must" only for gentoo repo.
Overlays and other sources can have other policies. Meaning there is
value for having it an optional argument.

> If this weren't a gentoo-specific tool I'd see making the behavior
> more generic, but it seems like if the default is going to be to help
> the user to shoot themself in the foot, it should just output some
> kind of explanation of the need for the parameter and what it means if
> it is not provided.

But I do like the idea of showing a warning if gentoo repo is detected
and without signoff, with short explanation how to add or configure it.

-- 
Arthur Zamarin
arthurzam@gentoo.org
Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Call for agenda items for upcoming council meeting (2022-05-08)

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]



> On 6 May 2022, at 07:30, Arthur Zamarin <arthurzam@gentoo.org> wrote:
> 
> On 05/05/2022 23.08, Rich Freeman wrote:
>> On Thu, May 5, 2022 at 3:27 PM Arthur Zamarin <arthurzam@gentoo.org> wrote:
>>> 
>>> This change will force all users to change their flow, or set the
>>> configuration part - meaning it is a semi-breaking change.
>> 
>> Since commits to the main repo without the signoff are going to get
>> rejected anyway, if we decide to go ahead with this would it make
>> sense to just have it abort by default if the config item or command
>> line parameter is missing?
>> 
>> If a user really wants to commit without a signoff they can just set
>> --signoff=false, or the equivalent in the config file.
>> 
>> Basically make it a non-optional parameter.
> 
> Just a small addition. Sign-off is a "must" only for gentoo repo.
> Overlays and other sources can have other policies. Meaning there is
> value for having it an optional argument.
> 
>> If this weren't a gentoo-specific tool I'd see making the behavior
>> more generic, but it seems like if the default is going to be to help
>> the user to shoot themself in the foot, it should just output some
>> kind of explanation of the need for the parameter and what it means if
>> it is not provided.
> 
> But I do like the idea of showing a warning if gentoo repo is detected
> and without signoff, with short explanation how to add or configure it.
> 

I think I get both sides here and while I don't think it's ideal, I need to
keep aside any reservations or hesitations I may have with the DCO model,
as it's not the topic at hand.

I think a decent compromise is a news item, warning on first use of some sort (news item
kind of accomplishes this, but pkg_postinst maybe), and updated
documentation. The config option to enable it is needed but that's already there
so it works for me.

Next step is to try figure out a way to make the contribution experience easier
for users by not forcing them to use PGP (or making errors from gpg more visible
in pkgdev commit). repoman suffered from the same issue where you'd write a commit
message then it'd bail out.

Thank you for reaching out and asking the community. I think you're handling
the responsibility of maintenance well, and thank you for the work!

> --
> Arthur Zamarin
> arthurzam@gentoo.org
> Gentoo Linux developer (Python, Arch Teams, pkgcore stack, GURU)

Best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]