Re: solving the network-manager-in-gnome problem (was Re: Re: duplicates in the archive)
Recommends is wrong for metapackages because it gets upgrades very wrong. This is why it is used very marginally. Couldn't this get fixed if Depends: network-manager-gnome (= 0.9.4) was replaced with Recommends: network-manager-gnome Breaks: network-manager-gnome ( 0.9.4) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5006b641.6090...@greffrath.com
Re: duplicates in the archive
Josselin Mouette writes (Re: duplicates in the archive): Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : What's wrong with Recommends: in that case? It seems to perfectly match the makes life easier for common but not universal use-case XXX scenario you describe. Recommends is wrong for metapackages because it gets upgrades very wrong. This is why it is used very marginally. Could you please explain this in more detail in the specific case of gnome-core and network-manager ? I'm not sure I understand the problem. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20487.16739.688176.814...@chiark.greenend.org.uk
Re: duplicates in the archive
Ian Jackson writes (Re: duplicates in the archive): Josselin Mouette writes (Re: duplicates in the archive): Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : What's wrong with Recommends: in that case? It seems to perfectly match the makes life easier for common but not universal use-case XXX scenario you describe. Recommends is wrong for metapackages because it gets upgrades very wrong. This is why it is used very marginally. Could you please explain this in more detail in the specific case of gnome-core and network-manager ? I'm not sure I understand the problem. In particular I've just read the message from Adam Borowski replying to you, which I will bounce to the TC list. Is Adam wrong ? Thanks, Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20487.16823.624317.28...@chiark.greenend.org.uk
Re: duplicates in the archive
Félix Arreola Rodríguez fgatuno@gmail.com writes: But, ignoring the a desktop works fine without n-m thing, n-m makes more, much more easy connecting to wifi networks, espeacially for laptops. I suggest make Laptop task depend on n-m, in this way, n-m don't get installed on desktop systems, just on laptop systems. What's wrong with Recommends: in that case? It seems to perfectly match the makes life easier for common but not universal use-case XXX scenario you describe. A hard package-dependency in a case like this, when there isn't actually any hard functional dependency, and there are issues with the depended-upon package, are decidedly user-unfriendly. [Yeah, the various desktops tend to abuse hard-dependencies in a lot of other ways, but ... in most cases this just results in bloat. NM is a bit worse than that.] -Miles -- Brain, n. An apparatus with which we think we think. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vest3i6@catnip.gol.com
Re: N-M: Depends-Recommends (was: Re: duplicates in the archive)
On Mon, Jul 09, 2012 at 11:13:16PM +0200, Adam Borowski wrote: and also, as Philipp Kern noticed before, things that use N-M to distinguish between online and offline modes will think they're offline after uninstalling N-M until they are restarted. You get this even with n-m installed, if n-m isn't managing your connection. So for example I have n-m configured for wifi and 3g connections, but ignoring my ethernet connection, so I can use a bridged setup. Various desktop apps misbehave in minor ways: pidgin as already mentioned; chrome reports unable to connect to Internet instead of more nuanced failures such as no such site, etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120710084754.GB24054@debian
Re: duplicates in the archive
Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : What's wrong with Recommends: in that case? It seems to perfectly match the makes life easier for common but not universal use-case XXX scenario you describe. Recommends is wrong for metapackages because it gets upgrades very wrong. This is why it is used very marginally. A hard package-dependency in a case like this, when there isn't actually any hard functional dependency, and there are issues with the depended-upon package, are decidedly user-unfriendly. It is unfriendly to the extreme minority of users who want a specific selection of packages rather than the default metapackages. Accidentally these are the users who also have the ability to make their own package selection. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1341927163.10559.1.camel@pi0307572
Recommends for metapackages (was: Re: duplicates in the archive)
[ dropping 542095@ ] Hi, On 2012-07-10 15:32, Josselin Mouette wrote: Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : What's wrong with Recommends: in that case? It seems to perfectly match the makes life easier for common but not universal use-case XXX scenario you describe. Recommends is wrong for metapackages because it gets upgrades very wrong. This is why it is used very marginally. Standards should not depend on implementation details. I see zero reasons why metapackages are (or should be) specific here. Whatever $it that gets upgrades wrong should be fixed instead. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux developer, Debian Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120710135212.GA5107@r500-debian
Re: N-M: Depends-Recommends (was: Re: duplicates in the archive)
On Tue, 2012-07-10 at 09:47 +0100, Jon Dowland wrote: On Mon, Jul 09, 2012 at 11:13:16PM +0200, Adam Borowski wrote: and also, as Philipp Kern noticed before, things that use N-M to distinguish between online and offline modes will think they're offline after uninstalling N-M until they are restarted. You get this even with n-m installed, if n-m isn't managing your connection. So for example I have n-m configured for wifi and 3g connections, but ignoring my ethernet connection, so I can use a bridged setup. Various desktop apps misbehave in minor ways: pidgin as already mentioned; chrome reports unable to connect to Internet instead of more nuanced failures such as no such site, etc. I was using gnome with n-m installed but deactivated (just remove /etc/rc*/netwrok-manager) without any issue. The reason for removing the rc*/n-m is that when starting n-m, evolution will refuse to connect to the unmanaged eth0 (static iface managed with ifup/ifdown). When n-m is stopped, evolution just will detect this and fallback to classical interface. I did not notice any other gnome application that depends on n-m on its apparent behavior. So I can certify this Depends is not required. Cheers,
Re: duplicates in the archive
On Tue, Jul 10, 2012 at 03:32:43PM +0200, Josselin Mouette wrote: Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit : What's wrong with Recommends: in that case? It seems to perfectly match the makes life easier for common but not universal use-case XXX scenario you describe. Recommends is wrong for metapackages because it gets upgrades very wrong. This is why it is used very marginally. In the general case, yes. This needs to be fixed. But it's not relevant here because squeeze had network-manager-gnome already. So we have three scenarios: * a new install. Recommends will pull in n-m unless explicitely rejected. * upgrade from squeeze (or earlier sid). Network-manager-gnome will be upgraded if present, and if it has been removed, that was not without a cause. * debfoster/aptitude/apt-get autoremove. Recommends will keep n-m-g safe from autoremoval. The problem with recommends is that they fail to pull in *new* relationships of an existing package, this is not what's the case here. A hard package-dependency in a case like this, when there isn't actually any hard functional dependency, and there are issues with the depended-upon package, are decidedly user-unfriendly. It is unfriendly to the extreme minority of users who want a specific selection of packages rather than the default metapackages. So you call people who want to connect a smartphone an extreme minority? The last time I checked, it's hard to find a person without one. USB cables seem to be more popular than wall chargers, and a good part of phones can transfer data over them. It also gets you an order of magnitude better transfer speed than wifi, and you don't have wifi everywhere. Folks who want to connect more than one machine via a VPN are also not that rare among Debian users. Or ones with a bridged setup. Those are more technical, yeah, but: Accidentally these are the users who also have the ability to make their own package selection. except that unless you sit deeply in Gnome development, you don't know which exactly components you need. This is precisely what a metapackage is for. Am I supposed to know by heart whether the file manager is called nautilus or caja this week? Or what do I need to install to have clicking an image show me its contents? -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 signature.asc Description: Digital signature
Re: duplicates in the archive
Adam Borowski writes (Re: duplicates in the archive): Breaks unrelated software on the system is a RC severity, and there's no way one can say a windowing environment is related to core networking. Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to Recommends: is a non-intrusive fix. It will cause n-m to be installed unless explicitely refused, just like you want it to be. I definitely think this should be fixed for wheezy. Adam earlier wrote on -devel: I tested a good part of Gnome today without n-m and it appears there are no regressions at all. The only differences are: * it gets rid of n-m icon in the systray (duh) The dependency comes via gnome-core depending on network-manager-gnome. To the Gnome maintainers: given that Adam has done this test, to check that things are OK without n-m, would you be willing to make this change to the gnome-core metapackage ? Thanks, Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20475.10012.868938.877...@chiark.greenend.org.uk
Re: N-M: Depends-Recommends (was: Re: duplicates in the archive)
On Mon, Jul 09, 2012 at 07:46:52PM +0100, Ian Jackson wrote: Adam Borowski writes (Re: duplicates in the archive): Breaks unrelated software on the system is a RC severity, and there's no way one can say a windowing environment is related to core networking. Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to Recommends: is a non-intrusive fix. It will cause n-m to be installed unless explicitely refused, just like you want it to be. I tested a good part of Gnome today without n-m and it appears there are no regressions at all. The only differences are: * it gets rid of n-m icon in the systray (duh) Actually, the very mail you reference, contains an continuation (with apologies for accidentally pressing 'y' instead of 'q'): } [was incomplete] } * network settings deep in the control panel will say the networking on }this system is not compatible and also, as Philipp Kern noticed before, things that use N-M to distinguish between online and offline modes will think they're offline after uninstalling N-M until they are restarted. Of course, none of the three are a big deal, at least comparing to not being able to connect a phone or use complex networking. -- Copyright and patents were never about promoting culture and innovations; from the very start they were legalized bribes to give the king some income and to let businesses get rid of competition. For some history, please read https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623 signature.asc Description: Digital signature
Re: duplicates in the archive
El lun, 09-07-2012 a las 19:46 +0100, Ian Jackson escribió: Adam Borowski writes (Re: duplicates in the archive): Breaks unrelated software on the system is a RC severity, and there's no way one can say a windowing environment is related to core networking. Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to Recommends: is a non-intrusive fix. It will cause n-m to be installed unless explicitely refused, just like you want it to be. I definitely think this should be fixed for wheezy. Adam earlier wrote on -devel: I tested a good part of Gnome today without n-m and it appears there are no regressions at all. The only differences are: * it gets rid of n-m icon in the systray (duh) The dependency comes via gnome-core depending on network-manager-gnome. To the Gnome maintainers: given that Adam has done this test, to check that things are OK without n-m, would you be willing to make this change to the gnome-core metapackage ? Thanks, Ian. A system without network-manager is still usable even for desktop users. I mean, for example, when Pidgin opens, and n-m is not available, it just tries to connect directly to internet. When pidgin opens, and n-m is active pidgin waits to connect until n-m gets connected. Sometimes is annoying because other network interfaces may be active with full internet and pidgin waits until n-m reports ready. A similiar experience happens with Evolution. But, ignoring the a desktop works fine without n-m thing, n-m makes more, much more easy connecting to wifi networks, espeacially for laptops. I suggest make Laptop task depend on n-m, in this way, n-m don't get installed on desktop systems, just on laptop systems. -- Atte. Félix Arreola Rodríguez, Firmado con GPG, llave 1E249EE4 signature.asc Description: This is a digitally signed message part
Re: duplicates in the archive
On Wed, Jun 27, 2012 at 10:23:38AM +0200, Philipp Kern wrote: On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote: Which wm does that? I know it isn't gnome-shell at least, as I've been using it quite successfully without nm installed. Have you tried to use evolution without NM? Evolution seems to work just fine. I didn't try but it only suggests network-manager. However some applications do behave weird if you just deinstalled n-m (pidgin for instance), because they assume that you're not connected. After a reboot (maybe dbus restart is enough) they certainly connect again, though. I tested a good part of Gnome today without n-m and it appears there are no regressions at all. The only differences are: * it gets rid of n-m icon in the systray (duh) The dependency comes via gnome-core depending on network-manager-gnome. Kind regards Philipp Kern -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120708144801.ga24...@angband.pl
Re: duplicates in the archive
WHOOPS, SORRY. Meant to delete this old draft, not send it. The issue is valid, but sorry for incomplete mail. On Sun, Jul 08, 2012 at 04:48:01PM +0200, Adam Borowski wrote: On Wed, Jun 27, 2012 at 10:23:38AM +0200, Philipp Kern wrote: On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote: Which wm does that? I know it isn't gnome-shell at least, as I've been using it quite successfully without nm installed. Have you tried to use evolution without NM? Evolution seems to work just fine. I didn't try but it only suggests network-manager. However some applications do behave weird if you just deinstalled n-m (pidgin for instance), because they assume that you're not connected. After a reboot (maybe dbus restart is enough) they certainly connect again, though. I tested a good part of Gnome today without n-m and it appears there are no regressions at all. The only differences are: * it gets rid of n-m icon in the systray (duh) [was incomplete] * network settings deep in the control panel will say the networking on this system is not compatible Since n-m breaks actually working software (udev, ifupdown) for non-obscure uses (connecting a phone via USB, bridged setups, non-basic VPNs, etc), a desktop environment hard-depending on it is bad, and this really needs to be a Recommends: relationship instead. N-M compared to ifupdown: * makes things easier for new users (good! especially in a default install) * is said to make wifi easier (when it works...) And downsides: * breaks usb0 completely (keeps raising and lowering the interface in a loop, no apparent way to tell it to keep its grubby hands away) * breaks a load of complex setups Breaks unrelated software on the system is a RC severity, and there's no way one can say a windowing environment is related to core networking. Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to Recommends: is a non-intrusive fix. It will cause n-m to be installed unless explicitely refused, just like you want it to be. On the other hand, breaking such setups is not a RC bug in n-m. Like any non-core package, there is no requirement for it to be universal: * not working with complex setups is at most wishlist * breaking USB networking by flipping the interface is normal It's just gnome-meta hard-depending on it what's wrong. -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. signature.asc Description: Digital signature
Re: duplicates in the archive
WHOOPS, SORRY. Meant to delete this old draft, not send it. The issue is valid, but sorry for incomplete mail. On Sun, Jul 08, 2012 at 04:48:01PM +0200, Adam Borowski wrote: On Wed, Jun 27, 2012 at 10:23:38AM +0200, Philipp Kern wrote: On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote: Which wm does that? I know it isn't gnome-shell at least, as I've been using it quite successfully without nm installed. Have you tried to use evolution without NM? Evolution seems to work just fine. I didn't try but it only suggests network-manager. However some applications do behave weird if you just deinstalled n-m (pidgin for instance), because they assume that you're not connected. After a reboot (maybe dbus restart is enough) they certainly connect again, though. I tested a good part of Gnome today without n-m and it appears there are no regressions at all. The only differences are: * it gets rid of n-m icon in the systray (duh) [was incomplete] * network settings deep in the control panel will say the networking on this system is not compatible Since n-m breaks actually working software (udev, ifupdown) for non-obscure uses (connecting a phone via USB, bridged setups, non-basic VPNs, etc), a desktop environment hard-depending on it is bad, and this really needs to be a Recommends: relationship instead. N-M compared to ifupdown: * makes things easier for new users (good! especially in a default install) * is said to make wifi easier (when it works...) And downsides: * breaks usb0 completely (keeps raising and lowering the interface in a loop, no apparent way to tell it to keep its grubby hands away) * breaks a load of complex setups Breaks unrelated software on the system is a RC severity, and there's no way one can say a windowing environment is related to core networking. Thus, I'd say, #542095 needs to be upgraded -- and changing Depends: to Recommends: is a non-intrusive fix. It will cause n-m to be installed unless explicitely refused, just like you want it to be. On the other hand, breaking such setups is not a RC bug in n-m. Like any non-core package, there is no requirement for it to be universal: * not working with complex setups is at most wishlist * breaking USB networking by flipping the interface is normal It's just gnome-meta hard-depending on it what's wrong. First of all I'm not a DD but just a Maintainer of 2 packages and a long time user. Since I fled away from KDE and felt into Gnome in Debian, I'm using it without N-M installed. It is only a matter of dpkg -force-depends -P two packages every time aptitude corrects my system when I install something, and I must say I'm more than happy by not having N-M: nothing messes with my network configuration (which is non-standard) and also users (my wife, or even myself using my normal account) can not disable networking nor break it. I have not tried Evolution (I use kmail even in Gnome and my wife uses Icedove) but I can say that Pidgin works better without N-M than with it. Regards (and thanks for all the time you spend that makes Debian my distro of choice) signature.asc Description: This is a digitally signed message part.
Re: duplicates in the archive
On Mon, Jun 25, 2012 at 12:38:42PM +0200, Svante Signell wrote: Which wm does that? I know it isn't gnome-shell at least, as I've been using it quite successfully without nm installed. Have you tried to use evolution without NM? I didn't try but it only suggests network-manager. However some applications do behave weird if you just deinstalled n-m (pidgin for instance), because they assume that you're not connected. After a reboot (maybe dbus restart is enough) they certainly connect again, though. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: duplicates in the archive
Adam Borowski kilob...@angband.pl kirjoitti: Sure, let's start removals with ones that hard-depend on things a window manager shouldn't touch, like network-manager. Which wm does that? I know it isn't gnome-shell at least, as I've been using it quite successfully without nm installed. (I hope this message looks okay - I'm sending from an unfamiliar MUA.) -- Antti-Juhani -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1eb44713-6893-4e9d-9cb5-9fd07e0c5...@email.android.com
Re: duplicates in the archive
On Sun, Jun 24, 2012 at 10:18:00PM +0100, Neil Williams wrote: On Sun, 24 Jun 2012 20:48:43 + Bart Martens ba...@debian.org wrote: On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote: Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit : What makes 42 window manager acceptable but not 43? Who said 42 is acceptable? The neglected ones should be removed. If they're all well maintained and all used, then 43 is acceptable, in my opinion. There is general agreement that neglected ones should be removed, it just comes down to someone doing the work and making that assessment. True. If you're interested, file the RM bugs in time for wheezy. You question those 42 implementations, so you can analyse them, file RM bugs where appropriate, and write a justification for rejecting #43. Feel free to re-use a similar measure/approximation for neglect as I blogged about for the measure/approximation of rubbish. (Linked from my homepage below.) If that text reflects consensus, then feel free to make http://qa.debian.org/howto-remove.html point to that text. With any objective analysis of the current 42, I find it impossible to believe that all 42 would re-qualify. Good, you seem to have already started with analysing those 42 implementations. Of course, someone who wanted to introduce #43 may be the person in the right place to do the analysis. This person may be in the right place to do the analysis, but I don't think that this person must do that analysis. It isn't a small task - if it doesn't get done for wheezy it's not that bad but The coming freeze period may be a good time for spending time on removals by anyone interested. it does seem justified before #43 arrives. It is not bad/wrong that you want that analysis to be done now. I'd expect that the process itself shows that #43 isn't actually needed at all and that whatever is desired can be achieved by patching one of the existing ones. Yes, the analysis may result in the conclusion that #43 is not needed in Debian. But please don't reject #43 just because nobody (not you, not the ITP submitter, not any volunteer) has compared it with the 42 other implementations. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120625062421.gb17...@master.debian.org
Re: duplicates in the archive
Neil Williams codeh...@debian.org writes: Whatever happens, there is no place for yet another duplicate of packages which already have multiple duplicates in the archive. I think it's hard to defend the contention that the quantity of packages has some strong relationship to whether or not those programs duplicate the functionality of other programs. Surely it also depends on the type of program, rather heavily. For example, I'm sure that we have more than 42 different programming languages in the archive, so obviously we don't need Java, right? You can do all the same things in C++. Or hey, let's pick one of either Perl or Python; they can both do the same things. I can definitely come up with more than 42 different ways to write an editor, all of which may appeal to different people, different tasks, or different work styles. But hey, I like Emacs, which clearly does everything that vi can do, so away with vim! And nvi just duplicates vim! We probably don't need 42 different ways to find duplicate files on local disk, since that's a relatively clear and well-defined task and there's only so many ways to go about it (and each implementation could probably gain the features of the others). But window managers are fundamental to one's style of interaction with the computer, and there are *huge* differences between them. A tiling window manager is not interchangeable with a desktop environment, which in turn is not interchangeable with a window manager designed to be operated without a mouse, or one that's optimized for a particular class of accessibility issues. And that's not even getting into the window managers that are used primarily because they embed a particular scripting language that people want to use to automate their windowing actions. By all means, let's get rid of packages that really do only offer subsets of functionality of other packages. But UI is part of functionality, and a different UI *is* a different feature. By all means, let's get rid of poorly-maintained packages. But if someone finds a package that does something in a way that nothing else does and that fits them, and they're able and willing to take care of it, having a place for those is one of Debian's strengths. We should be improving our tools and management techniques for handling large numbers of packages, including for retiring them when they're not being maintained, not trying to reduce the variety and depth of the distribution. And as sympathetic as I am to the concern about RC bugs in packages that are already in the archive, I suspect it's rather rare that fixing random RC bugs in other people's packages is the compelling, fun thing that gets someone involved in doing Debian development. I know it happens, but I bet more people join the project the way that I did: there's some specific piece of software that they want packaged for the distribution they already use, so they package it, and from that learn how to package, and from that branch out into helping with other parts of the distribution. Getting one's own package into the distribution is a really awesome feeling. I don't think it's good for the growth of the project, or for attracting new contributors, to put too many roadblocks in the way of someone feeling that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3yvgai6@windlord.stanford.edu
Re: duplicates in the archive
On Sun, Jun 24, 2012 at 08:36:13PM +0100, Neil Williams wrote: On Sun, 24 Jun 2012 20:42:33 +0200 Arno Töll a...@debian.org wrote: On 24.06.2012 19:51, Neil Williams wrote: Whatever happens, there is no place for yet another duplicate of packages which already have multiple duplicates in the archive. Letting alone the package in particular (I don't even know it, nor do I care) (Neither do I, particularly - but Thomas' list made it just too obvious that there was no justification for the bug report at the time of filing.) , I wonder where you'd draw that line. As you say yourself: There are lots of alternative packages in the archive already. So, what makes all the other alternatives acceptable but this one not? What makes 42 window manager acceptable but not 43? If it can be justified. That's what the objective comparison would need to demonstrate. The rejection of #43 should be justified, for example with conclusions from such comparison with the 42 other implementations. That's an established pattern in Debian - Let's not call your personal view an established pattern in Debian. Let's debate this and find a consensus before documenting it and advertising it as an established pattern in Debian. if someone wants to add something which is the same as something else, there should be a good reason to introduce the new one in that it needs to be better than the existing ones in some way which isn't achievable just by patching one of the existing ones. It is, in my opinion, OK that someone expresses an intent to package a 43th implementation in public so that anyone can compare it with the 42 other implementations and then argue why #43 would not be needed in Debian. Debian works on merit - packages and maintainers. Suggesting or packaging something which is without merit will usually result in complaints from your peers. Cope with it. Maintainers should not expect to be treated with kid gloves when what they are actually doing is wasting the free time of other volunteers. You can prevent your free time from being wasted by ignoring this ITP. If you actively want to keep the package of this ITP out of Debian, then you should produce some reasonable arguments, maybe after comparing all 43 implementations. But then it's your choice for doing all that work. Please don't blame the ITP submitter for wasting your time. We're used to 'Justification' as a concept for RC bugs, well an ITP is a bug in Debian and can also require justification. Some ITP bugs are simply invalid. An ITP is an expression of an intent to package some software. It does by itself not express I have analysed every alternative in Debian and I think this one is better. If you feel that this one is not better, then you should justify the rejection of the ITP. Someone needs to make that call and as we're all part of the QA team, various people do it according to their own free time, work area, expertise and general levels of annoyance with daft ideas. Yes, anyone can justify why an ITP should be rejected. Whether it's a joke package or a tiny package which needs to go into a collective package (goodies or devscripts or whatever), if maintainers (prospective or existing) can't do their own research ahead of filing a bug, it is up to the rest of us to point out the error. Yes, you're right about this. That's what I understand in peer review. I'm not in favor to get yet another window manager in Debian. All I'm saying is that filing a WNPP bug and wait whether a people complain loud enough is not the way to learn that. I think that it is OK that other people complain about an ITP. It is also OK to be very clear about why an ITP in particular is not welcome. Of course, politeness and friendliness are generally appreciated, and I think that this aspect started the debate. So feel free to file a patch to the Developer Reference explaining that if maintainers of prospective packages don't check for existing packages which provide the same or very similar functionality, any request to package such a duplicate needs to be accompanied by a detailed reasoning of *why* the existing packages are sufficiently inadequate that a new package is warranted instead of patching what we have. If you feel that Developer Reference can be improved, then feel free to do suggestions. The above is not a suggestion I can support. To me, such an expectation is common sense and I'm quite happy to continue criticising ITP's on the basis of being an unjustifiable duplicate of existing packages. It is good that you continue reviewing ITPs. But I would appreciate (and the ITP submitter would probably also appreciate) that you justify rejecting ITPs with good arguments and in a friendly way. Especially since a WNPP bug complaints are not worth that much. If you happen to find a DD to upload your stuff or you are DD yourself, you can silently ignore any
Re: duplicates in the archive
Hello, On Sun, 24 Jun 2012 20:36:13 +0100 Neil Williams codeh...@debian.org wrote: If it can be justified. That's what the objective comparison would need to demonstrate. That's an established pattern in Debian - if someone wants to add something which is the same as something else, there should be a good reason to introduce the new one in that it needs to be better than the existing ones in some way which isn't achievable just by patching one of the existing ones. It is definitely not the same and not duplicate. Different window managers look differently and feel a lot differently (I thought it should be obvious enough, isn't it?). More to say, I'd like to see this window manager in Debian, jugding by its documentation it seems to be really great, flexible yet tiny and easily configurable, so I support it's inclusion fully. -- WBR, Andrew signature.asc Description: PGP signature
Re: duplicates in the archive
On Mon, 2012-06-25 at 08:19 +0200, Antti-Juhani Kaijanaho wrote: Adam Borowski kilob...@angband.pl kirjoitti: Sure, let's start removals with ones that hard-depend on things a window manager shouldn't touch, like network-manager. Yes, why not! Which wm does that? I know it isn't gnome-shell at least, as I've been using it quite successfully without nm installed. Have you tried to use evolution without NM? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1340620722.5945.3.camel@x60
Re: duplicates in the archive
]] Neil Williams Popcon indicates almost nothing - least of all popularity. The weaknesses of popcon for archive-related questions is well documented. It might give a hint but it is *not* a reliable indicator. While it's not perfect, I'm not aware of any better tool we have. Relying on hearsay about what people install is worse. 99% of the Debian machines I install have no means of communicating via popcon - ever. What's installed on those is completely invisible. It does not matter how many machines are installed without popcon as long as it is installed on a representative sample. Whether that is the case is open for debate, but unless and until somebody comes up with a better tool and method than using popcon, that's what we have. [...] Rubbish. Complete tosh. You might want to reconsider your choice of words. You're coming across as quite hostile in this thread. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bok7zkxw@qurzaw.varnish-software.com
Re: duplicates in the archive
Svante Signell svante.sign...@telia.com kirjoitti: On Mon, 2012-06-25 at 08:19 +0200, Antti-Juhani Kaijanaho wrote: Which wm does that? I know it isn't gnome-shell at least, as I've been using it quite successfully without nm installed. Have you tried to use evolution without NM? Evolution is not, so far as I know, a window manager. And no, I have never used it, with or without NM. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8953d159-a56b-4756-8b12-383af507e...@email.android.com
Re: duplicates in the archive
+++ Neil Williams [2012-06-24 18:51 +0100]: On Sun, 24 Jun 2012 19:31:12 +0200 Arno Töll a...@debian.org wrote: Dropping the bug CC. On 24.06.2012 19:15, Neil Williams wrote: This bug is *not* useful to anyone. Please close it and find an RC bug to close instead. I'm pretty sure this could be expressed in another tone. Especially since we welcome everyone (you know) and we have _no_ written rule what belongs into Debian and what not, and nobody who decides on that beyond legal issues. This isn't about welcoming people, this is about keeping pointless vanity packages out of the archive. Arno's point was that if you were clever you could do both. It's possible to tell someone that packaing this particular thing is a bad idea without being rude and superiour. If one does that they might go away with the impression that Debian is a civilised place where they'd like to help out, rather than a place full of people who are usually right but arrogant with it. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624183857.go13...@stoneboat.aleph1.co.uk
Re: duplicates in the archive
Hi, On 24.06.2012 19:51, Neil Williams wrote: Whatever happens, there is no place for yet another duplicate of packages which already have multiple duplicates in the archive. Letting alone the package in particular (I don't even know it, nor do I care), I wonder where you'd draw that line. As you say yourself: There are lots of alternative packages in the archive already. So, what makes all the other alternatives acceptable but this one not? What makes 42 window manager acceptable but not 43? There isn't even any point waiting for such packages to get RC bugs to be able to remove them. Stop them getting in in the first place. I'm not in favor to get yet another window manager in Debian. All I'm saying is that filing a WNPP bug and wait whether a people complain loud enough is not the way to learn that. Especially since a WNPP bug complaints are not worth that much. If you happen to find a DD to upload your stuff or you are DD yourself, you can silently ignore any comments if you like and upload nonetheless. That's how we end up with 42 display manager. Complaining on the 43th is not the way to go. Moreover, would you be a well respected Debian Developer today if your replies to your first WNPP bug (if you filed any, I don't know) back then told you to go away, nobody appreciates your work? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: duplicates in the archive
On Sun, Jun 24, 2012 at 06:51:47PM +0100, Neil Williams wrote: On Sun, 24 Jun 2012 19:31:12 +0200 Arno Töll a...@debian.org wrote: Dropping the bug CC. On 24.06.2012 19:15, Neil Williams wrote: This bug is *not* useful to anyone. Please close it and find an RC bug to close instead. I'm pretty sure this could be expressed in another tone. Especially since we welcome everyone (you know) and we have _no_ written rule what belongs into Debian and what not, and nobody who decides on that beyond legal issues. This isn't about welcoming people, this is about keeping pointless vanity packages out of the archive. We don't need absolute rules on this but the whole point of ITP bugs being CC'd to this list is so that people on this list get a chance to head off mistakes. Adding another pointless alternative for packages which are already duplicated over and over *is* a mistake. Maybe the Developer Reference should be strengthened to require a check against the existing archive as well as the WNPP list but, IMHO, that's a bit of common sense which all maintainers and prospective maintainers should be able to demonstrate. If you feel that's not common, feel free to file a bug against the Developer Reference. Whatever happens, there is no place for yet another duplicate of packages which already have multiple duplicates in the archive. There isn't even any point waiting for such packages to get RC bugs to be able to remove them. Stop them getting in in the first place. Hi Neil, I agree with Arno about the tone. I don't have a strong opinion on whether this package in particular should be kept out of Debian. You may be right about this package in particular, no idea. About allowing new packages in Debian in general : On the one hand you have a point that Debian should not collect any free software, but on the other hand I think that it is OK to have multiple implementations of the same/similar functionality in Debian, and over time the popcon stats may indicate that a newer package wins over an older package. It is, in my opinion, not always possible to judge the potential of a package before it has been in Debian for some time. Having competing alternatives in Debian is OK, even good, in my opinion. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624184554.ga22...@master.debian.org
Re: duplicates in the archive
On Sun, 24 Jun 2012 20:42:33 +0200 Arno Töll a...@debian.org wrote: On 24.06.2012 19:51, Neil Williams wrote: Whatever happens, there is no place for yet another duplicate of packages which already have multiple duplicates in the archive. Letting alone the package in particular (I don't even know it, nor do I care) (Neither do I, particularly - but Thomas' list made it just too obvious that there was no justification for the bug report at the time of filing.) , I wonder where you'd draw that line. As you say yourself: There are lots of alternative packages in the archive already. So, what makes all the other alternatives acceptable but this one not? What makes 42 window manager acceptable but not 43? If it can be justified. That's what the objective comparison would need to demonstrate. That's an established pattern in Debian - if someone wants to add something which is the same as something else, there should be a good reason to introduce the new one in that it needs to be better than the existing ones in some way which isn't achievable just by patching one of the existing ones. Debian works on merit - packages and maintainers. Suggesting or packaging something which is without merit will usually result in complaints from your peers. Cope with it. Maintainers should not expect to be treated with kid gloves when what they are actually doing is wasting the free time of other volunteers. We're used to 'Justification' as a concept for RC bugs, well an ITP is a bug in Debian and can also require justification. Some ITP bugs are simply invalid. Someone needs to make that call and as we're all part of the QA team, various people do it according to their own free time, work area, expertise and general levels of annoyance with daft ideas. Whether it's a joke package or a tiny package which needs to go into a collective package (goodies or devscripts or whatever), if maintainers (prospective or existing) can't do their own research ahead of filing a bug, it is up to the rest of us to point out the error. I'm not in favor to get yet another window manager in Debian. All I'm saying is that filing a WNPP bug and wait whether a people complain loud enough is not the way to learn that. So feel free to file a patch to the Developer Reference explaining that if maintainers of prospective packages don't check for existing packages which provide the same or very similar functionality, any request to package such a duplicate needs to be accompanied by a detailed reasoning of *why* the existing packages are sufficiently inadequate that a new package is warranted instead of patching what we have. To me, such an expectation is common sense and I'm quite happy to continue criticising ITP's on the basis of being an unjustifiable duplicate of existing packages. Especially since a WNPP bug complaints are not worth that much. If you happen to find a DD to upload your stuff or you are DD yourself, you can silently ignore any comments if you like and upload nonetheless. At which point, the credibility of any such DD is diminished, as is the credibility of any DD who sponsors such packages despite complaints from his/her peers. That's how we end up with 42 display manager. Complaining on the 43th is not the way to go. The 43rd must be *justified* - there needs to be a reason why the lack of this package is a bug in Debian. Otherwise the request could just as well be reassigned as a wishlist bug against one of the alternatives. Moreover, would you be a well respected Debian Developer today if your replies to your first WNPP bug (if you filed any, I don't know) back then told you to go away, nobody appreciates your work? As hinted in my previous post, I did my research before filing my first (and subsequent) ITP bugs. Nobody disagreed at the time and I have since removed the first package I introduced into Debian as it's time had passed. There were no duplicates but there was also no justification for it remaining in the archive for wheezy. An ITP is meant to be a bug in Debian - that Debian is missing some functionality. It is perfectly acceptable to require that such functionality can be implemented in a different way by working with a package we already have. Triaging bugs requires that the bugs are tested for validity before spending more time on the fix. No point putting the wrong fix into the archive. However, I also had comments from other bugs once becoming a DD which showed where I'd gone wrong on those packages, but that just meant that I had to show I could accept criticism and just get on with fixing stuff. Those who did criticise me I now count as friends, so that is how I think Debian should work. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpKX9uPlbfZH.pgp Description: PGP signature
Re: duplicates in the archive
On Sun, 24 Jun 2012 18:45:54 + Bart Martens ba...@debian.org wrote: About allowing new packages in Debian in general : On the one hand you have a point that Debian should not collect any free software, but on the other hand I think that it is OK to have multiple implementations of the same/similar functionality in Debian, and over time the popcon stats may indicate that a newer package wins over an older package. It is, in my opinion, not always possible to judge the potential of a package before it has been in Debian for some time. Having competing alternatives in Debian is OK, even good, in my opinion. The maintainer has to make that judgement, it's just one of the things maintainers have to do. popcon is no indicator here, it is about whether there is a bug in Debian, independent of this package. I apply the same criteria to all my packages and I have and will continue to remove any which do not merit a place in a stable release. What *quality* issue is meant to being fixed by a new package? If there's none, then the ITP is invalid and the package is without merit. Just like any other bug - if the submitter has just got it wrong (for whatever reason), the bug can be deemed invalid. Sometimes an improvement to the documentation can help others not make the same error, sometimes the docs are fine and it's just a mistake. Multiple implementations hurt the archive, waste ftpmaster time, waste QA time, waste wanna-build time, waste Debian resources, complicate transitions and often collect RC bugs. In short, the more duplicates there are, the higher the percentage of those duplicates which will go to rot in the archive, causing aggravation for everyone. Competition is useful, surfeit is harmful. If a new package does have merit compared to all the existing equivalents, then explain those merits and let your peers judge the package. The issue is to fix the problem in Debian, not just introduce a new package which fixes nothing. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpUT9xx6tkN0.pgp Description: PGP signature
Re: duplicates in the archive
Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit : What makes 42 window manager acceptable but not 43? Who said 42 is acceptable? -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1340569299.29283.0.camel@tomoyo
Re: duplicates in the archive
On Sun, Jun 24, 2012 at 08:48:48PM +0100, Neil Williams wrote: On Sun, 24 Jun 2012 18:45:54 + Bart Martens ba...@debian.org wrote: About allowing new packages in Debian in general : On the one hand you have a point that Debian should not collect any free software, but on the other hand I think that it is OK to have multiple implementations of the same/similar functionality in Debian, and over time the popcon stats may indicate that a newer package wins over an older package. It is, in my opinion, not always possible to judge the potential of a package before it has been in Debian for some time. Having competing alternatives in Debian is OK, even good, in my opinion. The maintainer has to make that judgement, it's just one of the things maintainers have to do. popcon is no indicator here, it is about whether there is a bug in Debian, independent of this package. Not only the maintainer but also the many users judge how useful a package is in Debian. This judgement cannot always be made at ITP time. Popcon does indicate how popular the package is, doesn't it ? I apply the same criteria to all my packages and I have and will continue to remove any which do not merit a place in a stable release. I see no problem with removing packages that don't belong in a Debian stable release. But weren't we talking about judging at ITP time on whether the package is allowed to enter Debian ? What *quality* issue is meant to being fixed by a new package? If there's none, then the ITP is invalid and the package is without merit. Just like any other bug - if the submitter has just got it wrong (for whatever reason), the bug can be deemed invalid. Sometimes an improvement to the documentation can help others not make the same error, sometimes the docs are fine and it's just a mistake. I don't think that an ITP is only valid if it fixes something in Debian. Sometimes a package is worth entering Debian simply because it is good free software, regardless of any alternatives already in Debian. Multiple implementations hurt the archive, waste ftpmaster time, waste QA time, waste wanna-build time, waste Debian resources, complicate transitions and often collect RC bugs. In short, the more duplicates there are, the higher the percentage of those duplicates which will go to rot in the archive, causing aggravation for everyone. I'm not convinced that the above applies to multiple implementations more than to simply many packages. Neglected packages about should be removed. That applies to any package in Debian, not only to multiple implementations. Competition is useful, surfeit is harmful. If a new package does have merit compared to all the existing equivalents, then explain those merits and let your peers judge the package. If there are sufficient volunteers who want to spend their time on packaging the software and maintaining it in Debian, then why not let the users judge the package ? The issue is to fix the problem in Debian, not just introduce a new package which fixes nothing. The issue is to allow new packages a chance in Debian to rise above the existing alternatives in Debian. This cannot always be judged at ITP time. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624204655.gz22...@master.debian.org
Re: duplicates in the archive
On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote: Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit : What makes 42 window manager acceptable but not 43? Who said 42 is acceptable? The neglected ones should be removed. If they're all well maintained and all used, then 43 is acceptable, in my opinion. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624204843.ga22...@master.debian.org
Re: duplicates in the archive
On Sun, 24 Jun 2012 20:48:43 + Bart Martens ba...@debian.org wrote: On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote: Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit : What makes 42 window manager acceptable but not 43? Who said 42 is acceptable? The neglected ones should be removed. If they're all well maintained and all used, then 43 is acceptable, in my opinion. There is general agreement that neglected ones should be removed, it just comes down to someone doing the work and making that assessment. If you're interested, file the RM bugs in time for wheezy. Feel free to re-use a similar measure/approximation for neglect as I blogged about for the measure/approximation of rubbish. (Linked from my homepage below.) With any objective analysis of the current 42, I find it impossible to believe that all 42 would re-qualify. Of course, someone who wanted to introduce #43 may be the person in the right place to do the analysis. It isn't a small task - if it doesn't get done for wheezy it's not that bad but it does seem justified before #43 arrives. I'd expect that the process itself shows that #43 isn't actually needed at all and that whatever is desired can be achieved by patching one of the existing ones. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpQr67DQQziL.pgp Description: PGP signature
Re: duplicates in the archive
On Sun, 24 Jun 2012 20:46:55 + Bart Martens ba...@debian.org wrote: The maintainer has to make that judgement, it's just one of the things maintainers have to do. popcon is no indicator here, it is about whether there is a bug in Debian, independent of this package. Not only the maintainer but also the many users judge how useful a package is in Debian. This judgement cannot always be made at ITP time. Popcon does indicate how popular the package is, doesn't it ? Popcon indicates almost nothing - least of all popularity. The weaknesses of popcon for archive-related questions is well documented. It might give a hint but it is *not* a reliable indicator. 99% of the Debian machines I install have no means of communicating via popcon - ever. What's installed on those is completely invisible. I apply the same criteria to all my packages and I have and will continue to remove any which do not merit a place in a stable release. I see no problem with removing packages that don't belong in a Debian stable release. But weren't we talking about judging at ITP time on whether the package is allowed to enter Debian ? Yes. An ITP is a bug in Debian and bugs need to be triaged - triage involves assessing whether the bug is valid. Before trying to fix the problem, identify that the problem is the problem you think it is. That kind of response makes me think that you haven't tried to remove a set of packages and have no idea how difficult it can be. What *quality* issue is meant to being fixed by a new package? If there's none, then the ITP is invalid and the package is without merit. Just like any other bug - if the submitter has just got it wrong (for whatever reason), the bug can be deemed invalid. Sometimes an improvement to the documentation can help others not make the same error, sometimes the docs are fine and it's just a mistake. I don't think that an ITP is only valid if it fixes something in Debian. Sometimes a package is worth entering Debian simply because it is good free software, regardless of any alternatives already in Debian. Rubbish. Complete tosh. That is precisely the attitude that leads to Debian being seen as a dumping ground for vanity packages and other trash. An ITP is a statement that there is some *functionality* absent in Debian. Someone cannot do something because the existing packages don't provide that functionality - that is a justification for a new package but it can also be justification for a patch to an existing package. Copying ITP bugs to this list is one of the ways of spotting when that can be done instead of adding another package. If I file a bug against one of your packages that it needs to do something which would be a complete waste of your time, do you not have the right and obligation to tell me to not be so stupid and to close the bug as invalid? Well, WNPP is one of your packages just as it is one of mine because it comes under the QA team. Multiple implementations hurt the archive, waste ftpmaster time, waste QA time, waste wanna-build time, waste Debian resources, complicate transitions and often collect RC bugs. In short, the more duplicates there are, the higher the percentage of those duplicates which will go to rot in the archive, causing aggravation for everyone. I'm not convinced that the above applies to multiple implementations more than to simply many packages. Neglected packages about should be removed. That applies to any package in Debian, not only to multiple implementations. Yes, so do both. There are still plenty of packages which could justifiably be removed before Wheezy is released. Competition is useful, surfeit is harmful. If a new package does have merit compared to all the existing equivalents, then explain those merits and let your peers judge the package. If there are sufficient volunteers who want to spend their time on packaging the software and maintaining it in Debian, then why not let the users judge the package ? There never *ARE* enough volunteers. Even if there are today, there is no guarantee that there will be by the time of the next release and when volunteers give up, they tend not to have time to tidy up after themselves by removing packages. Why do you think we have so many RC bugs? We never have enough volunteers - if we did, we could have frozen at the start of June and we would make the release on the last day of DebConf. As it is, we have over 670 RC bugs right now and we only have one Gregor Herrmann. The issue is to fix the problem in Debian, not just introduce a new package which fixes nothing. The issue is to allow new packages a chance in Debian to rise above the existing alternatives in Debian. This cannot always be judged at ITP time. On what basis are things going to rise above if there is nothing which separates them from the existing packages? NotInventedHere syndrome should *not* be welcome in Debian. That's not
Re: duplicates in the archive
On Sun, Jun 24, 2012 at 10:21:39PM +0200, Josselin Mouette wrote: Le dimanche 24 juin 2012 à 20:42 +0200, Arno Töll a écrit : What makes 42 window manager acceptable but not 43? Who said 42 is acceptable? Sure, let's start removals with ones that hard-depend on things a window manager shouldn't touch, like network-manager. If one has to choose between working networking and a given window manager, the choice is obvious -- except maybe for newbie users, who won't understand what to do when they get hard-stumped faced with a basic task like connecting a phone via USB[1], or for less newbie ones, any bridged or multi-homed setup. So, a good deal of smaller window managers are functionally redundant and could be culled, but they at least don't break unrelated packages. Whether one prefers Gnome3 interface or something more traditional[2] is one thing, but there are technical downsides for Gnome that could be trivially fixed. And yet are not. [1]. With non-ancient udev, connecting one spawns an usb0 interface you can configure any usual way, unless you have n-m continuously screwing with it. [2]. Let's not go into flamewars about user interface here, it has been overdone already. -- I was born an ugly, dumb and work-loving child, then an evil midwife replaced me in the crib. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624215814.ga32...@angband.pl
