-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sat, 23 Jan 2016 12:12:57 +0100 Patrice Clement <monsie...@gentoo.org> wrote:
> Tuesday 19 Jan 2016 00:44:49, NP-Hardass wrote : > > With all of the unclaimed herds and unclaimed packages within them, > > I started to wonder what will happen after the GLEP 67 transition > > finally comes to fruition. This left me with some concerns and I > > was wondering what the community thinks about them, and some > > possible solutions. > > > > There is a large number of packages from unclaimed herds that, at > > this time, look like they will not be claimed by developers. This > > will likely result in a huge increase in maintainer-needed packages > > (and subsequent package rot). This isn't to say that some of these > > packages weren't previously in a "maintainer-needed" like state, but > > now, they will explicitly be there. > > > > A possible approach to reducing this is to adopt some new policies. > > > > The first of which is an "adopt-a-package" type program. In > > functionality, this is no different than proxy-maintenance, however, > > this codifies it into an explicit policy whereby users are > > encouraged to step and take over a package. This obviously > > requires a greater developer presence in the proxy-maint project > > (or something similar), but, personally, I think that a stronger > > dev presence in proxy-maint would be better for Gentoo as a whole. > > > > The second policy change would be that maintainer-needed packages > > can have updates by anyone while maintaining the standard "you fix > > it if you break it" policy. This would extend to users as well. > > With the increased ease that users can contribute via git/github, > > they should be encouraged to contribute and have their efforts > > facilitated to ease contributions to whatever packages they desire > > (within the maintainer-needed category). > > > > Similar to the concept of a "bugday," coupled with above, an > > "ebuildday" where users and devs get together so users can learn to > > write ebuilds and for devs to work together to maintain packages > > that usually fall outside their normal workload could prove > > beneficial to the overall health of Gentoo packaging. > > > > Once again, these are just some random musings inspired by recent > > events on the dev ML, and thought it might be worth discussing. > > I've cc'd proxy-maint as a lot of this discussion is likely to > > involve them, and would like them to put in their official opinion > > as well. > > > > > > -- > > NP-Hardass > > More food for thought on the topic of "what do we do with > maintainer-wanted packages". > > NP-Hardass I quite like your idea but what about clearing down the > massive queue of reports assigned to maintainer-wanted first? > > Right now, the number of bug reports assigned to maintainer-wanted > amounts to over 4k: http://tiny.cc/maintainer_wanted > > There's literally a slew of reports we can mark as WONTFIX / OBSOLETE > because, well, some of these bugs are over 10 years old (!) and a lot > of projects have stalled / are dead by now / or the industry has > moved on. It has to be done at some point anyway so better now than > later. And the upside is that it doesn't require ebuild skills or > knowing Gentoo by heart: only clicking links and checking whether > projects are still alive. > > What do you think? > On behalf of the proxy-maintainers project, it is perhaps fitting to reply to this around the time the actual switch is to occur; from the citing of herd to the new versioned projects, and so forth. This topic touches on the potential impact upon the orphaned package list known as maintainer-needed. Patrice has more or less pulled in the associated list of bugs under maintainer-wanted. The two combined boast an awesome tally. In brief, the proxy-maintainer project has had a significant change of face in the last 6 or so months. While it had some momentum as a vehicle in which users can proxy maintain packages and overshadowing sunrise, it almost collapsed into a memory of history at election time when the lead elected to not be nominated for election, then promptly withdrew from the project entirely, no-one nominated anyone else and consequently no-one voted for anyone else in a typical non election. Having accidentally missed the election period, in collaboration with jlec & mrueg, it was endorsed that I took the lead role, and concurrently created the channel #gentoo-proxy-maint. Clearly, this is not common knowledge since some responders to this thread have pointed users at gentoo-dev-help as a source of support, quite unaware of the existence of the channel, let alone the rate of activity it generates, arguably possessing the longest logs of any given day in any gentoo channel since its inception. Such is the state of activity of users discussing gentoo and working ebuilds and pull requests, and various cakes, on a daily basis. The release of the Reviewer's project also give it an automatic boost. While the project was forged on the notion of users picking up packages from the orphaned package list, it has simply added to its 'raison dêtre' by users maintaining new packages to portage under the supervision of the devs of the project. This came into vogue before I joined. What this has done is to generate a need for extended policies given the expanded activities and the permutations that come with them. With regard to this thread, the points that relate are: 1. the impact of the addition of packages to the maintainer-wanted list, 2. the existence of the maintainer-wanted list in its own right 3. The practices and policies in the proxy-maintainers project in its current period 4. The notion of bugday and ebuild day floated and re-cited in the initial thread. 5. Documentation and record / stats keeping performed within the modern day gentoo. The purpose here is to state a stance on behalf of the proxy-maintainers project relative to its place re the above issues / processes. Keeping it brief has already proven nigh on impossible. As much as it urks, in this case I shall have to side with mgorny's 'stance on issue number 1. "this isn't going to be some kind of huge growth. Right now I can count 380 new maintainer-needed packages, from which some will most likely be mapped. I would estimate the final outcome to around 300 packages, maybe less" The notion that the "fallthrough" of around 300 packages has cause some to anticipate a possible flurry of activity upon the proxy-maintainers project since it is the only project designated to deal directly with the orphaned package list. Frankly, mgorny's approach here rings true; it may end up being a big meh. It is merely speculation that the "shuffling come loss" of any distinguishable ownership will cause ripples of activity in the project. Firstly, the project requires devs and users willing to grab the packages and commit changes to the tree. As a broad statement of response, the project is ready and able if the cause arises. If I had not reshaped it to what it is, the list of users and devs of the channel would not exist. The project itself likely would not exist as a recognizable functioning entity. This isn't a case of blowing my own horn, this is merely a summary of a series of observable and recorded events. As the replies have already illustrated, there are many permutations of states possible to this shuffled list. To pre-empt them is frankly foolhardy. 2. The maintainer-wanted list. monsieurp has included this in the mix in a prior reply in this thread. After some inhouse discussion with the most active current key members, it's apparent that some see little value in investing time and effort into culling and, in fact finally directly dealing with, on embarrassingly huge history of inattention and outright shunning by the developer community towards legitimately presented requests by users. Others in fact do. (Horses for courses) While the project has no duty towards dealing with this small mountain, it does represent 'work', under a package manager banner, that can be executed by advanced and willing users, overseered by a developer or two, that also qualifies as legitimate training exercises in the acquisition / development of the skill set required to become a developer. All this is consistent with the overall mission of this project. While neither obliged nor pressured, there are already some users of the member's list who have begun an assault on this formidable and ancient list. 3. With recent policies added to the wiki page of the project, it is adequately equipped to deal with what may spill forth form the switch. The page has had a section added by monsieurp which I edited (mostly for grammar and style), and a link to a new page; Project:Proxy Maintainers/Maintainer Wanted, dealing precisely with the points raised by monsieurp in his (previous) reply. They have a set of criteria with which to make the decisions required to manage the bugs. 4. The bugday is merely an entry in the pages of bugs I have never seen enacted, or organised, and acted upon. Frankly, an ebuild, while a viable idea, sounds like what we do in the channel most days. However, an idea or activity of this type, albeit a repetition of a day in the life of the proxy-maintainers, still makes for a legit addition to what gentoo cam make available to nay users who may attend, assisting in the learning curve that must be trodden by any user, or mentoree, keen to advance their skills. This remains, traditionally, an endemic gap in the fabric that is modern gentoo environment. 5. At the risk of sounding like Patrick, gentoo lacks some forms of documentation pertaining to established proxy maintainers and to forms of stats analysis. In discussions, points were raised regarding the gathering of stats data re packages' tally of downloads and instances of emerging into a gentoo system. Most of the desired stats appear to lack any form of tools available to gather and report data that would prove helpful in evaluating packages of either the m-w or m-n lists. The topic of recruitment and recruiting are tied, but imo, quite disparate. - -- kind regards Ian Delaney -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1 iQJ8BAEBCgBmBQJWpOAmXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCRUI4RjAxNzRGRTVDMjI4RjcxNkRFNzIw QzQzN0NCNDcxRTlEMzNBAAoJEAxDfLRx6dM6ECAQAJnDqx7EBbAa8tl5/A9HiF6t 8ajaf9NqJYYQZApNjaa6SY60/EP7a5trYW7QOGxE8EvRpNDYlxRIzTZZmb2uCsER GOgovqYAelaPhwBBGYGGU91i4wKtJ+U+ujrFRLb3eE9Bsv3NcOOzhRIn6zWr9KuB OBkwYHi37xc8WUsJKR7rBjmOx+OG5Izs5z4gRF3BZVV3+MHgH2zb6Q4W4u13lhOg BtYBqN5/Y52bzFKgcX0tYeTt9xoYI/Zk1szwX1M3rYizKmYGZwh/lCmUO7PA+Q8V ZoRhHAaZIgm4eRScnoQBWWm8aStw9nFFRIWcxRKVIx5aEYODWcFz6JEO/zKseNqD LH/67ssc1/y4JIw0MbZ1YyFrouATs0TnSgbJzKAiMLSJsjHI+EEjdKyEhlRVLVHk FjM3RzyGTcZWfzFBWXKdYgfCR2GzJZ4Q3rYMZKZARW2t1om1pRJo6JK66JHDErVA GQiQpEsGQgjOFmp1DyhEJpziBIuTL6l8TwaLamqvJeWhgFEzuaqqfv+Lh/5H8jFB ghRYkeGiqX6p1pPV+bBYNfxrAlpNeNRoyyKt8Jupuwnr63QA1QevBko/2ngfNgGl 5OQBJhcjs+BJ4KlS/3X1v5rKqSK/eLf1Yy87CY52+2P2rEabfKjB8JHxzu6E7O7/ XaQEesz4Egp1ZOrfMJC+ =sq9P -----END PGP SIGNATURE-----
