On 17/12/14 09:32, Ido Rosen wrote:
Agreed that everything in "core" should be maximally stable. (Also, following upstream stable releases rather than unstable releases fits just fine with Arch's philosophy of following upstream releases, since unstable releases are really just poorly named release candidates, which we don't usually follow.)
TBH, your argument is a red herring. Arch is about K.I.S.S. and following upstream as close to current as *upstream stable releases* allow. There have been occasions when what you propose has happened, mostly due to the chronic lack of developer hands and time. I can recall the headache it was to move from guile 1.8 to 2.x a little longer than a year ago.
Given that gpg is such a crucial core component of Arch's infrastructure and that gpg 2.1 is NOT stable. Could we switch back to gnupg 2.0.x (stable release) and create a gnupg-modern or gnupg21 package to track gnupg 2.1.x, which should be installable side-by-side with gnupg stable (perhaps with gpg21 as the binary name).
Instead, why not donate to gnupg.org so that the software is truly stable and evolves quickly? One underpaid (and underfed!) developer doesn't give any assurance about the future of the project and the software itself.[1] TL;DR: gnupg's situation is such that the OpenSSL project before the Heartbleed incident looks like a bunch of rich kids clubbing in Ibiza.
[1] https://news.ycombinator.com/item?id=8761896 -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre
