On Fri, Mar 28, 2014 at 1:14 AM, Andrea Scarpino <andrea@archlinux.org> wrote:
On Mon 24, March 15:02:53 Gaetan Bisson wrote:
Personally, although I think the AUR is a valuable service and that you shouldn't be assuming its costs and maintenance alone, I'm not sure if making it official would be a good thing (TM) in terms of encouraging users to downgrade packages rather than reporting bugs and upgrading cleanly when things break.
I want to quote Gaetan and Dave here. I fear that making ARM "official" or "semi-official" we unconsciously boost single packages downgrade.
I absolutely agree that we must make it abundantly clear that partial upgrades/downgrades are not supported. Never have been, and never will be. Apart from keeping this in mind when making any public statements on this subject (to avoid giving false expectations) I don't think it is a show-stopper though. If people do stupid things they get to keep the pieces when stuff breaks. We shouldn't let the fear of stupid people being stupid hinder our development. Another important point is that downgrading your whole system means you don't get any security upgrades or bug fixes, so in that sense it is not supported. In precisely the same way not upgrading your system is not supported. That said, I do think the ARM (or whatever its new name will be) is a really crucial service given our development model. We are on the bleeding edge, and our QA is more or less nonexistent. Surprisingly the quality of our packages is still very high (at least in my experience), but we do of course occasionally let the some buggy package slip through to core/extra/community. When this happens, the reasonable thing for a user to do is to file a bug and downgrade the package until the bug has been fixed. However, we don't support partial downgrades (at all, it would be a really, really stupid thing to do), so the only reasonable thing to do is to downgrade the whole system to a previously known good state (which is usually the state of the archives just before the offending package was updated). Doing this now is actually a real pain, as the user may not have all the necessary packages in their local cache, and even if they do, they can't easily know which packages to downgrade to what version. Another concern I have seen raised in the past is that if we make it simple to downgrade to temporarily avoid buggy packages, we will get fewer bug reports. I don't think that is a valid argument, rather we'd discourage users from upgrading frequently, or from using Arch at all. The argument is similar to a filesystem developer refusing to ship a fsck tool as it would allow people to fix their broken filesystems without filing bugs first... Having the ARM service (or something like that) with all the necessary caveats and warnings, makes it simple to force-downgrade to a given point in time, allowing users a reasonable fallback-mode in case some crucial package breaks on upgrade (and I mean crucial in the sense that it is something the user urgently needs, not in the sense that it is in [core], it could easily be a text editor, music player or web browser). So, in conclusion, I fully support adding such a service under the archlinux.org domain, and hosted on Arch infrastructure. This is under the assumption that care is taken when communicating precisely what this does and does not entail and someone is volunteering to do the actual work (and that whoever is actually affected by it on the infrastructure side do not object). If hosting it on our infrastructure is a problem, I'd suggest we pick up the bill for the current hosting costs instead, but still assign it an arch domainname and consider it officially part of our project. I have no comments regarding the details when it comes to pricing or other resources, except to say that we don't necessarily need a very long history, if space poses a problem, and that the kind of expenses indicated seems well within what we can afford (though we should of course always be respectful of our donors and try to keep expenses down when possible). Cheers, Tom