Hi Ricardo, sorry for the lengthy reply. I had the feeling being more verbose was required. On Mon, 26. Nov 10:54 Ricardo Mones <mones@debian.org> wrote: > Hi Markus, > > On Sun, Nov 25, 2012 at 01:27:31AM +0100, Markus Koschany wrote: > > On Sat, 24. Nov 12:18 Ricardo Mones <mones@debian.org> wrote: > > > On Sat, Nov 24, 2012 at 08:50:04AM +0100, Markus Koschany wrote: > > [..] > > > > Sounds good. But now i'm wondering, why not making the next step and > > > > remove packages automatically which have been orphaned for more than > > > > two years and also have a low popcon value for example? If not much > > > > feedback gathering is required this could be an automatism at the > > > > beginning of each release cycle. > > > > > > AFAIK, low popcon + certain amount of time orphaned alone are not enough > > > reasons to remove a package from the archive. They are used as a hints to > > > help removal when real causes exist, which are mainly RC bugs. > > > > In fact i have never found an absolute list of criteria which should > > apply to removal requests. Indeed it seems everyone uses common > > sense and is convinced to do the right thing and i like this keep it > > simple approach. If you search for > > > > RoQA; orphaned, low popcon > > > > you will find various removal requests by the QA-Team alleging an > > orphaned package and a low popcon are adequate reasons. > > > > All the games in question won't see any improvements in the future because > > upstream has been dead since 1998 in some cases. > > That those requests existed doesn't justify they were correct, anyway > from what I've briefly seen most of them also add the "dead upstream" > factor you're also adding here for free. I talked about O + low popcon only. I see you would like to discuss whether the sole factors "orphaned and low popcon" are justified reasons to remove a package automatically from the archive. Let's be more specific. I intend to adopt LGeneral, a strategy game, and i have prepared a complete overhaul of the package. [1] The game has been orphaned since 2008. In 2009 it received the usual QA injection, a homepage field, a watch file, a debhelper bump and a new Standards Version. That was the first update since 2004. Now lintian was happy. But nobody saw that the package had been shipped non-free files from a proprietary game since its initial release in 2001. (#691451) In 2011 the QA team eventually requested the removal of lgc-pg which is a requirement to convert non-free game data to LGeneral's native file format. [2] Finally someone did the right thing but unfortunately he missed the opportunity to remove LGeneral because he didn't see the connection between both packages. Besides being completely outdated, despite the fact upstream was still active, now it wasn't even possible for gamers to aquire data to play the game anyway. (#690683) I'm sure this package would have been released with wheezy because there were no automatisms in place which were desperately needed because humans didn't care. Nobody even bothered to file RC bugs. This is a paragon why sane automatisms are a good thing. A developer who acts in good faith and wants to bring an orphaned package in shape again cannot always assess whether the orphaned package in question might possibly contain security or legal implications or is just unusable. Taking only care of lintian warning isn't sufficient, packages need a maintainer who cares about them. Now you might think your "Gandalf theory" turned out be right. :) I like this kind of thought, that there is a value in everything, but software packages are not human beings. Everyone can reintroduce them, he or she just needs to care and there are a lot of other packages i and everyone else could have been working on. Nevertheless LGeneral isn't a minigame like the games this thread is all about. > > Apart from that you should also take into account that the technical > > quality of a package isn't the only crucial factor. Especially games > > attract people by their gameplay, looks and fun factor. It's no > > advertisement for Debian and free software in general if you ship games > > which look outdated even compared to games from the 90ies. > > You seem unaware of the people which like retro games, or the possibility > of studying sources, or even the historic value. We're not selling anything, > why should we care about those commercial factors? If somebody don't like > a game just don't install it. No, actually i'm one of these people who care most about games and especially retro games. I'm blogging about them and i even started a small vserver project which hosts only free software multiplayer games. [3] You might guess which OS i'm using. I also want to preserve *good quality* games or retro games like etw. Yes, it has bugs, but it is also the only retro football game in the archive. Here i'd like to invest time but not for each and every minigame many of whom Debian has often duplicate packages. There is no sentimental or scientific value in them. Besides gameplay and fun factor don't be just commercial factors, ask some real gamers about it. :) > > I'm sure this kind of "soft criteria" also applies to other software > > apart from games. > > Sure, those highly subjective criterias are powerful. Why not, for example, > remove all Athena widgets based stuff? They look ugly, don't you think? I can only talk about things which i have tested myself. [..] > > I agree popcon isn't the tool of last resort but it's a good indicator > > especially if you compare the results with Ubuntu's popcon. > > Don't see how comparing two flawed numbers can produce a better hint > for removal. Could work for not removing though, in the unlikely case > that Ubuntu's popcon is not low but Debian's is very low. Both could also indicate the same low popcon. I consider everything under 20 to be very low. [..] > > But we gain time and resources. Time that could be spent to focus on other > > more important packages, time to not have to deal with bugs or security > > issues anymore or to write documentation, > > time to guide new contributors and to review their ITAs or even ITPs. > > There are a lot of people who request sponsorship but can't find a > > sponsor because he or she is busy fixing bugs in stepbill.app to continue > > promoting the bogeyman Bill Gates. > > Are you supposing that if they run out of QA packages they are going to > focus on what you want? > Sorry to inform you, but people doesn't work that way. > Like someone said “Welcome to the desert of the real” ;-) No, i'm often idealistic but in this case i'm using simple math. If an indicator for quality is the quotient of maintainers per package you can either increase the number of maintainers or reduce the number of packages to increase the value. I don't want to stop anybody from working on things they like, i just think channeling resources serves the greater good better. :-) [..] > > Jester was easy, indeed. But other packages can be more difficult. I > > also think that the universal OS will benefit from less unmaintained > > packages. > > Again, being maintained by QA team doesn't mean unmaintained. Please. Please see my remarks above. > > > “Many in the archive deserve removal. And some out deserve being packaged. > > > Can you package them? Then do not be too eager to deal out removals in > > > judgement. For even the very wise cannot see all ends.” > > > > > > Well, maybe wasn't talking about packages, anyway... > > > > Nice quote, i see your point. I can't admittedly resurrect people, but > > everyone can reintroduce packages. ;) > > No, only DDs can. And you have to make a very good case to convince a DD > to reintroduce a package which has already been removed from the archive. > So, in practical terms, removal of such packages equals to death for them. I think everybody can. You need someone who cares about a package, she needs to prepare a policy compliant package and act on objections. The duty of a DD is to check the quality and press the upload button. If nobody cares to upload the package this could be an indicator of the package's relevance or maybe that the whole world has turned against you. :( Regards, Markus [1] http://bugs.debian.org/465942 [2] http://bugs.debian.org/465943 [3] http://linuxiuvat.de
Attachment:
signature.asc
Description: Digital signature