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.