[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
Jeroen Roovers posted on Sun, 31 Oct 2010 18:36:25 +0100 as excerpted: [Duncan wrote...] However, Gentoo policy has always been that even ~arch is only upstream- stable packages, the ~arch keyword denoting Gentoo package testing (basically, the ebuild script and dependencies), /not/ upstream testing. In with certain exceptions, in particular for packages where Gentoo itself is upstream, if it's not a package that could at least in theory be Gentoo- stable if no bugs appear during the 30-day standard stabilizing period, it's not supposed to be ~arch keyworded either. This doesn't even make sense. Well, then, perhaps the developer handbook and devmanual versions make sense to you: Developer Handbook: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1#doc_chap4 1.d QA policy, under ~ARCH in KEYWORDS There is a difference between using package.mask and ~arch for ebuilds. The use of ~arch denotes an ebuild requires testing. The use of package.mask denotes that the application or library itself is deemed unstable. For example, if gimp-1.2.0 is the stable release from Gimp developers, and a new bug fix release is available as 1.2.1, then a developer should mark the ebuild as ~arch for testing in portage because the release is deemed to be stable. In another example, if Gimp decides to release an unstable/development series marked as 1.3.0, then these ebuilds should be put in package.mask because the software itself is of development quality and is not recommended by the developers for distribution. Devmanual: http://devmanual.gentoo.org/keywording/index.html The different levels of keyword are: arch (x86, ppc-macos) Both the package version and the ebuild are widely tested, known to work and not have any serious issues on the indicated platform. ~arch (~x86, ~ppc-macos) The package version and the ebuild are believed to work and do not have any known serious bugs, but more testing is required before the package version is considered suitable for arch. As I said, ~arch keywords denote Gentoo package testing, /not/ upstream testing. ~arch should be stable upstream, or it belongs in package.mask, not ~arch. (In practice, there are exceptions, the biggest one being where Gentoo's the upstream, such as with portage itself. The reasoning as I understand it is that upstream needs testing to stabilize, and since Gentoo's it's own upstream in these cases...) So there is indeed /some/ developer responsibility for maintaining a reasonably stable system, even for ~arch. If it's known-broken or upstream is deliberately labeling it beta and saying it's not ready for general use, it doesn't belong in ~arch either, but rather in package.mask. So here's your original statement to which I took issue: I didn't push it on all users. Maybe ~arch users, but they get to keep the pieces when they break their systems, if I recall correctly. My reply: To some extent, yes[, however, Gentoo policy, the top quote above] To which you say: No, to the full extent. The point that I'm making is that the clear Gentoo policy as outlined in the quotes above, is that if it's known broken, upstream beta clearly not intended for general usage yet, or hasn't been tested by the committing dev, it's that dev's responsibility. Thus, the to some extent on the ~arch users get to keep the pieces bit. It's known to be less well tested and in fact is ~arch for the /purpose/ of getting that testing, but if there are known serious issues, or if upstream itself doesn't call it ready for general distribution, in general, it shouldn't be in ~arch at all, but in package.mask. That's the clearly stated policy, whether it makes sense to you or not. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
On Mon, 1 Nov 2010 10:34:21 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Well, then, perhaps the developer handbook and devmanual versions make sense to you: Stop throwing the book at me, please. jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
On Sat, 30 Oct 2010 09:44:42 +0400 Peter Volkov p...@gentoo.org wrote: Also speaking about this specific package: I've maintained this package quite long time and I'm following upstream mailing list and I've never heard from upstream it's safe to push betas on all users. I didn't push it on all users. Maybe ~arch users, but they get to keep the pieces when they break their systems, if I recall correctly. jer
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
Jeroen Roovers posted on Sat, 30 Oct 2010 19:40:45 +0200 as excerpted: On Sat, 30 Oct 2010 09:44:42 +0400 Peter Volkov p...@gentoo.org wrote: Also speaking about this specific package: I've maintained this package quite long time and I'm following upstream mailing list and I've never heard from upstream it's safe to push betas on all users. I didn't push it on all users. Maybe ~arch users, but they get to keep the pieces when they break their systems, if I recall correctly. To some extent, yes. However, Gentoo policy has always been that even ~arch is only upstream- stable packages, the ~arch keyword denoting Gentoo package testing (basically, the ebuild script and dependencies), /not/ upstream testing. In with certain exceptions, in particular for packages where Gentoo itself is upstream, if it's not a package that could at least in theory be Gentoo- stable if no bugs appear during the 30-day standard stabilizing period, it's not supposed to be ~arch keyworded either. That's an important distinction to make. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
В Птн, 29/10/2010 в 06:03 +, Jeroen Roovers (jer) пишет: jer 10/10/29 06:03:08 Modified: ChangeLog Added:tcpreplay-3.4.5_beta2.ebuild Log: Beta version bump, fixes buffer overflow (bug #336605). Please, hard mask beta versions. To fix this bug it's not hard to backport patch (patch referenced in bug) and this will give us good version to stabilize. Really don't abuse beta versions. -- Peter.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
Il giorno ven, 29/10/2010 alle 12.12 +0400, Peter Volkov ha scritto: Please, hard mask beta versions. To fix this bug it's not hard to backport patch (patch referenced in bug) and this will give us good version to stabilize. Really don't abuse beta versions. It vastly depends how beta the beta version is, so it's up to the maintainer deciding that. Sometimes .0 versions are just as bugged as _beta for others. -- Diego Elio Pettenò — “Flameeyes” http://blog.flameeyes.eu/ If you found a .asc file in this mail and know not what it is, it's a GnuPG digital signature: http://www.gnupg.org/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
On Fri, 29 Oct 2010 12:12:38 +0400 Peter Volkov p...@gentoo.org wrote: В Птн, 29/10/2010 в 06:03 +, Jeroen Roovers (jer) пишет: jer 10/10/29 06:03:08 Modified: ChangeLog Added:tcpreplay-3.4.5_beta2.ebuild Log: Beta version bump, fixes buffer overflow (bug #336605). Please, hard mask beta versions. To fix this bug it's not hard to backport patch (patch referenced in bug) and this will give us good version to stabilize. Really don't abuse beta versions. I see you've done that already. jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
On Fri, 29 Oct 2010 12:12:38 +0400 Peter Volkov p...@gentoo.org wrote: Please, hard mask beta versions. I personally don't see a reason why he needed to do that. If a particular package was a popular one and/or the beta version changed a lot which might imply a lot of users getting trouble due to it, then I would agree. Please notice that 'beta' is not the same for each upstream. There are indeed packages which are in 'beta' state for the time being -- would you like all of them to be hard masked? Or maybe you're fine with them because they don't put 'beta' in their PV? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
On Fri, Oct 29, 2010 at 07:29:07PM +0200, Micha?? G??rny wrote: On Fri, 29 Oct 2010 12:12:38 +0400 Peter Volkov p...@gentoo.org wrote: Please, hard mask beta versions. I personally don't see a reason why he needed to do that. If a particular package was a popular one and/or the beta version changed a lot which might imply a lot of users getting trouble due to it, then I would agree. I don't know or use this package, but I agree. Just because something is beta doesn't mean it should be automatically hard masked. That decision should be left to the maintainer. William pgpsGU0GuTPuQ.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
В Птн, 29/10/2010 в 19:29 +0200, Michał Górny пишет: On Fri, 29 Oct 2010 12:12:38 +0400 Peter Volkov p...@gentoo.org wrote: Please, hard mask beta versions. I personally don't see a reason why he needed to do that. If a particular package was a popular one and/or the beta version changed a lot which might imply a lot of users getting trouble due to it, then I would agree. If the package is not popular there is even more reasons to rely on the upstream's judgment and hard mask betas. Please notice that 'beta' is not the same for each upstream. There are indeed packages which are in 'beta' state for the time being -- would you like all of them to be hard masked? Until you have explicit go for it from upstream or there is no real pressure to use betas, please, hard mask them. Or maybe you're fine with them because they don't put 'beta' in their PV? I'm fine in case upstream released package for general usage and we use them. I'm not fine in case package name suggests that package is for testing but we push it on users. Beta is beta. And for the sake of discussion I already had not so nice talks with upstream about Gentoo and beta versions we push on users... So this request is not out of the air. -- Peter.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-analyzer/tcpreplay: ChangeLog tcpreplay-3.4.5_beta2.ebuild
В Птн, 29/10/2010 в 17:51 +0200, Diego Elio Pettenò пишет: Il giorno ven, 29/10/2010 alle 12.12 +0400, Peter Volkov ha scritto: Please, hard mask beta versions. To fix this bug it's not hard to backport patch (patch referenced in bug) and this will give us good version to stabilize. Really don't abuse beta versions. It vastly depends how beta the beta version is, so it's up to the maintainer deciding that. Yup. But then, please, tell what were the reasons for this decision (in ChangeLog or inside ebuild). If there are no reasons - hard mask it. Also speaking about this specific package: I've maintained this package quite long time and I'm following upstream mailing list and I've never heard from upstream it's safe to push betas on all users. -- Peter.
