Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add fields to indicate packager's acceptance of community contributions #274

Open
jasontibbitts opened this issue Nov 17, 2015 · 12 comments

Comments

Projects
None yet
7 participants
@jasontibbitts
Copy link

commented Nov 17, 2015

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

This comment has been minimized.

Copy link
Author

commented Nov 17, 2015

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

This comment has been minimized.

Copy link

commented Nov 18, 2015

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

@pypingou

This comment has been minimized.

Copy link
Member

commented Nov 18, 2015

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

This comment has been minimized.

Copy link

commented Nov 18, 2015

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

@pypingou

This comment has been minimized.

Copy link
Member

commented Nov 18, 2015

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

This comment has been minimized.

Copy link

commented Nov 18, 2015

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

This comment has been minimized.

Copy link
Member

commented Nov 18, 2015

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

@nonamedotc

This comment has been minimized.

Copy link

commented Nov 18, 2015

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

This comment has been minimized.

Copy link
Author

commented Nov 18, 2015

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

@lemenkov

This comment has been minimized.

Copy link

commented Nov 19, 2015

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

This comment has been minimized.

Copy link

commented Nov 28, 2015

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.

@ralphbean ralphbean added the medium label Jan 11, 2016

@mizdebsk

This comment has been minimized.

Copy link
Member

commented Jan 11, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.