Add fields to indicate packager's acceptance of community contributions

[jasontibbitts]

I and plenty of other people have run into an issue where we've modified someone else's package to fix bugs or whatnot and they have been extremely angry that their packages have been molested. It would be super nice to have a way for maintainers who care to indicate the degree to which they are willing to have the community of provenpackagers work on their packages.

I'm trying to work out a simple way to allow maintainers to specify what they'd like done without devolving into bikeshedding about the precision of the options. I'd like to have things like:

• Please feel free to commit and build changes to this package on all branches and push updates as needed.
• Please feel free to commit to rawhide, but ask before pushing to release branches.

Perhaps this would work. Have a number of questions:

• Is it OK for provenpackagers to commit changes to rawhide?
• ... submit new rawhide builds?
• ... commit changes to release branches?
• ... submit new builds in release branches?
• ... submit updates?

And after each, a select box with the following options:

• As you wish. Help is always welcome!
• Please ask first.
• Please don't.

Also add a multiline text field for the maintainer(s) to include additional information, and some boilerplate:

Anyone is always welcome to submit patches via bugzilla.
Please respect the maintainers' packaging style and wishes as indicated in specfile comments.
You broke it, you fix it! Provenpackagers should always take care to test their changes and be prepared to fix any issues which result from them.

[jasontibbitts]

BTW, I believe that the answer to the first two questions should default to "as you wish" and everything should default to "please ask first", but others may have other opinions.

[nonamedotc]

My two cents - This is a fantastic idea, IMHO. +1

[pypingou]

I do like the idea as well, one question about it:

• Who should be allowed to change it? the POC or all the maintainers?

[nonamedotc]

My opinion would be POC (of rawhide) since POC is technically "in charge" of the package.

[pypingou]

My opinion would be POC (of rawhide) since POC is technically "in charge" of the package.

Well we kinda want to stop this idea, the POC is not in charge, she/he is just the point of contact, otherwise she/he just a maintainers like the others. That's the whole idea round the change of terminology

[nonamedotc]

That's true ... This would then mean it's not a question at all, really. Any (co-)maintainer should be able to toggle, no?

[pypingou]

That would be my thoughts, but maybe everyone but me thinks this way :)

[nonamedotc]

That would be my thoughts, but maybe everyone but me thinks this way :)

Thinking more about this - It does make sense for all maintainers would be able to toggle this I guess. As you say, the only difference between POC (and admin) and committers is ability to alter ACLs. Ability to choose to accept others' contributions to a package which one is responsible for (all committers) seems reasonable ...

May be I am mistaken ... :)

[jasontibbitts]

My opinion is that anyone who can change ACLs should be able to change these fields.

[lemenkov]

Love the idea!

Speaking about the issue, I believe the idea of "owning a package" is toxic. I know some motivation behind this attitude, but in this case we should provide a packager additional infrastructure to announce his/her plans.

[Hubbitus]

Brilliant idea indicate it so detailed and for each package!

For most of my package I would like any help and contribution, but just always ask kindly provide breaf declaration of intent. It is not "ask me first", just inform me before doing to give me chance react and provide some information, help, thinks...

So, in some cases maintainer known about own package some details what other do not. F.e. what it can't be updated on particuar reason or it has some side effect and some bug should not be fixed in current release etc... Not all such thinks may be stated in spec comments. Meantime some may be fit into comments in pkgdb.
So, I would suggest also option like "Ask me first, but may proceed after X days" with choose of period. For do not stop thinks when I really busy and even can't handle mail in timed manner.

[mizdebsk]

I support this idea.

Debian has a similar procedure (low threshold NMU) - package maintainers can opt-in to allow other developers to modify some of their packages without all the bureaucracy.