Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Monday 29 of March 2010 09:30:38 Peter Volkov wrote: В Вск, 28/03/2010 в 07:47 +0200, Maciej Mrozowski пишет: No, seriously - given the fact that some of my packages were even stabilized without contacting me (app-misc/hal-cups-utils, app-admin/system-config- printer-common) If you know packages are broken why they were not hardmasked? If they have no problems what why it was bad idea to mark them stable? They are not broken, they're just not suitable. It's like stabilizing gcc-2.95 now, even when it won't work with some recent KDE/boost. hal-cups-utils is not a problem system-config-printer-common-1.1.13 is as it's being used by maybe incompatible now system-config-printer-kde from testing arch (I've raised those deps now), besides I wanted to wait for polkit-1 with this package (otherwise dbus newprinternotifications can be received only by root or require tweaking dbus conf to work out of the box . That's why kde- base/system-config-printer-kde and kde-base/printer-applet were intentionally left out from KDE-4.3.3 stabilization list. -- regards MM
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. Have you ever just considered closing the stabilization bug and ignoring the arch. If they take so long to mark your packages as stable why do you care about them enough to even attempt to stabilize anything on their arch.
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Sun, Mar 28, 2010 at 07:31:10PM +1300, Alistair Bush wrote: On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. Have you ever just considered closing the stabilization bug and ignoring the arch. If they take so long to mark your packages as stable why do you care about them enough to even attempt to stabilize anything on their arch. If the pkg isn't a leaf node, you wind up keeping older and older versions lingering across multiple pkgs to keep it from breaking stable. This is assuming that it's still heavily frowned upon to remove the only stable version available for a non-dead arch... ~harring pgpPnF5xnRygw.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Sun, 28 Mar 2010 07:47:27 +0200 Maciej Mrozowski reave...@gmail.com wrote: No, seriously - given the fact that some of my packages were even stabilized without contacting me (app-misc/hal-cups-utils, app-admin/system-config- printer-common) - I think it should be: Well you'd marked them ~arch, right? That means they're candidates to go stable. * solely up to the package maintainers to stabilize application on arches they're using or on any arch if package is arch-agnostic (optionally, but preferably with some peer review from other project members or arch team members). There are no arch agnostic packages. It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. How do you know it works if you don't test on the arch in question? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 28.3.2010 09:39, Ciaran McCreesh napsal(a): On Sun, 28 Mar 2010 07:47:27 +0200 Maciej Mrozowski reave...@gmail.com wrote: No, seriously - given the fact that some of my packages were even stabilized without contacting me (app-misc/hal-cups-utils, app-admin/system-config- printer-common) - I think it should be: Well you'd marked them ~arch, right? That means they're candidates to go stable. Yes, but last time i checked we have consensus that archies should wait onto maintainer to request the stabling. * solely up to the package maintainers to stabilize application on arches they're using or on any arch if package is arch-agnostic (optionally, but preferably with some peer review from other project members or arch team members). There are no arch agnostic packages. I can find some, for example kde-l10n O:P But you are right. It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. How do you know it works if you don't test on the arch in question? Basically you are saying that NONE tested that package on the arch until the stablerequest. That's quite wrong and it should mean that the arch should be ~ only, since they are stabling packages that they first tested the day they stable them. Tomas -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuvKa0ACgkQHB6c3gNBRYdaWACdGP3EvuvL3+GVXI8GBsU3fHqj Kq8AoJMyVDS8P0vCXfwJuGIIEQHWPgUL =CO3D -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On 03/28/2010 06:04 AM, Tomáš Chvátal wrote: Basically you are saying that NONE tested that package on the arch until the stablerequest. That's quite wrong and it should mean that the arch should be ~ only, since they are stabling packages that they first tested the day they stable them. Well, keep in mind that if a package is marked ~arch, it is getting used, but for the most part it isn't getting used with other packages that are stable. So, if your package is ~arch for a period of time that gives you strong evidence that it works with openrc, but no evidence as to whether it works with baselayout-1, which is what stable users have. So, I would argue that for any package to be stabilized on an arch it should be tested on that arch on a stable platform. amd64 has had the policy that any dev can stabilize if they've tested it on a stable amd64 system, and this hasn't really caused problems. Perhaps we should encourage understaffed arch teams to recruit more arch testers if possible? Then any dev could ask an arch tester to test on some platform that they don't have access to, and then stabilize accordingly? For arch-neutral packages a more liberal policy might be possible, but keep in mind that the set of stable packages is not the same across archs. So, unless you check carefully you might not be testing the same library dependency versions from one stable platform to another, and that could cause problems. Rich
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Sunday 28 of March 2010 09:39:18 Ciaran McCreesh wrote: It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. How do you know it works if you don't test on the arch in question? The problem is not waiting for some instert some exotic arch here to go stable so it would be possible to close bug and ignore arches. It's not about closing bug at all. The only inconvenience from exotic arches lagging is inability to remove particular old ebuild from tree, that's it. It's about having package marked stabled on my arch (amd64 in my case, may be other from other developer's perspective) in a timely manner. And I know it works on my arch because I test it and often use it on daily basis. On Sunday 28 of March 2010 13:32:59 Richard Freeman wrote: amd64 has had the policy that any dev can stabilize if they've tested it on a stable amd64 system, and this hasn't really caused problems. That would have certainly solved the problem if that policy was written and published anywhere. -- regards MM
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Sun, Mar 28, 2010 at 07:31:10PM +1300, Alistair Bush wrote: On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. Have you ever just considered closing the stabilization bug and ignoring the arch. If they take so long to mark your packages as stable why do you care about them enough to even attempt to stabilize anything on their arch. If they have old versions of the package stable on their arch, ignoring them wouldn't be the right answer either. That makes you keep the old versions around because the arch team isn't keeping up. William pgp2zGAP9huYO.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: On Sat, Mar 27, 2010 at 05:45:51PM +0100, Torsten Veller wrote: * Petteri R?ty betelge...@gentoo.org: So let's summarize for assigning to the single arch: In support (and my comments in support): - Can be used as a gentle reminder for slacker arches And if not only one arch or single arch is slacking? I guess you would find another gentle way to remind them. How about a tool generating mails to arch teams, which lists all STABLEREQ, KEQWORDREQ bugs to which the arch team is CC'ed for a month? (Or probably easier or possible at all: which weren't changed for 30 days.) I know that I have several bugs right now with minor arch's on them waiting to be stabilized. A couple have been waiting for a very long time. I have even pinged some of the bugs several times with no response. Is there anything else I can do to get these arch teams attention? Yes, I think getting from them the privilege of being the only ones able to stabilize applications should do the job. No, seriously - given the fact that some of my packages were even stabilized without contacting me (app-misc/hal-cups-utils, app-admin/system-config- printer-common) - I think it should be: * solely up to the package maintainers to stabilize application on arches they're using or on any arch if package is arch-agnostic (optionally, but preferably with some peer review from other project members or arch team members). * to arch team members in other cases (like now) * other rules (30 days 'waiting' period, bugzilla bug with STABLEREQ) applied as they are now Role of arch teams would be decreased to peer review and solving KEYWORD requests. It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. Comments? -- regards MM
