[arch-dev-public] Repo cleanup / Package adoption
Hi, This is yet another repo cleanup package adoption thread. There hasn't been much feedback when I last brought up the subject so let's try to fix this once for all. This is an important issue. The cleanup is mostly done. The current issue is orphaned (make)depends. I'll repeat the process. Go to https://dev.archlinux.org/wiki/Repo%20Cleanup/ There is the list of orphans and the packages that depends on them. The name of the maintainer of the package depending on orphans is also listed so just search for your name. It's as simple as that so it only takes a few minutes. Keep in mind that these orphanes are in the repo because YOUR package depends on them so they need to be maintained as well. There are still orphaned core packages. Of course, anyone is free to adopt any orphans that they wish. Once you adopted some packages, remove them from the list to keep the list up-to-date. You can also post the list of packages you have adopted in this thread and I'll take care of removing them from the wiki list. Either way, please reply in this thread to confirm that you went through the list. That will give me an idea on how many devs have checked the list. However, it is possible that some of you already have the maximum workload that they can handle so they can't really adopt any or all of their packages' orphaned depends. At least, check the list to see if your packages depends on orphaned packages and let us know. Perhaps someone else, who can add to their current workload, would be willing to adopt some of these orphans especially if they use the package that depends on them. I'm sure we'll be able to split the present orphans workload somehow between us. Currently, we just need an idea on the current workload state. In summary, we should ideally get a reply in this thread from every active dev confirming that they went though the wiki list and: a) have adopted all or some of their "assigned" orphans and have modified the list accordingly or b) have adopted all or some of their "assigned" orphans and posted a list here so I can update the wiki and/or c) have adopted none or only some of their "assigned" orphans because of too high workload or other reason. Two other points: I would like to remind everyone that after adding a package in the repo or moving it to another repo, don't forget to adopt it afterwards in the dashboard. I believe that's one reason explaining why several packages are currently orphaned. I haven't updated the wiki list since the last time except a when I happen to stumble on a new orphan so it might be slightly out-of-date compared to the dashboard orphans. When it'll be significantly smaller, I'll update it. Thanks for your cooperation, Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Mon, May 5, 2008 at 8:38 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote: <snip>
I haven't updated the wiki list since the last time except a when I happen to stumble on a new orphan so it might be slightly out-of-date compared to the dashboard orphans. When it'll be significantly smaller, I'll update it.
I grabbed ifenslave in core. Seems easy enough to maintain.
Thanks for your cooperation, Eric
Thanks for your efforts in keeping the motivation to do this. I think this is something that really needs doing. -Dan
On Mon, May 5, 2008 at 9:38 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
a) have adopted all or some of their "assigned" orphans and have modified the list accordingly
I scanned through the list
On Mon, May 5, 2008 at 8:38 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
Hi,
This is yet another repo cleanup package adoption thread. There hasn't been much feedback when I last brought up the subject so let's try to fix this once for all. This is an important issue.
The cleanup is mostly done. The current issue is orphaned (make)depends. I'll repeat the process.
Go to https://dev.archlinux.org/wiki/Repo%20Cleanup/ There is the list of orphans and the packages that depends on them. The name of the maintainer of the package depending on orphans is also listed so just search for your name. It's as simple as that so it only takes a few minutes. Keep in mind that these orphanes are in the repo because YOUR package depends on them so they need to be maintained as well. There are still orphaned core packages. Of course, anyone is free to adopt any orphans that they wish.
Once you adopted some packages, remove them from the list to keep the list up-to-date. You can also post the list of packages you have adopted in this thread and I'll take care of removing them from the wiki list. Either way, please reply in this thread to confirm that you went through the list. That will give me an idea on how many devs have checked the list.
However, it is possible that some of you already have the maximum workload that they can handle so they can't really adopt any or all of their packages' orphaned depends. At least, check the list to see if your packages depends on orphaned packages and let us know. Perhaps someone else, who can add to their current workload, would be willing to adopt some of these orphans especially if they use the package that depends on them. I'm sure we'll be able to split the present orphans workload somehow between us. Currently, we just need an idea on the current workload state.
In summary, we should ideally get a reply in this thread from every active dev confirming that they went though the wiki list and: a) have adopted all or some of their "assigned" orphans and have modified the list accordingly or b) have adopted all or some of their "assigned" orphans and posted a list here so I can update the wiki and/or c) have adopted none or only some of their "assigned" orphans because of too high workload or other reason.
I grabbed: aiksaurus gtkmathview libots They all look like one-offs due to abiword-plugins... and also: librep rep-gtk But I doubt I can pull in much more. Off topic: sqlite2 is on that list along due to python-sqlite-legacy... do you guys think we still need sqlite2? I don't think anything still needs it for backwards compat.
I haven't updated the wiki list since the last time except a when I happen to stumble on a new orphan so it might be slightly out-of-date compared to the dashboard orphans. When it'll be significantly smaller, I'll update it.
I just removed the ones I listed above. Thanks for all the hardwork Eric. Considering you've put the most time into this - do you think we need more package maintainers to handle the load? Or do you think we could more properly distribute what we have among ourselves?
But I doubt I can pull in much more.
Off topic: sqlite2 is on that list along due to python-sqlite-legacy... do you guys think we still need sqlite2? I don't think anything still needs it for backwards compat.
The only packages that depends on sqlite2 and python-pysqlite-legacy are in community so I guess we could remove both from extra.
I haven't updated the wiki list since the last time except a when I happen to stumble on a new orphan so it might be slightly out-of-date compared to the dashboard orphans. When it'll be significantly smaller, I'll update it.
I just removed the ones I listed above.
Thanks for all the hardwork Eric. Considering you've put the most time into this - do you think we need more package maintainers to handle the load? Or do you think we could more properly distribute what we have among ourselves?
I'll need more feedback before knowing if the load is too much. You're the only dev that had stuff to adopt who had replied so far. Dan, who adopted a core orphan, and Travis didn't had any depends to adopt. We'll have to see what the others will say. As for adding new devs to handle the load, it will decrease the workload only if we do it right. If we just bring in a TU, say, and he only move his community packages to extra, that won't decrease the load at all. Ideally, we need to bring someone willing to pick up a significant portion of these orphans. The main difficulty here is that, except for a few standalone packages that we can always move to unsupported, most remaining orphans are libraries which are not particularly interesting to maintain. Perhaps the better way to do this would be for everyone to go through his packages and to come up with a list of packages for which they would be willing to hand over the maintainership to the new dev. The new dev would pick up the package he wants. This will decrease the workload of some devs who might be able to adopt more orphaned depends. It also came up to me that it would be a bad idea to have every dev with a 100% packages workload. If sometime they have less time to devote to Arch, the package maintenance will suffer. Also, if a dev becomes inactive for a period of time, no one else will have the time to take care of his packages. Plus, we'll spend less of our time to do developement work. Probably more devs wouldn't hurt. But if we want the addition of devs to reflect in the workload, we must somehow organize ourselves such that the new dev ends up maintaining packages that are already in the repo (core/extra). Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
core: mpfr is maintained by Jan. I removed it from the list. extra: libraw1394 is maintained by Jan - removed nothing for me to adopt :) -Andy
On Thu, 8 May 2008, Andreas Radke wrote:
core:
mpfr is maintained by Jan. I removed it from the list.
extra:
libraw1394 is maintained by Jan - removed
I removed about a dozen of orphans from the list which already had a mainatiner. There might be other. Just remove them if you see them.
nothing for me to adopt :)
-Andy
How about opera? As you maintain opera-devel, could you also maintain the opera package in extra? If you are planning on removing opera-devel and maintaining opera once 9.50 goes stable, I could take care of opera in the meanwhile if no-one else wants too. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Am Thu, 8 May 2008 18:49:02 -0400 (EDT) schrieb Eric Belanger <belanger@ASTRO.UMontreal.CA>:
On Thu, 8 May 2008, Andreas Radke wrote:
core:
mpfr is maintained by Jan. I removed it from the list.
extra:
libraw1394 is maintained by Jan - removed
I removed about a dozen of orphans from the list which already had a mainatiner. There might be other. Just remove them if you see them.
nothing for me to adopt :)
-Andy
How about opera? As you maintain opera-devel, could you also maintain the opera package in extra? If you are planning on removing opera-devel and maintaining opera once 9.50 goes stable, I could take care of opera in the meanwhile if no-one else wants too.
TomK always updated Opera. He should be the first Dev to take it. Right now I can't menage Opera 9.2x because it runs only i686. Let's wait some time to see if TomK will adopt it. If not count me in as the new maintainer. -Andy
Hi - gtkglextmm and the depending sharpconstruct can be ditched entirely becuase sharpconstruct is dead (became a module in blender) and gtkglextmm was needed only for it - adopted libpano13 - adopted perl-gtk2-ex-formfactory - did not adopt libdvbpsi4 because I wanna see if vlc 0.9 will depend on it (vlc-0.8.* is a friggin mess anyway) - did not adopt pyxml because it would be my only python package -T
On Thu, 8 May 2008, Tobias Kieslich wrote:
Hi
- gtkglextmm and the depending sharpconstruct can be ditched entirely becuase sharpconstruct is dead (became a module in blender) and gtkglextmm was needed only for it
Roman has adopted sharpconstruct in the last round of adoption. I'll wait for his input before removing sharpconstruct from the repo.
- adopted libpano13 - adopted perl-gtk2-ex-formfactory
removed from the list
- did not adopt libdvbpsi4 because I wanna see if vlc 0.9 will depend on it (vlc-0.8.* is a friggin mess anyway)
You could still adopt it. If it doesn't need to be updated/fixed it involves no work. And if vlc 0.9 doesn't need it, you can just remove it at that point.
- did not adopt pyxml because it would be my only python package
-T
There's a start for everything. ;) Doesn't seem to be much work. I could grab it if noone does. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Hi, I adopted gtk-sharp... Daniel
2008/5/9 Eric Belanger <belanger@astro.umontreal.ca>:
On Thu, 8 May 2008, Tobias Kieslich wrote:
Hi
- gtkglextmm and the depending sharpconstruct can be ditched entirely becuase sharpconstruct is dead (became a module in blender) and gtkglextmm was needed only for it
Roman has adopted sharpconstruct in the last round of adoption. I'll wait for his input before removing sharpconstruct from the repo.
Finally I got to this thread. Sorry for so loong time. Yep, I planned to maintain sharpconstruct at that time, because it seemed to be the only gtk2 application for 3D modelling. I knew it was dead but didn't know it became a plugin for Blender. I don't have much time for pkg maintaining yet, so I cannot so I think it would be ok to just drop it from Extra to Unsupported then (along with its dependency). -- Roman Kyrylych (Роман Кирилич)
On Sat, 31 May 2008, Roman Kyrylych wrote:
2008/5/9 Eric Belanger <belanger@astro.umontreal.ca>:
On Thu, 8 May 2008, Tobias Kieslich wrote:
Hi
- gtkglextmm and the depending sharpconstruct can be ditched entirely becuase sharpconstruct is dead (became a module in blender) and gtkglextmm was needed only for it
Roman has adopted sharpconstruct in the last round of adoption. I'll wait for his input before removing sharpconstruct from the repo.
Finally I got to this thread. Sorry for so loong time. Yep, I planned to maintain sharpconstruct at that time, because it seemed to be the only gtk2 application for 3D modelling. I knew it was dead but didn't know it became a plugin for Blender. I don't have much time for pkg maintaining yet, so I cannot so I think it would be ok to just drop it from Extra to Unsupported then (along with its dependency).
I can't move gtkglextmm to unsupported. I'm getting the famous "You are not allowed to overwrite the gtkglextmm package." error. Aaron (or someone else): can you fix that? Then I'll move both sharpconstruct and gtkglextmm to unsupported. Roman: do you also want me to move cdw to unsupported as well? See FS#6023. Thanks. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
2008/6/1 Eric Belanger <belanger@astro.umontreal.ca>:
I can't move gtkglextmm to unsupported. I'm getting the famous "You are not allowed to overwrite the gtkglextmm package." error.
Aaron (or someone else): can you fix that? Then I'll move both sharpconstruct and gtkglextmm to unsupported.
Roman: do you also want me to move cdw to unsupported as well? See FS#6023.
Yes, please do so. It's not that important package. -- Roman Kyrylych (Роман Кирилич)
Is cdtool part of the list? AFAI can see there is no maintainer listed. Theres a bug report about it http://bugs.archlinux.org/task/10558 but it seems dead and needed only by tcdr which also looks like a dead project. 2 possible candidates for removal? If not, then someone adopt cdtool so i can assign the bug report to him :P Greg
On Sun, 1 Jun 2008, Grigorios Bouzakis wrote:
Is cdtool part of the list? AFAI can see there is no maintainer listed. Theres a bug report about it http://bugs.archlinux.org/task/10558 but it seems dead and needed only by tcdr which also looks like a dead project.
Yes, cdtool is on that list.
2 possible candidates for removal? If not, then someone adopt cdtool so i can assign the bug report to him :P
Damir maintains tcdr so technically he should also maintains cdtool unless the workload would be too much. He haven't answered yet in this thread. He could also decide to orphan tcdr and have both tcdr and cdtool moved to unsupported.
Greg
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Mon, 5 May 2008, Eric Belanger wrote:
Hi,
This is yet another repo cleanup package adoption thread. There hasn't been much feedback when I last brought up the subject so let's try to fix this once for all. This is an important issue.
The cleanup is mostly done. The current issue is orphaned (make)depends. I'll repeat the process.
Go to https://dev.archlinux.org/wiki/Repo%20Cleanup/ There is the list of orphans and the packages that depends on them. The name of the maintainer of the package depending on orphans is also listed so just search for your name. It's as simple as that so it only takes a few minutes. Keep in mind that these orphanes are in the repo because YOUR package depends on them so they need to be maintained as well. There are still orphaned core packages. Of course, anyone is free to adopt any orphans that they wish.
Once you adopted some packages, remove them from the list to keep the list up-to-date. You can also post the list of packages you have adopted in this thread and I'll take care of removing them from the wiki list. Either way, please reply in this thread to confirm that you went through the list. That will give me an idea on how many devs have checked the list.
However, it is possible that some of you already have the maximum workload that they can handle so they can't really adopt any or all of their packages' orphaned depends. At least, check the list to see if your packages depends on orphaned packages and let us know. Perhaps someone else, who can add to their current workload, would be willing to adopt some of these orphans especially if they use the package that depends on them. I'm sure we'll be able to split the present orphans workload somehow between us. Currently, we just need an idea on the current workload state.
In summary, we should ideally get a reply in this thread from every active dev confirming that they went though the wiki list and: a) have adopted all or some of their "assigned" orphans and have modified the list accordingly or b) have adopted all or some of their "assigned" orphans and posted a list here so I can update the wiki and/or c) have adopted none or only some of their "assigned" orphans because of too high workload or other reason.
Two other points:
I would like to remind everyone that after adding a package in the repo or moving it to another repo, don't forget to adopt it afterwards in the dashboard. I believe that's one reason explaining why several packages are currently orphaned.
I haven't updated the wiki list since the last time except a when I happen to stumble on a new orphan so it might be slightly out-of-date compared to the dashboard orphans. When it'll be significantly smaller, I'll update it.
Thanks for your cooperation, Eric
There are still several devs who haven't answered yet. This is a gentle reminder. Thanks, Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Mon, May 26, 2008 at 11:51 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
There are still several devs who haven't answered yet. This is a gentle reminder.
I'm just looking through the list now and I see some programs that, at least in my opinion we should drop if nobody is actively maintaining them: azureus, dvdbackup, handbrake, nicotine, and d4x. All of these are pretty fringe apps except for maybe azureus, which is just plain slow and buggy (or was the last time I used it). I don't know much about the deps/makedeps, but if any of them are tied to the other fringe apps we should look at removing them entirely as well...just my two cents of course. I admit though I was a bit surprised to see we had 4267 packages in extra--even if half of those are x86_64 that's a still a shedload of maintenance.
On Mon, May 26, 2008 at 12:46 PM, Thayer Williams <thayer@archlinux.org> wrote:
On Mon, May 26, 2008 at 11:51 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
There are still several devs who haven't answered yet. This is a gentle reminder.
I'm just looking through the list now and I see some programs that, at least in my opinion we should drop if nobody is actively maintaining them: azureus, dvdbackup, handbrake, nicotine, and d4x. All of these are pretty fringe apps except for maybe azureus, which is just plain slow and buggy (or was the last time I used it).
I use azureus somewhat regularly. I don't know if I'm up to maintaining it though. Didn't simo used to do it?
On Mon, 26 May 2008, Jason Chu wrote:
On Mon, May 26, 2008 at 12:46 PM, Thayer Williams <thayer@archlinux.org> wrote:
On Mon, May 26, 2008 at 11:51 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
There are still several devs who haven't answered yet. This is a gentle reminder.
I'm just looking through the list now and I see some programs that, at least in my opinion we should drop if nobody is actively maintaining them: azureus, dvdbackup, handbrake, nicotine, and d4x. All of these are pretty fringe apps except for maybe azureus, which is just plain slow and buggy (or was the last time I used it).
I use azureus somewhat regularly. I don't know if I'm up to maintaining it though. Didn't simo used to do it?
Yes, he was and he was interested in taking it back. He might have changed his minf though. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Mon, 26 May 2008, Thayer Williams wrote:
On Mon, May 26, 2008 at 11:51 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
There are still several devs who haven't answered yet. This is a gentle reminder.
I'm just looking through the list now and I see some programs that, at least in my opinion we should drop if nobody is actively maintaining them: azureus, dvdbackup, handbrake, nicotine, and d4x. All of these are pretty fringe apps except for maybe azureus, which is just plain slow and buggy (or was the last time I used it).
I don't know much about the deps/makedeps, but if any of them are tied to the other fringe apps we should look at removing them entirely as well...just my two cents of course. I admit though I was a bit surprised to see we had 4267 packages in extra--even if half of those are x86_64 that's a still a shedload of maintenance.
I don't think these fringe apps have a lot of depends specific to them. If so, we'll remove them when we'll remove the apps. Currently, I want to focus on the depends for stuff that we want to keep. When the list will be smaller, I'll update it with the current orphans in the dashboard. There might be other orphaned fringes apps or packages we want to keep not in the wiki list. Also, I've noticed that some packages got orphaned when we updated the web site: sudo, abs, exiv2, initscripts, etc. Check if it happened to your packages. Otherwise, I'll add them to the wiki list when I'll update it. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Mon, May 26, 2008 at 4:12 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Mon, 26 May 2008, Thayer Williams wrote:
On Mon, May 26, 2008 at 11:51 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
There are still several devs who haven't answered yet. This is a gentle reminder.
I'm just looking through the list now and I see some programs that, at least in my opinion we should drop if nobody is actively maintaining them: azureus, dvdbackup, handbrake, nicotine, and d4x. All of these are pretty fringe apps except for maybe azureus, which is just plain slow and buggy (or was the last time I used it).
I don't know much about the deps/makedeps, but if any of them are tied to the other fringe apps we should look at removing them entirely as well...just my two cents of course. I admit though I was a bit surprised to see we had 4267 packages in extra--even if half of those are x86_64 that's a still a shedload of maintenance.
I don't think these fringe apps have a lot of depends specific to them. If so, we'll remove them when we'll remove the apps. Currently, I want to focus on the depends for stuff that we want to keep. When the list will be smaller, I'll update it with the current orphans in the dashboard. There might be other orphaned fringes apps or packages we want to keep not in the wiki list.
Also, I've noticed that some packages got orphaned when we updated the web site: sudo, abs, exiv2, initscripts, etc. Check if it happened to your packages. Otherwise, I'll add them to the wiki list when I'll update it.
You sure that's not just the testing repo? At the very least I know abs == travis and initscripts == thomas, correct?
On Tue, May 27, 2008 at 2:44 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Mon, May 26, 2008 at 4:12 PM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
On Mon, 26 May 2008, Thayer Williams wrote:
On Mon, May 26, 2008 at 11:51 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
There are still several devs who haven't answered yet. This is a gentle reminder.
I'm just looking through the list now and I see some programs that, at least in my opinion we should drop if nobody is actively maintaining them: azureus, dvdbackup, handbrake, nicotine, and d4x. All of these are pretty fringe apps except for maybe azureus, which is just plain slow and buggy (or was the last time I used it).
I don't know much about the deps/makedeps, but if any of them are tied to the other fringe apps we should look at removing them entirely as well...just my two cents of course. I admit though I was a bit surprised to see we had 4267 packages in extra--even if half of those are x86_64 that's a still a shedload of maintenance.
I don't think these fringe apps have a lot of depends specific to them. If so, we'll remove them when we'll remove the apps. Currently, I want to focus on the depends for stuff that we want to keep. When the list will be smaller, I'll update it with the current orphans in the dashboard. There might be other orphaned fringes apps or packages we want to keep not in the wiki list.
Also, I've noticed that some packages got orphaned when we updated the web site: sudo, abs, exiv2, initscripts, etc. Check if it happened to your packages. Otherwise, I'll add them to the wiki list when I'll update it.
You sure that's not just the testing repo? At the very least I know abs == travis and initscripts == thomas, correct?
Definitely not testing - I did lose ABS as a maintainer. Re-adopted.
On Mon, 2008-05-26 at 17:12 -0400, Eric Belanger wrote:
On Mon, 26 May 2008, Thayer Williams wrote:
On Mon, May 26, 2008 at 11:51 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
There are still several devs who haven't answered yet. This is a gentle reminder.
I've looked at the list: perl-extutils-cbuilder and perl-module-build can be dropped since they are provided by perl itself now. I'll grab perl-mime-types. Cheers, k
-- K. Piche <kpiche@rogers.com>
On Fri, 30 May 2008, K. Piche wrote:
On Mon, 2008-05-26 at 17:12 -0400, Eric Belanger wrote:
On Mon, 26 May 2008, Thayer Williams wrote:
On Mon, May 26, 2008 at 11:51 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
There are still several devs who haven't answered yet. This is a gentle reminder.
I've looked at the list: perl-extutils-cbuilder and perl-module-build can be dropped since they are provided by perl itself now.
I removed them both from repo. To do that, I used the db-remove script but it left the PKGBUILD in trunk. I can understand why it did that, but should I manually remove them completely from svn?
I'll grab perl-mime-types.
perl-mime-types is still orphaned. Please remember to adopt it via the dashboard. Thanks, Eric
Cheers, k
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On Mon, 26 May 2008, Eric Belanger wrote:
On Mon, 26 May 2008, Thayer Williams wrote:
On Mon, May 26, 2008 at 11:51 AM, Eric Belanger <belanger@astro.umontreal.ca> wrote:
There are still several devs who haven't answered yet. This is a gentle reminder.
I'm just looking through the list now and I see some programs that, at least in my opinion we should drop if nobody is actively maintaining them: azureus, dvdbackup, handbrake, nicotine, and d4x. All of these are pretty fringe apps except for maybe azureus, which is just plain slow and buggy (or was the last time I used it).
I don't know much about the deps/makedeps, but if any of them are tied to the other fringe apps we should look at removing them entirely as well...just my two cents of course. I admit though I was a bit surprised to see we had 4267 packages in extra--even if half of those are x86_64 that's a still a shedload of maintenance.
I don't think these fringe apps have a lot of depends specific to them. If so, we'll remove them when we'll remove the apps. Currently, I want to focus on the depends for stuff that we want to keep. When the list will be smaller, I'll update it with the current orphans in the dashboard. There might be other orphaned fringes apps or packages we want to keep not in the wiki list.
I've updated the wiki list. It should reflect the current orphan state.
Also, I've noticed that some packages got orphaned when we updated the web site: sudo, abs, exiv2, initscripts, etc. Check if it happened to your packages. Otherwise, I'll add them to the wiki list when I'll update it.
Please check the updated wiki list. In case when I suspected the above issue happened, I added "orphaned accidentally?" in the comment and the name of the last maintainer. Please correct if these are incorrect. Also, now that we have multi-architecture support in the dashboard, we could have a different maintainer for each architecture. However, as we are currently dealing with orphans for which we've been trying to find maintainers over the last few months, please adopt the package for both architecture so we can get over this adoption process . Don't worry if you can't build for x86_64, someone else will do it when it'll be needed. Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
participants (12)
-
Aaron Griffin
-
Andreas Radke
-
Dan McGee
-
Daniel Isenmann
-
Eric Belanger
-
Grigorios Bouzakis
-
Jason Chu
-
K. Piche
-
Roman Kyrylych
-
Thayer Williams
-
Tobias Kieslich
-
Travis Willard