Re: [gentoo-dev] Removals reply
On 02/03/2013 07:07 AM, Alexandre Rostovtsev wrote: We the Gentoo developers strongly believe that this project is not fun and not important. veto. a) there is no we, b) there are conrary posts on this list. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] Removals reply
Le lundi 04 février 2013 à 12:08 +0100, Michael Weber a écrit : On 02/03/2013 07:07 AM, Alexandre Rostovtsev wrote: We the Gentoo developers strongly believe that this project is not fun and not important. veto. a) there is no we, b) there are conrary posts on this list. that doesn't mean this is the majority either. In any case, if anyone feels strongly about this, it should probably be discussed on -project and/or brought up to the council. I have absolutely no interest in having Gentoo be some kind of archive distro and will not read any further mail in this thread since it has looped a few times already on the same arguments. Thanks for reading this captain obvious mail. -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Removals reply
(My last public mail on the topic, I promise). Alexandre Rostovtsev wrote: If you want an automatic archive for dropped packages, MAKE ONE! You can study the problem with single-person projects at the example of the (previous) Gentoo Wiki. Without having the files on (at least some) mirrors it makes no sense. (Also, I am already contributing more than I can afford with eix). Alec Warner wrote: Gentoo has been running for over 10 years without it This is why nobody yet expected to re-obtain tarballs for packages older than 10 years. Also the desire for still slightly younger tarballs is currently low due to the age of Gentoo. But slowly the situation starts to change, and in a few years, it will look rather differently. I don't believe for a second that it is the role of Gentoo to have packaged 'any software the user might have ever needed, or will ever need.' Not packaged, but if it was once packaged, it could still be provided (in an unmaintained form). It has nothing to do with disk space. It is. (Only). See below. Why do you want to put pressure on *me* to maintain software I do not want to maintain? Not at all. I was never suggesting that anyone should maintain it. I am just suggesting to *not* remove things permanently but just to mark them unmaintained instead (e.g. by a corresponding mask comment). I think what you have failed to do is find someone in the developer community who is really eager to implement your idea. There is not much to implement - just to not remove. If you really think that it is a *technical* problem if unmaintained masked abuilds are in the tree (e.g. to shorten the disk space on the user's disk, to shorten eix's output, or just to avoid that portage might get confused some day with ancient EAPI's), one could indeed find a small alternative implementation: E.g. remove the ebuilds as now (since they are in CVS/git anyway), but to save the tarballs just collect them in some package app-portage/obsolete (or other name) which installs nothing but just contains all removed tarballs in its SRC_URI so that they do not vanish from the mirrors. There is really nothing to implement. It is only a question whether it is *wanted*. Or put pressure on *Gentoo* to mirror someones source code or binaries, for software Gentoo are no longer interested in distributing? So, essentially, it *is* an issue of disk (mirror) space. Regards Martin
Re: [gentoo-dev] Removals reply
On Sun, Feb 3, 2013 at 12:07 AM, Vaeth va...@mathematik.uni-wuerzburg.de wrote: Yep! That's the right attitude: Give the people 30 days (even those people who are currently not at Gentoo for whatever reason) to know years in advance all the software they might ever need and tell them, if in doubt, just to maintain hundreds of packages! It is *of course* their fault if they do not! Later, if they need a package, you can blame them that they have not voluntereered for all these packages they possibly might have needed, because years ago they had 30 days time to think about it (even longer if they took the time and resources to backup on their machines all tarballs of all packages). If the package gets masked and you want to keep it around, just fetch the tarball (which should still be on the mirrors) and copy the ebuild to your own overlay. For you personally, there is no longer a crisis. Now, if you want the rest of the world to benefit from your work you can publish that overlay and stick the distfile somewhere public. You're welcome to get somebody to help you proxy-maintain the package in the tree as well. If the only thing wrong with the package is the missing SRC_URI you shouldn't have too much trouble finding somebody willing to do the commit. Creating a long-term repository for upstream tarballs even after we drop the package is not a trivial job. There would be considerable space requirements, and there are legal issues as well (since they aren't maintained nobody is looking for license issues/etc). There are many packages in the tree with RESTRICT=mirror and those we can't do anything for in any case. Sure, the road to becoming a dev is a long one, but NOBODY needs PERMISSION to contribute to Gentoo. Anybody can submit patches, and anybody can run their own overlay. In most distros this is a much more common practice. Go look up your favorite piece of software and you'll probably find their instructions for installing it on Gentoo start out by adding another repository to your configuration - they couldn't even get Ubuntu to carry their package despite having done all the work for them. With services like github and such it really doesn't take that much work to set up your own overlay. If you do that you can package whatever you want and nobody will tell you that you're in violation of any rules. Gentoo really is an empowering distro. However, manpower is tight at Gentoo, and we're all volunteers. You can't just yell at devs and tell them to do more work. It won't get you very far. Rich
Re: [gentoo-dev] Removals reply
The ebuild is still available by CVS (or maybe git in future), but if there were already a lot of gentoo patches, the tarball with these patches is lost forever. If even upstream is dead, not even the main tarball will be available anymore. Oh but it can mostly these archaic packages do not have patchsets. Please, do not put up strawmans. Even if it should happen not often, it it is a serious problem when it happens. I do not remember anymore about the package(s?), but I already ran into the situation of long gone patchsets. Moreover, a gone tarball is even worse. When I came to Gentoo many years ago, this was a very rare problem, but the removal of packages has tremendously increased, and it is not only me who is observing this problem - there were already some threads in the forums, and people planning to but not coming back to Gentoo for this reason. Also there is proposal to create git repository with patches exactly for this purposes. This might solve the problem of the patches but not of the lost tarballs. It was suggested in this thread to put up some server with the tarballs. This might be a solution, but for such isolated solutions there is always the danger that the same could happen as did once to the Gentoo Wiki: It would be better if the old tarballs are also on the mirrors (at least on some of them); maybe one could make some optional directory which not every mirror is supposed to have. You still can count the packages using huge patchsets using just your hands. Again, the number is not so important, but counting by using your hands I did not expect to be meant binary ;) %grep -l http.*:.*patch.*\..*z.* /srv/portage/gentoo/*/*/*.ebuild|wc -l 421 And what if somebody decides to do so in a year? If you are person who didn't touch his Gentoo box Again, please, do not put up strawmans. I mentioned several reasons why somebody might want to do this in a year (and actually this already happened to me and probably others; it is not so infrequent that people leave gentoo for a long while - there are many valid reasons). Your argument only shows that there could also exist other (stupid) behavior - which is not related at all with my arguments. so we can say someone get hardware that is at least decade old, honestly just obtain distros build around such HW (like debian stable). Gentoo is about choice. I bet, many Gentoo users have at least some old hardware device which they want to use. Maybe occasionally, they also inherit some which they want to use. You really want to scare all these users away? Or if he was not yet a gentoo user at the time when the package was removed (or absent/busy for a long period)? Well he would found out after sync Perhaps there was a misunderstanding: How can someone who starts to use Gentoo in a year find out after sync? Or another one know a year in advance that he will have the need for some special software (e.g. to support a device which he inherits in a year)? Gentoo is not a distro with bigger resources I agree: If none of the developers is interested in a package, it is completely fine to declare it as unsupported and to require the user to maintain it himself (or hire somebody) if he wants to use it. Masking it is perfectly fine (maybe another idea would be to introduce some new state for such unmaintained packages so that they are usually ignored). I just ask that Gentoo should not *hinder* the user in installing/ maintaining a package later by removing the tarballs (and possibly patches) which once were available. If these mild (essentially only storage) resources are *really* a severe issue for Gentoo (or uninstalled masked packages should cause a considerable slowdown for portage's resolver) then Gentoo has a much more severe resources problem (or technical problem with portage)... PS: threading is broken in your mail client. Sorry about that; I am not a regular member of this list and post only about once a year when I really feel that something should be said. In this case, I just wanted to report this problem to where it probably belongs - to the developer's list - instead of complaining only in some forums. Presumably, this will be my last posting for quite a while, since I hope that the problem (and suggestions for possible solutions) should have become clear. Regards Martin
Re: [gentoo-dev] Removals reply
On Sat, Feb 2, 2013 at 6:44 AM, Vaeth va...@mathematik.uni-wuerzburg.de wrote: I just ask that Gentoo should not *hinder* the user in installing/ maintaining a package later by removing the tarballs (and possibly patches) which once were available. So, I can see the validity of this argument insofar as it applies to Gentoo-generated tarballs and such, like patchsets. These tend to be hosted on dev webpages and such, and as a result they don't get any kind of version control like files in cvs do. Code that Gentoo creates should in general be revision-controlled. Another class of code is distfile tarballs that we create. Some packages have these because upstream does not have reliable source tarball hosting. Maybe they only host binaries and an scm that does not generate tarballs on demand. So, sometimes devs have to create source tarballs and host them somewhere, and these also do not get revision-controlled. I'm a bit torn on these because they are in fact large files and they're only marginally Gentoo-created, but they probably could never be recreated with a matching hash. If for whatever reason space was no object and we did revision-control these files we would need a mechanism to obliterate them entirely (or at least block access) should a licensing issue be discovered. Patches are something we could probably claim copyright or fair use over, but entire source tarballs clearly require a license to redistribute. I do have to agree with the earlier comment that Gentoo isn't a software archiving service. I think we SHOULD archive the stuff we create - if somebody wants to work on a better way of hosting patches this is something Gentoo should support (via infra/etc), but of course somebody has to step up and actually do that work, and it isn't reasonable to ask treecleaners/QA/etc to leave things with broken SRC_URIs in the tree until this is done. Broken SRC_URIs generate logspam and no doubt headaches in general for those who graciously maintain our mirrors. As far as upstream tarballs go - if somebody wants to archive them by all means do so, and patches for broken SRC_URIs that point to these patches should be consider welcome provided the package has no other serious flaws. However, maintaining an archive of tarballs for anything we EVER packaged sounds like a lot of work, and not a small amount of space/bandwidth/etc as well. Do we archive everything just in case? Do we periodically scan stuff in our attic in case a package we already removed has its sources disappear (and what do we even do then since we don't mirror removed pacakges)? Why bother trying to archive some distfiles if we don't archive all of them? This just sounds like a big mess, and not really our core mission. Rich
Re: [gentoo-dev] Removals reply
Dne So 2. února 2013 12:44:30, Vaeth napsal(a): When I came to Gentoo many years ago, this was a very rare problem, but the removal of packages has tremendously increased, and it is not only me who is observing this problem - there were already some threads in the forums, and people planning to but not coming back to Gentoo for this reason. Awesome so they could've get involved and maintain it themselves if they seen it so crushial for their lives. When looking on Robins automated packages addition/removal tracker it seems that the removal trend does not change much, the only thing that changed is that now with tinderbox we see way earlier that package is broken to build and thus removed rather than being in tree uninstallable. Also on the additions side we are quite getting more and more stuff in tree. Also there is proposal to create git repository with patches exactly for this purposes. This might solve the problem of the patches but not of the lost tarballs. It was suggested in this thread to put up some server with the tarballs. This might be a solution, but for such isolated solutions there is always the danger that the same could happen as did once to the Gentoo Wiki: It would be better if the old tarballs are also on the mirrors (at least on some of them); maybe one could make some optional directory which not every mirror is supposed to have. As I said in my first mail, distro mirroring system is not to pose for upstream. You have to set up some webpage and download on some site. I mentioned fedorahosted because that one is managed by rh so it won't diappear, but you can put it on github or elsewhere if you feel like it. You still can count the packages using huge patchsets using just your hands. Again, the number is not so important, but counting by using your hands I did not expect to be meant binary ;) %grep -l http.*:.*patch.*\..*z.* /srv/portage/gentoo/*/*/*.ebuild|wc -l 421 Yay, now lets see what are biggest consumers on your list: kernel, coreutils, netbeans, postgres Sweet this leaves around 200 versioned ebuilds with 2 versions in tree each. So 100 not critical ebuids of all the in-tree ebuilds use custom patchsets... I agree that we should track the patches in some git repository so feel free to open bugreport for infra team to fire up some structure that everyone will be required to use. Also thinking about it we still have this nice policy where we should open upstream bugreports and contribute all patches back, so they should in theory be always somewhere else too :-) so we can say someone get hardware that is at least decade old, honestly just obtain distros build around such HW (like debian stable). Gentoo is about choice. I bet, many Gentoo users have at least some old hardware device which they want to use. Maybe occasionally, they also inherit some which they want to use. You really want to scare all these users away? Yes gentoo is about choice but the choice does not mean to contain everything possible in the tree. We keep the tree maintainable and working for everyone, it is not just some junkyard of whatever did compile few years back for lucky people. Actually suse/fedora and others remove packages way more than us, they just do it with each release so it does not happen here and there but just once every 6 months (or whatever is their release cycle). Or if he was not yet a gentoo user at the time when the package was removed (or absent/busy for a long period)? Well he would found out after sync Perhaps there was a misunderstanding: How can someone who starts to use Gentoo in a year find out after sync? Or another one know a year in advance that he will have the need for some special software (e.g. to support a device which he inherits in a year)? So when he starts using Gentoo he can look up if the sw he needs is supported and go elsewhere if it is not, or actually contribute and do some stuff about it to make it work for himself. Basically our goal is to create good distribution for us. There is no goal to dominate market or something like that. Take a look on ubuntu, tons of people are using it but it does not help the development team because not much of those contribute back. We rather preffer people that actually can and contribute back. When looking on our stats the user counts seem quite same so we are not losing any user share lately, but on contributors side seems like people are just consuming than contributing back. And contributors are the only ones that are important as they help you in our job. Gentoo is not a distro with bigger resources I agree: If none of the developers is interested in a package, it is completely fine to declare it as unsupported and to require the user to maintain it himself (or hire somebody) if he wants to use it. Masking it is perfectly fine (maybe another idea would be to introduce some new state for such
Re: [gentoo-dev] Removals reply
On Sat, Feb 02, 2013 at 02:05:50PM +0100, Tomáš Chvátal wrote: Dne So 2. února 2013 12:44:30, Vaeth napsal(a): When I came to Gentoo many years ago, this was a very rare problem, but the removal of packages has tremendously increased, and it is not only me who is observing this problem - there were already some threads in the forums, and people planning to but not coming back to Gentoo for this reason. Awesome so they could've get involved and maintain it themselves if they seen it so crushial for their lives. Agreed. That's why there are last rights announcements with a 30 day delay before the package is actually removed. That is also why we allow people to proxy-maintain packages. In a nutshell, the people complaining about removals should stop complaining and start volunteering to maintain either the packages, or set up some place on github or some other service and maintain the software so we can package it. William pgpZjlppunND1.pgp Description: PGP signature
Re: [gentoo-dev] Removals reply
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/2013 01:49 PM, William Hubbs wrote: On Sat, Feb 02, 2013 at 02:05:50PM +0100, Tomáš Chvátal wrote: Dne So 2. února 2013 12:44:30, Vaeth napsal(a): When I came to Gentoo many years ago, this was a very rare problem, but the removal of packages has tremendously increased, and it is not only me who is observing this problem - there were already some threads in the forums, and people planning to but not coming back to Gentoo for this reason. Awesome so they could've get involved and maintain it themselves if they seen it so crushial for their lives. Agreed. That's why there are last rights announcements with a 30 day delay before the package is actually removed. That is also why we allow people to proxy-maintain packages. In a nutshell, the people complaining about removals should stop complaining and start volunteering to maintain either the packages, or set up some place on github or some other service and maintain the software so we can package it. This could not possibly be more well said. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRDWKdAAoJEKXdFCfdEflKa/QP/j7Y53Wj9nP/9JwYsdTRcUf+ Wojz4UWTBHAW+YIRyqmklmevCvB3/6yJ7STVKeFf8zHpqZqJkgbDKfcJefBeKKWD zQ8rH3tuiZ8MXz/uxFOeUKFaEnMKCu9CUwBf/oRgJZjXMa1NlkRu5Rh6OiMB4vci HdD/6XSMkc0PEwIqS+Hi5P+joVwVZE70Jqm5ItG3CnCKLY0PdWdPp+vrcKsssbLW CMP8wEJ7eh63oDMaKfLUAR/huFAxZwofmFhmjIlf0Ax6xFvBwf2HK81PqTHCNWiW LU7FDfBVmeCndFJkxY76wyamInbxb/VnNIUNIqe4vN17p9P5ZIys/IOVsZSyMQM7 4KIz9yumwQrFyAqxqjk0iDd+/ScyzeaEpxXziAbNhw/7RpJzdmuAOoqzVdPBZpxt rB3OsMVKnu73z8W+XjQdwF4v0Xbkaxh+s5q7xNgAHV09v9pGkLffJmmKO3ccSBdd H7JUK4BcrOOy8nSuLBM87bkDa0Yud3s/kWUwdqQqOozUkz4Ks5FUhmHd+smeJfzo B+jAC7fFdhagUZeeG01xAnfWg+S67ZSBFJChWzkWDEE+0vn0/Eq1yoEpRQeJicG1 JMiLjJTW2J0Mt2sntlOrSaIMMe3l/Y/r6f51rPEcep4kCEE1/wFcbLRQBCQh+ebj OmIx8P1jMky34Zov1rBf =4CHN -END PGP SIGNATURE-
Re: [gentoo-dev] Removals reply - please write adequate log messages!
Am Freitag, 1. Februar 2013, 14:53:19 schrieb Tomáš Chvátal: just to be sure here Removals are completely up to the maintainer to decide, with expection of QA removal where the package must be already broken to get punted. If you as developers and users find some package useful you can retake the maintainership (or became proxy-maint) which also expects you to take care of the bugs (QA can prune it even if you take the maintainership but ignore failures [even if your personal feeling is that it is corner case, it is for QA to deicde]). I agree 100% that we should not accumulate cruft in the tree and that removals are necessary. Please however, *** write meaningful log or mask messages *** !!! Old and uses IMake is not really a reason for treecleaning. Fortify crash on start and unuseable on fast machines definitely is. Cheers, A -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Removals reply
Sorry, but I feel that I must explain once more: When I came to Gentoo many years ago, this was a very rare problem, but the removal of packages has tremendously increased, and it is not only me who is observing this problem - there were already some threads in the forums, and people planning to but not coming back to Gentoo for this reason. Awesome so they could've get involved and maintain it themselves if they seen it so crushial for their lives. Agreed. That's why there are last rights announcements with a 30 day delay before the package is actually removed. So this 30 day delay will enable these people to get involved, especially for all the packages which were removed in the last years? Now it is apparent that an archive for dropped packages (in the form of keeping masked packages or some other form) is not needed: I want to join your club with the time machine! In a nutshell, the people complaining about removals should stop complaining and start volunteering to maintain either the packages Yep! That's the right attitude: Give the people 30 days (even those people who are currently not at Gentoo for whatever reason) to know years in advance all the software they might ever need and tell them, if in doubt, just to maintain hundreds of packages! It is *of course* their fault if they do not! Later, if they need a package, you can blame them that they have not voluntereered for all these packages they possibly might have needed, because years ago they had 30 days time to think about it (even longer if they took the time and resources to backup on their machines all tarballs of all packages). To be serious: If somebody *has* the resources to backup all dropped tarballs, he should please donate these resources to Gentoo, because Gentoo nowadays definitely cannot afford to waste a byte. Or how else can it be explained that this idea of enabling people to use previous packages if they need to is fought so intensively? All it costs is some amount of disk/mirror space. Or is it really that you *want* to blame the user and put pressure on him to maintain packages? Strange that as soon as user's resources are required, Gentoo's attitude was always quite the opposite: E.g. it just *always* installs bash completion or systemd files (or previously also static libraries, although I must admit that the situation for the latter was now improved, fortunately) - the user must care about cleaning for himself if he does not want to waste resources. Sure, both is an admissible attitude - only the user is responsible for everything. It is just: *I* want to contribute only to a distribution which also cares somewhat about the users. Maybe some developers feel the same, but it is of course up to you to decide this. Regards Martin
Re: [gentoo-dev] Removals reply
On Sun, 2013-02-03 at 06:07 +0100, Vaeth wrote: So this 30 day delay will enable these people to get involved, especially for all the packages which were removed in the last years? Now it is apparent that an archive for dropped packages (in the form of keeping masked packages or some other form) is not needed: I want to join your club with the time machine! If you want an automatic archive for dropped packages, MAKE ONE! Get a domain name, rent a VPS with lots of disc space, subscribe a mail account to gentoo-dev, write a small script that parses last-rites announcements and automatically archives the affected ebuilds and their sources. You have to realize that there are only three ways to get something done in the non-commercial open-source space: 1. convince someone else that it's fun; 2. convince someone else that it's important; or 3. do it yourself. We the Gentoo developers strongly believe that this project is not fun and not important. So if want dropped packages to be automatically archived, I suggest that you volunteer for the job of automatically archiving them. -Alexandre.
Re: [gentoo-dev] Removals reply
On Sat, Feb 2, 2013 at 9:07 PM, Vaeth va...@mathematik.uni-wuerzburg.de wrote: Sorry, but I feel that I must explain once more: When I came to Gentoo many years ago, this was a very rare problem, but the removal of packages has tremendously increased, and it is not only me who is observing this problem - there were already some threads in the forums, and people planning to but not coming back to Gentoo for this reason. Awesome so they could've get involved and maintain it themselves if they seen it so crushial for their lives. Agreed. That's why there are last rights announcements with a 30 day delay before the package is actually removed. So this 30 day delay will enable these people to get involved, especially for all the packages which were removed in the last years? Now it is apparent that an archive for dropped packages (in the form of keeping masked packages or some other form) is not needed: I want to join your club with the time machine! Gentoo has been running for over 10 years without it, so I would argue it is not *needed*. Would it be nice? Sure! No one is saying 'hey your idea sucks!' We are saying 'hey we are not really interested in doing this, but you should feel free to do it yourself, and we would think it is cool and totally support you.' In a nutshell, the people complaining about removals should stop complaining and start volunteering to maintain either the packages Yep! That's the right attitude: Give the people 30 days (even those people who are currently not at Gentoo for whatever reason) to know years in advance all the software they might ever need and tell them, if in doubt, just to maintain hundreds of packages! I don't believe for a second that it is the role of Gentoo to have packaged 'any software the user might have ever needed, or will ever need.' I'm unsure if this is the point you are making? It is *of course* their fault if they do not! Later, if they need a package, you can blame them that they have not voluntereered for all these packages they possibly might have needed, because years ago they had 30 days time to think about it (even longer if they took the time and resources to backup on their machines all tarballs of all packages). To be serious: If somebody *has* the resources to backup all dropped tarballs, he should please donate these resources to Gentoo, because Gentoo nowadays definitely cannot afford to waste a byte. It has nothing to do with disk space. The tree has software packages in it. I would argue that *most* of the software: 1) Has someone in Gentoo to maintain it. 2) Has a herd in Gentoo to maintain it. 3) Has a proxy-maintainer outside of Gentoo and a dev willing to commit on behalf of that person to maintain it. A minority of the software available is un-maintained. When I started the treecleaner project, I wanted all the software in the tree to have a maintainer; packages that had no maintainer would be removed. This was basically voted down by the Gentoo Community. Instead we adopted a less aggressive policy: http://www.gentoo.org/proj/en/qa/treecleaners/policy.xml Treecleaners also quasi-manage maintainer-needed packages. http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml Note that there are currently 734 packages 'assigned' to maintainer needed. When I created the treecleaners project I really tried to make the policies very straightforward so that when maskings occurred that users would not be confused as to why the package was being removed, and I also tried to make it clear how a user or developer could 'save' a package. Or how else can it be explained that this idea of enabling people to use previous packages if they need to is fought so intensively? Again I don't think anyone dismisses the idea. The problem is implementing it is perhaps not as trivial as you think. If I pick on the git migration as an example; we have essentially been 'trying to migrate to git' for like 2 years. That is going very slowly, even though everyone is basically on board with the idea. This is not a small agile project. Very often you need folks in the community willing to drive things to completion. mgorny's work on python-r1.eclass and his multilib stuff is one recent example. I think what you have failed to do is find someone in the developer community who is really eager to implement your idea. All it costs is some amount of disk/mirror space. Or is it really that you *want* to blame the user and put pressure on him to maintain packages? Why do you want to put pressure on *me* to maintain software I do not want to maintain? Or put pressure on *Gentoo* to mirror someones source code or binaries, for software Gentoo are no longer interested in distributing? Strange that as soon as user's resources are required, Gentoo's attitude was always quite the opposite: E.g. it just *always* installs bash completion or systemd files (or previously also static libraries, although I
[gentoo-dev] Removals reply (I am not going to figure out which tread of those all should i reply to)
Hello guys, just to be sure here Removals are completely up to the maintainer to decide, with expection of QA removal where the package must be already broken to get punted. If you as developers and users find some package useful you can retake the maintainership (or became proxy-maint) which also expects you to take care of the bugs (QA can prune it even if you take the maintainership but ignore failures [even if your personal feeling is that it is corner case, it is for QA to deicde]). For dead upstream packages there are quite few problems you, who support keeping it in tree, seem not to notice. The distro patches will blob up (with each distro having different stuff) as things break with shiny new updates (and no saying it builds with older xyz does not make it work), users have no chance to report problems with the package elsewhere than to our bugzilla, etc, etc. This is the reason why the fedorahosted.org was fired up. So if you care about the package, take your time, fire up VCS/homepage/tracker there and try to work on it or find someone else interested to help you with becaming at least pseodo-upstream. Cheers Tom
Re: [gentoo-dev] Removals reply (I am not going to figure out which tread of those all should i reply to)
On Fri, Feb 1, 2013 at 8:53 AM, Tomáš Chvátal tomas.chva...@gmail.com wrote: If you as developers and users find some package useful you can retake the maintainership (or became proxy-maint) which also expects you to take care of the bugs (QA can prune it even if you take the maintainership but ignore failures [even if your personal feeling is that it is corner case, it is for QA to deicde]). Citation? I don't see any GLEPs or other Council-approved policies to that effect. And this is of course why nobody actually wants to maintain these packages - everybody is going to be looking over your shoulder because they've already decided that the existence of the package bothers them. Honestly, threads like this bug me so much that I'm half-tempted to take over maintainership of one of these packages just to be a test case... Ugh - time for an email break... Rich
Re: [gentoo-dev] Removals reply
If security bugs occur then there's two options -- fix, or remove. (Or maybe mask with message clearly indicating security issues or warn about possibly unknown security issues). I agree. But security bugs are really relevant only for a rather limited types of packages: Those which are SUID (or have caps) or automatically called by other programs and reading untrusted data: Libraries (or used as such like movie players, viewers etc), or programs tightly coupled to the net (browsers, net games, etc). So e.g., I completely agree with masking xpdf for security reasons if nobody wants to care about security issues, although this does not necessarily mean that it has to be removed from the tree. However, for all other packages I mentioned, e.g. simple games (I was not speaking about net games), security issues are not security relevant: It is really the user's fault if he feeds them untrusted data, and in this case the user's data can be harmed. This he should know in advance, anyway. Regards Martin
Re: [gentoo-dev] Removals reply (I am not going to figure out which tread of those all should i reply to)
2013/2/1 Rich Freeman ri...@gentoo.org: On Fri, Feb 1, 2013 at 8:53 AM, Tomáš Chvátal tomas.chva...@gmail.com wrote: If you as developers and users find some package useful you can retake the maintainership (or became proxy-maint) which also expects you to take care of the bugs (QA can prune it even if you take the maintainership but ignore failures [even if your personal feeling is that it is corner case, it is for QA to deicde]). Citation? I don't see any GLEPs or other Council-approved policies to that effect. You my friend are slowly pissing me of as I read through all the flames you cause on -dev. There is no council vote required as it is already defined within qa team specs (and glep too when i think of it, so yep there is glep for you). And this is of course why nobody actually wants to maintain these packages - everybody is going to be looking over your shoulder because they've already decided that the existence of the package bothers them. No, they won't get anyone looking over their shoulder unless they decide to neglect the bugs as few maintainers did. I didn't see a lot forced removals caused by qa, did you? The existence of the package usually does not bother anyone, maintainer just decided that its burden so it will be removed, he could've put it to m-n but its up to every maintainer to decide what to do if the package has bugs he deem serious. If anyone else decide to pick up where they left, it is his job to ensure the package gets fixed and up-par to work nicely. Bit ago we had this discussion about keeping broken shit in tree masked or just prune it, and obvious solution was to remove it as there is just few of us and if anyone wants to start where we left he can pick out the ebuild from attic and put into his own overlay where it might work for him or even put it back to tree fixed. Honestly, threads like this bug me so much that I'm half-tempted to take over maintainership of one of these packages just to be a test case... Ugh - time for an email break... Go for it, i wrote exactly what to do, create vcs/tracker/homepage and it can stay.
Re: [gentoo-dev] Removals reply (I am not going to figure out which tread of those all should i reply to)
On 01/02/2013 18:00, Tomáš Chvátal wrote:
No, they won't get anyone looking over their shoulder unless they
decide to neglect the bugs as few maintainers did.
I didn't see a lot forced removals caused by qa, did you?
As far as I can tell, they come down to two:
- webmin; which was saved after a masking and ended up not going
anywhere, as most of the bugs (most security-related due to the nature
of webmin!) were still around months after the unmask;
- ${forgothename} which Robbins claimed he fixed in five minutes and
our QA was bad — where his fix was exchanging a build-time failure with
a runtime abort, and thus was kicked just as fine;
You could possibly add the damn squeezebox software that even Logitech
discontinued, but for that I'd just refer to the previous flame which
for my side boiled down if you want to keep it around, mask the fucker
because it's crap.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Removals reply
[...] and if anyone wants to start where we left he can pick out the ebuild from attic and put into his own overlay where it might work for him or even put it back to tree fixed. And this is exactly what *cannot* be done after a while: The ebuild is still available by CVS (or maybe git in future), but if there were already a lot of gentoo patches, the tarball with these patches is lost forever. If even upstream is dead, not even the main tarball will be available anymore. Go for it, i wrote exactly what to do, create vcs/tracker/homepage and it can stay. And what if somebody decides to do so in a year? E.g. if somebody gets some hardware in a year and needs support of a package which was removed? Or if he was not yet a gentoo user at the time when the package was removed (or absent/busy for a long period)? Then he is lost unless a distribution with bigger resources as gentoo has decided to keep the package. Not really a selling point for gentoo.
Re: [gentoo-dev] Removals reply
Dne Pá 1. února 2013 18:40:32, Vaeth napsal(a): [...] and if anyone wants to start where we left he can pick out the ebuild from attic and put into his own overlay where it might work for him or even put it back to tree fixed. And this is exactly what *cannot* be done after a while: The ebuild is still available by CVS (or maybe git in future), but if there were already a lot of gentoo patches, the tarball with these patches is lost forever. If even upstream is dead, not even the main tarball will be available anymore. Oh but it can mostly these archaic packages do not have patchsets. You still can count the packages using huge patchsets using just your hands. Also there is proposal to create git repository with patches exactly for this purposes. So bribe infra people with cookies to focus on it and you will get your stuff done :-) Go for it, i wrote exactly what to do, create vcs/tracker/homepage and it can stay. And what if somebody decides to do so in a year? If you are person who didn't touch his Gentoo box within a year hire some guy to maintain it. Seriously after a year without syncing and checkign the masks it is just walking security hole. E.g. if somebody gets some hardware in a year and needs support of a package which was removed? Well we never remove stuff right away, so we can say someone get hardware that is at least decade old, honestly just obtain distros build around such HW (like debian stable). Or if he was not yet a gentoo user at the time when the package was removed (or absent/busy for a long period)? Well he would found out after sync that it is removed, but he still can have it on his system, not available package does not mean that you have to uninstall it from that box. Then he is lost unless a distribution with bigger resources as gentoo has decided to keep the package. Not really a selling point for gentoo. Gentoo is not a distro with bigger resources, there is only few developers working on everything (yeah we show that 250 devs are still around, but question is how much of those are active). If you want real support you can always go for paid distros (thats their purpose, to support stuff where OSS is out of loop). PS: threading is broken in your mail client. or I dunno why this reply appeared out of thread.
