Project Talk:Proxy Maintainers

From Gentoo Wiki
Jump to:navigation Jump to:search
Note
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using ~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC)
: A reply [[User:Sally|Sally]] 14:03, 5 November 2024 (UTC)
:: Your reply ~~~~

Video of Talk about Proxy

Talk status
This discussion is still ongoing.

How and where should we link this, can we embed it in our wiki? https://www.youtube.com/watch?v=2fvIICPZBcw --Jonas Stein (talk) 00:45, 18 December 2017 (UTC)

The maintainer wanted list is no longer available

Talk status
This discussion is done as of November 13, 2017‎.

$ portageq --obsolete would give that list. should be edited. --Ervin.peters (talk) 13:36, 12 November 2017 (UTC)

Thank you. I have added the command. The maintaining team is informed about the broken server script. --Jonas Stein (talk) 16:56, 13 November 2017 (UTC)

Choice of tool to make commits

Talk status
This discussion is still ongoing as of February 8, 2016‎.

1) "repoman full -x" MUST return clean for files that were modified. This means that if an older version of an ebuild uses a banned EAPI that should not matter as long as the new ebuild which is committed is fine. The -x is for checking xml files too if any of those were modified. This means that a commit may be made with git instead of with repoman, provided that it complies with the above.

2) "repoman commit" is RECOMMEND, because it is the recommended means for committing a package as per the Devmanual, it automatically runs "repoman full" before a commit (obviating the need to remember to run it), and amongst other things, re-generates the Manifest file if necessary. The non preferred method of submission is by "git commit" which in some instances is a necessity.

Sometimes how to fix a repoman error is not always obvious. If there are any questions about errors we will of course help with the goal of getting the output to pass and ensuring good QA for the submission.

Rough draft of additional policies

Talk status
This discussion is done as of November 13, 2017‎.

The following policy changes pending RFC and are for Ian Delaney (idella4) :

== Policy for designation of maintainer ==

If the maintainer is inactive and bug of the package has input from other users, the users actively contributing may be offered the option of becoming a co-maintainer without consultation of the actual maintainer. Because a maintainer's absence may be transitory:

* Substituting a maintainer requires confirmation of notice of withdrawal by the maintainer, or
* beyond a timeout period of one month and at the discretion of the supervising developer of the project.

If the maintainer returns to re-affirm their wish to pursue the package, sanity need prevail; they can be re-assigned with apt negotiation.

== Policy for authority to commit ==

This policy implements a priority approach to ascertain who may commit a proxied user's contribution and accounts for the current possible scenarios. The fora currently used now include:

* The list of orphaned packages commonly labelled maintainer-wanted.
* Regular packages dropped by a developer picked up by user maintainers.
* Patches submitted via the new Gentoo GitHub mirror system.

The first priority is given to members of the project, second to developers with established knowledge in the field of the category of the package. Since the project hosts a full scope of packages, negotiations between developers is taken as an 'understood' and required approach in determining authority. Commits by 'non member' developers without contact with members of the project is discouraged and falls short of respecting the set processes / operations of the project.
  
With regard to the newly established Gentoo's GitHub mirror, this policy states that:

* Those developers need first prompt the project's members, via IRC or the alias, offering the option of committing.
* Once this proves fruitless, developers of the GitHub mirror are free to commit the pull request on behalf of the user.
* Recommended timeout period, 1 week and up to the discretion of the developers.

== Policy for retention of ebuilds ==

The proxied maintainer is to be given opportunity, in discussion with a proxy developer, to select which ebuilds should be declared redundant and removed or retained from portage. If user maintainer does not do so, the proxy developer is entitled to remove old versions, upon commit, at his / her discretion in order to keep the tree clean.

github PR list links are broken

Talk status
This discussion is done.

Just FYI, github links at the bottom of the Proxy Maintainers page are partially broken: all of them have a trailing "|", which makes all the queries return nothing.

thank you. Fixed. --Jonas Stein (talk) 18:17, 13 August 2018 (UTC)
Thank you for trying!
It didn't solve the problem though.
Looks like, there should be no "|" between the link and the text: [https://mediawiki.org MediaWiki].
  • new packages -- [https://github.com/gentoo/gentoo/pulls?utf8=✓&q=is%3Apr+is%3Aopen+label%3A%22new+package%22 new packages]
  • self-maintained -- [https://github.com/gentoo/gentoo/pulls?utf8=✓&q=is%3Apr+is%3Aopen+label%3Aself-maintained self-maintained]
  • maintainer-needed -- [https://github.com/gentoo/gentoo/pulls?utf8=✓&q=is%3Apr+is%3Aopen+label%3Amaintainer-needed maintainer-needed]
Ups thanks again. --Jonas Stein (talk) 17:57, 14 August 2018 (UTC)
I'm really sorry to talk about this again, but after your fix
  • "new packages" -- leads to all open PRs, not just with label "new package";
  • self-maintained -- leads to both open and closed PRs with label "self-maintained", not just to open ones;
  • maintainer-needed -- leads to both open and closed PRs with label "maintainer-needed", not just to open ones.
The links I posted above are correct though. --Ahippo (talk) 03:15, 15 August 2018 (UTC)

Project Lead amendment

Talk status
This discussion is still ongoing as of 29th June 2020.

The "bad boss" should properly be the "big bad boss", see https://en.wikipedia.org/wiki/Big_Bad_Wolf .
-- veremit (talk) 20:46, 29 June 2020 (UTC)