Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
El sáb, 06-06-2020 a las 15:09 -0400, Aaron Bauman escribió: > On Sat, Jun 06, 2020 at 02:50:31PM -0400, Aaron Bauman wrote: > > All, the graphics project has now been disbanded. > > > > All packages have been reassigned to maintainer-needed. Bugs will be > > reassigned soon. > > > > Here are a list of the packages that are now up for grabs: > > > > dev-cpp/pngpp > > To expound on this, the graphics project has a quite a few bugs assigned > to them (169). A few packages have co-maintainers, but these are still > reflected in the metadata as required. > > If anyone else has time to address the bugs or wants to take the package > over please do. > > If you hit a package with a co-maintainer then my apologies. > I think this is the list of completely unmaintained packages now (indeed most of them, around 100) :) dev-cpp/pngpp media-gfx/apng2gif media-gfx/apngasm media-gfx/apngdis media-gfx/apngopt media-gfx/autopano-sift-C media-gfx/cellwriter media-gfx/chafa media-gfx/cptutils media-gfx/darktable media-gfx/dcraw media-gfx/duhdraw media-gfx/enblend media-gfx/exact-image media-gfx/exif media-gfx/fim media-gfx/fr0st media-gfx/gif2apng media-gfx/gif2png media-gfx/gifsicle media-gfx/gimageview media-gfx/gmic media-gfx/gnofract4d media-gfx/graphicsmagick media-gfx/grub-splashes media-gfx/gtkimageview media-gfx/hugin media-gfx/icon-slicer media-gfx/igal media-gfx/imagemagick media-gfx/jhead media-gfx/jigl media-gfx/jpeginfo media-gfx/jpegoptim media-gfx/jpegpixi media-gfx/libimagequant media-gfx/luminance-hdr media-gfx/mandelbulber media-gfx/metapixel media-gfx/mscgen media-gfx/nvidia-cg-toolkit media-gfx/openclipart media-gfx/panini media-gfx/pdf2svg media-gfx/png2ico media-gfx/pngcheck media-gfx/pngcrush media-gfx/pngquant media-gfx/pngrewrite media-gfx/povtree media-gfx/pqiv media-gfx/pqstego media-gfx/qiv media-gfx/qvv media-gfx/raw-thumbnailer media-gfx/rotoscope media-gfx/scantailor-advanced media-gfx/scour media-gfx/sfftobmp media-gfx/sxiv media-gfx/tintii media-gfx/tuxpaint-stamps media-gfx/tuxpaint media-gfx/ufraw media-gfx/uniconvertor media-gfx/wkhtmltopdf media-gfx/xli media-gfx/xloadimage media-gfx/xzgv media-libs/cimg media-libs/esdl media-libs/flickcurl media-libs/gd media-libs/giblib media-libs/giflib media-libs/imlib media-libs/jbigkit media-libs/jpeg media-libs/lensfun media-libs/libexif-gtk media-libs/libexif media-libs/libfpx media-libs/libheif media-libs/libicns media-libs/libjpeg-turbo media-libs/libmng media-libs/libpano13 media-libs/libpgf media-libs/libpqstego media-libs/libraw media-libs/netpbm media-libs/opencolorio media-libs/openimageio media-libs/openjpeg media-libs/pnglite media-libs/stimg media-libs/tiff media-libs/urt virtual/imagemagick-tools virtual/jpeg-compat virtual/jpeg x11-misc/gromit x11-misc/shutter signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
вс, 7 июн. 2020 г. в 09:10, Pacho Ramos : > > > I think this is the list of completely unmaintained packages now (indeed most > of > them, around 100) :) > > x11-misc/shutter I'm updating this one right now
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On Sat, Jun 6, 2020 at 7:49 PM Jonas Stein wrote: > > our concept of "Projects" (Herds in the past) maintaining packages has > several problems. You might want to search the list archives as many of the issues you've raised have been discussed extensively. There was never a complete push to fix things, but most project removals/etc have been along the lines of what has been discussed. While tangential, I'll point out that there have been similar discussions around appropriate uses of eclasses and there are some loose parallels for when eclasses make sense. > * Many projects are too heterogeneous > Projects should only maintain either > a) many similar packages such as libraries (like Perl, Python) or > b) very few strong correlated packages (like KDE, Kernel, Xfce) > > It makes no sense to group packages by usage as in > Science, Games, Theology, Sound, Netmon, Video, Electronics... ...graphics... This is the gist of the outcome of previous discussions. Projects make sense when developers actually work TOGETHER to maintain things. Nobody who works on qt is going to just upgrade one component of qt without talking to the other maintainers. It makes sense for those packages to be managed by a project. Historically a lot of projects worked more like "tags" as an alternative way of grouping packages other than categories. While tags are a great idea projects are a terrible way to implement them. > I think we should first find a consent about the following questions > before someone deletes projects. In general I'm a fan of announcing things like this BEFORE doing them. However, I don't think they need pre-approval when they make sense. If anything we haven't been doing it often enough. I don't see any point in bringing back graphics though - if somebody who actually intends to lead such a project wants to speak up on that they should certainly do so, but it sounds like it is just a vestige of an old herd that probably never worked as an actual team. People reading the thread shouldn't think that this has anything to do with the importance of the individual packages. This is purely about how devs are organized around them. Some of what you wrote was more about our larger meta-structure and how devs maintain packages in general. That has also been discussed quite a bit, like having a core group of devs who don't maintain any individual packages and all they do is QA pull requests from a much larger pool of individuals who do care about packages. There are a lot of pros and cons to that and I won't rehash the previous discussions here. That isn't to discourage anybody from doing so - I mainly just want to point out that this stuff is in the archives. -- Rich
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On Sun, 7 Jun 2020 06:43:19 -0400 Rich Freeman wrote: > Historically a lot of projects worked more like "tags" as an > alternative way of grouping packages other than categories. While > tags are a great idea projects are a terrible way to implement them. I was thinking perhaps instead of "group membership" oriented things, we could instead have a "developer proficiency" oriented system. Developers could choose skills from a defined list (like projects, but finely grained) Maybe with some WOT based proficiency rating thing. Then maybe the project system becomes used mostly for "primary ownership" of well maintained sets of things with great team structure, and the proficiency system becomes a defacto fallback for everything else. Packages are tagged with the sort of skills required to maintain them effectively, and people who have registered with said proficiencies get CC'd into the bug (somehow) and similar things. Like, for instance, when a package uses perl stuff, but isn't inherently owned by perl@, I still care, but registering that I care is tricky. And then potentially packages with above "good maintainer-ship" could indicate some sort of maintainer-ship grant to "people with proficiency > X in Y". Yes, I'm likely over-thinking everything here too much, but I suspect somebody could get some inspiration from something here :) pgpGDBplJU7XL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On 6/7/20 2:28 AM, Joonas Niilola wrote: > > On 6/6/20 10:11 PM, Aisha Tammy wrote: >> On 6/6/20 2:50 PM, Aaron Bauman wrote: >>> All, the graphics project has now been disbanded. >>> >> Is it weird to ask what happened? >> >> It seems like a lot of the packages listed here should be and are >> very popular :O >> >> Aisha >> > Hi, > > floppym's response sums it up. > > https://archives.gentoo.org/gentoo-dev/message/c0b5e5e1ab4e0ed77725d4366a5232be > > jstein started a new thread about this subject, > > https://archives.gentoo.org/gentoo-dev/message/f9fae5f9583e73e6d4dbf4fc521dd559 > Indeed, thanks a lot. I should have anticipated that there would be further discussion on this, before prematurely asking simple question >.< Nonetheless, an interesting situation. I never knew too much about projects. Aisha > -- juippis > > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On 07/06/2020 03.43, Aaron Bauman wrote: > On Sun, Jun 07, 2020 at 01:49:28AM +0200, Jonas Stein wrote: > I will happily revert my change on the graphics project Wiki [..] Glad to read your offer. Yes, please do so. I think it would hurt the Gentoo project if single developers delete projects - without without informing the project members - without prior discussion (on gentoo-dev for example), - without vote/consent - without an organized shutdown (reassign bugs, archive things...). However we should continue to find a general solution for the problems discussed in this thread and find a general consent. Thank you. -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On Sun, Jun 7, 2020 at 2:14 PM Jonas Stein wrote: > > On 07/06/2020 03.43, Aaron Bauman wrote: > > On Sun, Jun 07, 2020 at 01:49:28AM +0200, Jonas Stein wrote: > > > I will happily revert my change on the graphics project Wiki [..] > > Glad to read your offer. Yes, please do so. > > I think it would hurt the Gentoo project if single developers delete > projects > > - without without informing the project members > - without prior discussion (on gentoo-dev for example), > - without vote/consent > - without an organized shutdown (reassign bugs, archive things...). > > However we should continue to find a general solution for the problems > discussed in this thread and find a general consent. While I get what you're saying, I think it would also be helpful if we just let people who feel they are actually impacted by changes like this speak up for themselves, instead of assuming that they must exist and that it is our duty to speak up for them. Are you, directly, impacted in any negative way by this change? If so it would probably be helpful if you just explained the issue. This really seems like a fairly uneventful change. I do think it is better to pre-announce changes. However, I suspect that most of the fuss is because a lot of people assume that a change like this must have some kind of big impact, and for whatever reason all the people who are being harmed by it are just afraid to speak up so we must do so on their behalf. I say this as somebody who used to raise a lot more hypothetical objections to changes in the past. I've since learned that it is easy to over-react, and that when others are actually impacted by a change they will tend to speak up. I'm pretty sure in this case there was an organized shutdown - I doubt they just removed the project without reassigning packages or bugs. They were effectively already assigned to nobody as it was, since the project was inactive. I guess my point is that while this probably could be done in a better way, I think it is likely to end up happening either way, so all undoing it is going to do is send a lot of people two more rounds of bugspam at best. Or, it will result in one more round of bugspam and then these packages continue to be unmaintained because nobody is going to bother doing all the steps you're suggesting to get rid of it in the future. Easier to just leave the dead project around and let users wonder why nobody pays attention to the bugs they open. -- Rich
[gentoo-dev] Thank you & Vote for the next Bugday (2020-07-04)
Hi, the Bugday had a nice revival on 2020-06-06. Over the time there were several people, who worked on the fine Bug selection. And we had good discussions about package testing and the bugs. Support was provided by experienced Gentoo users and developers. A big "thank you" to everyone who joined. We had a great time and I learned a lot too. You (literally everybody) can vote for the topics of the next Bugday. https://dudle.inf.tu-dresden.de/Bugday_2020-07-04/ Stay informed on: https://wiki.gentoo.org/wiki/Bugday -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On 6/7/20 9:14 PM, Jonas Stein wrote:
>
> Glad to read your offer. Yes, please do so.
>
> I think it would hurt the Gentoo project if single developers delete
> projects
>
> - without without informing the project members
> - without prior discussion (on gentoo-dev for example),
> - without vote/consent
> - without an organized shutdown (reassign bugs, archive things...).
>
> However we should continue to find a general solution for the problems
> discussed in this thread and find a general consent.
>
> Thank you.
>
The "voting" and "discussion" happened in #gentoo-dev IRC channel. Every
participant was unhappy with the state of graphics project, and even
after pinging the project, no members responded. This "discussion" has
been ongoing for a while now. While I agree the outcome wasn't clean, in
my eyes attempts to contact project has been made.
Now for the future, I wouldn't mind having a "last rite: XYV Project" or
similar e-mail sent to gentoo-dev{-announce} before action to ebuilds is
taken, so the project members/lead has one final chance to stop it.
Maybe this even encourages us to go through some of the more inactive
projects currently?
-- juippis
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Looking for a co-maintainer: games-fps/gzdoom
I am looking for a co-maintainer for the games-fps/gzdoom package. GZDoom version 4.4.0 was just released and GZDoom has been refactored to move its audio code to a new external library called ZMusic: https://bugs.gentoo.org/727448 A games-fps/gzdoom-4.4.0 version bump will require the introduction of a new zmusic ebuild. Since GZDoom is one of the larger DOOM source ports, I figure it'll be good to have more than one person looking after these packages. If anyone is interested in helping out, please let me know. Thanks, William Breathitt Gray signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
> Now for the future, I wouldn't mind having a "last rite: XYV Project" or
> similar e-mail sent to gentoo-dev{-announce} before action to ebuilds is
> taken, so the project members/lead has one final chance to stop it.
Good plan.
--
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, qa, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
> Project Graphics was now deleted Inofficially a graphics@ maintainership of a package meant "fix the bugs yourself" for quite some time already. So I doubt the current state got worse via the removal of the project. That said, this is actually for a subset of the packages one of the cases where a project would really make sense. We have a lot of central libraries here that are used by many other software. libpng, jpeg, tiff, ... These are definitely worth a team of maintainers. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: net-misc/charm
# Aaron Bauman (2020-06-07) # py2 only. dead upstream. m-n. rdep. # Masked for removal in 15 days net-misc/charm -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] Last rites: sys-cluster/polysh
# Aaron Bauman (2020-06-07) # py2 only. dead upstream. m-n. rdep. # Masked for removal in 15 days sys-cluster/polysh -- Cheers, Aaron signature.asc Description: PGP signature
[gentoo-dev] net-p2p/nicotine+: No maintainer, depends on dev-python/pygtk
Package has been slow to port away from pygtk [1] and python2 and is one of the last remaining blockers. [2] Meanwhile, upstream actually managed to port to gtk3 and recently merged that work to master. [3] A new release is imminent [4] so now is the time to start work on an ebuild. If you are using this package, consider stepping up as maintainer *now*. Otherwise, last-rites and removal from tree will happen soon. [1] https://bugs.gentoo.org/708162 [2] https://bugs.gentoo.org/706462 [3] https://github.com/Nicotine-Plus/nicotine-plus/pull/106 [4] https://github.com/Nicotine-Plus/nicotine-plus/issues/99 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
200607 Pacho Ramos wrote: > I think this is the list of completely unmaintained packages now, > indeed most of them, around 100. -- extract from list -- > media-gfx/imagemagick : 200516 > media-libs/giflib : 200312 > media-libs/libjpeg-turbo : 200328 > media-libs/openjpeg : 200328 > virtual/jpeg : 200606 There have been upgrades of all these in recent months : dates when I upgraded on my desktop system are added (the last yesterday). Surely, that means someone is maintaining them. Perhaps the culprits could own up (smile). As a long-time user, I find it disturbing that a huge list of packages should suddenly be declared unmaintained, esp as some of them -- eg above -- are likely needed by most users. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatcadotinterdotnet
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
> On 8 Jun 2020, at 00:22, Philip Webb wrote: > > 200607 Pacho Ramos wrote: >> I think this is the list of completely unmaintained packages now, >> indeed most of them, around 100. > > -- extract from list -- > >> media-gfx/imagemagick : 200516 >> media-libs/giflib : 200312 >> media-libs/libjpeg-turbo : 200328 >> media-libs/openjpeg : 200328 >> virtual/jpeg : 200606 > > There have been upgrades of all these in recent months : > dates when I upgraded on my desktop system are added (the last yesterday). Basically all of these get done by us in security@ because they tend to have vulnerabilities and they are core packages. > Surely, that means someone is maintaining them. > Perhaps the culprits could own up (smile). Maybe. If nobody else does, I will, but it’s easier if someone with +w does for now. > > As a long-time user, I find it disturbing > that a huge list of packages should suddenly be declared unmaintained, > esp as some of them -- eg above -- are likely needed by most users. They’re declared to not have a named maintainer — I promise you, they are not going anywhere, even though this appears concerning. With graphics@, it was an “open secret” that they were unmaintained, now it’s clear that anyone is welcome to help. I hope this helps reassure you a bit — the gist is, they’re not going anywhere, and nobody would let these packages leave the tree. This is essentially just making the formalities reflect reality — to be clear we’re welcome to touch these packages and help. > > -- > ,, > SUPPORT ___//___, Philip Webb > ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto > TRANSIT`-O--O---' purslowatcadotinterdotnet > >
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On Sun, Jun 7, 2020 at 7:22 PM Philip Webb wrote: > > 200607 Pacho Ramos wrote: > > I think this is the list of completely unmaintained packages now, > > indeed most of them, around 100. > > -- extract from list -- > > > media-gfx/imagemagick : 200516 > > media-libs/giflib : 200312 > > media-libs/libjpeg-turbo : 200328 > > media-libs/openjpeg : 200328 > > virtual/jpeg : 200606 > > There have been upgrades of all these in recent months : > dates when I upgraded on my desktop system are added (the last yesterday). > Surely, that means someone is maintaining them. > Perhaps the culprits could own up (smile). > > As a long-time user, I find it disturbing > that a huge list of packages should suddenly be declared unmaintained, > esp as some of them -- eg above -- are likely needed by most users. They were not maintained by identified developers before - that is the point. The only thing that is changing is that metadata is being updated to reflect reality. Now these packages will get more notice and developers can set up and maintain them as needed. The packages aren't being removed - just the project. If any of the packages assigned to the graphics projects already had individual maintainers then those would still remain after the project is removed. Put it this way - suppose we created a project called "dummy" with no developers in it, and we assigned that project to all the packages that are maintaner-needed. Would that actually change anything? XML tags in metadata files don't maintain packages - people do. This sort of thing has happened many times in the past. Sometimes it does result in packages getting treecleaned, but mainly when they have other serious issues. Popular packages aren't likely to get removed this way - certainly not something like libjpeg or imagemagick and so on. -- Rich
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-06-07 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2020-06-07 23:59 UTC. Removals: media-plugins/gimp-lensfun 20200601-22:18 asturm 63cf8d6f236 x11-drivers/xf86-input-keyboard20200606-10:57 slashbeast 0e6b1d8cf0d x11-drivers/xf86-input-mouse 20200606-10:57 slashbeast 0e6b1d8cf0d Additions: acct-group/motion 20200604-07:04 juippis8d6281579d9 acct-user/motion 20200604-07:05 juippis1d0f7143e0c app-backup/kup 20200602-14:09 asturm fd92483d159 dev-libs/libucl20200426-16:09 bman effe59a4a91 dev-python/asteval 20200607-10:36 pacho d5712a4e760 dev-python/black 20200602-22:15 chutzpah 17e0e5f755f dev-python/klein 20200601-04:06 dolsen 5e038299cef dev-python/lmfit 20200607-10:38 pacho 474620d5b9d dev-python/python-dotenv 20200603-16:02 sping b0200d1528d dev-python/tubes 20200601-00:54 dolsen 2b487afce49 dev-ruby/sys-uname 20200607-08:34 graaff 9c8c5ead1d7 dev-util/buildbot-badges 20200601-20:30 dolsen 961c3974a74 dev-util/cucumber-cucumber-expressions 20200607-09:06 graaff 7970871b5c0 dev-util/cucumber-tag-expressions 20200607-08:58 graaff 78ffd36be3b gui-apps/lavalauncher 20200518-02:15 bman d9417ccd322 gui-wm/hikari 20200426-16:15 bman 10ac27bddb6 kde-plasma/kwayland-server 20200604-14:21 asturm 9931cc419a3 mail-mta/notqmail 20200521-08:57 mgorny d331eb76b16 sci-libs/volk 20200529-16:02 zerochaos 07401ce1325 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: x11-drivers/xf86-input-keyboard,removed,slashbeast,20200606-10:57,0e6b1d8cf0d x11-drivers/xf86-input-mouse,removed,slashbeast,20200606-10:57,0e6b1d8cf0d media-plugins/gimp-lensfun,removed,asturm,20200601-22:18,63cf8d6f236 Added Packages: dev-python/lmfit,added,pacho,20200607-10:38,474620d5b9d dev-python/asteval,added,pacho,20200607-10:36,d5712a4e760 dev-util/cucumber-cucumber-expressions,added,graaff,20200607-09:06,7970871b5c0 dev-util/cucumber-tag-expressions,added,graaff,20200607-08:58,78ffd36be3b dev-ruby/sys-uname,added,graaff,20200607-08:34,9c8c5ead1d7 gui-apps/lavalauncher,added,bman,20200518-02:15,d9417ccd322 gui-wm/hikari,added,bman,20200426-16:15,10ac27bddb6 dev-libs/libucl,added,bman,20200426-16:09,effe59a4a91 mail-mta/notqmail,added,mgorny,20200521-08:57,d331eb76b16 kde-plasma/kwayland-server,added,asturm,20200604-14:21,9931cc419a3 acct-user/motion,added,juippis,20200604-07:05,1d0f7143e0c acct-group/motion,added,juippis,20200604-07:04,8d6281579d9 dev-python/python-dotenv,added,sping,20200603-16:02,b0200d1528d dev-python/black,added,chutzpah,20200602-22:15,17e0e5f755f app-backup/kup,added,asturm,20200602-14:09,fd92483d159 dev-util/buildbot-badges,added,dolsen,20200601-20:30,961c3974a74 dev-python/klein,added,dolsen,20200601-04:06,5e038299cef dev-python/tubes,added,dolsen,20200601-00:54,2b487afce49 sci-libs/volk,added,zerochaos,20200529-16:02,07401ce1325 Done.
[gentoo-dev] Last rites: php-ext-source-r2.eclass
No ebuilds in the tree use this eclass anymore, since php-ext-source-r3 exists. Removal in ~30 days. Bug #727472. -- juippis signature.asc Description: OpenPGP digital signature
