Re: Bodhi 0.7.5 release
On 07/06/2010 12:15 PM, Kevin Fenzi wrote: On Sat, 03 Jul 2010 19:55:27 +0200 Till Maasopensou...@till.name wrote: On Fri, Jul 02, 2010 at 10:33:04PM +0200, Till Maas wrote: On Fri, Jul 02, 2010 at 12:48:43PM -0600, Kevin Fenzi wrote: I have updated the page. Does it look clear now? Re-wording or tweaks very welcome. https://fedoraproject.org/wiki/Package_update_acceptance_criteria Btw. does Bodhi really work the way it is said there? What happens if there are +1 and -1 karma values for an critpath update? According to the criteria, -1 karma does not have any impact at all except for all other updates, because they contain a karma threshold. Interestingly the first critpath update I saw with f-e-k is not approved but should be according to the criteria: https://admin.fedoraproject.org/updates/F12/FEDORA-2010-9850 It doesn't have enough karma... it got: -1, +1, +1, for a total of 1. So, I guess it's not going to push without hitting +2. I've asked Luke to comment here and your parent post about how things work, as I would love to know too. ;) Right now for a critical path update to gain approval, it must have a net karma of at least 2, including a +1 from a proventester, and +1 from another authenticated user. This is the behavior that was implemented and utilized during the No Frozen Rawhide pre-release stage of F13. If we want to change this behavior, that's fine with me. Let's discuss alternative solutions. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Sat, 03 Jul 2010 19:55:27 +0200 Till Maas opensou...@till.name wrote: On Fri, Jul 02, 2010 at 10:33:04PM +0200, Till Maas wrote: On Fri, Jul 02, 2010 at 12:48:43PM -0600, Kevin Fenzi wrote: I have updated the page. Does it look clear now? Re-wording or tweaks very welcome. https://fedoraproject.org/wiki/Package_update_acceptance_criteria Btw. does Bodhi really work the way it is said there? What happens if there are +1 and -1 karma values for an critpath update? According to the criteria, -1 karma does not have any impact at all except for all other updates, because they contain a karma threshold. Interestingly the first critpath update I saw with f-e-k is not approved but should be according to the criteria: https://admin.fedoraproject.org/updates/F12/FEDORA-2010-9850 It doesn't have enough karma... it got: -1, +1, +1, for a total of 1. So, I guess it's not going to push without hitting +2. I've asked Luke to comment here and your parent post about how things work, as I would love to know too. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Sun, 2010-07-04 at 17:27 +0200, Michel Alexandre Salim wrote: On Sun, Jul 4, 2010 at 1:27 PM, Till Maas opensou...@till.name wrote: On Sun, Jul 04, 2010 at 12:34:59PM +0200, Michel Alexandre Salim wrote: On Sun, Jul 4, 2010 at 10:34 AM, Till Maas opensou...@till.name wrote: On Sun, Jul 04, 2010 at 01:32:16AM +0200, Michel Alexandre Salim wrote: Could a flag be added to only output the package names, so that I can pipe the output directly to yum? Or even better, have that flag automatically cause the bodhi client to invoke yum with --enable-repo=updates-testing with the packages required. You can just install all critpath updates using: yum groupinstall --enable-repo=\*-testing critical-path\* core and then use f-e-k from git with --critpath-only to get only asked for the unapproved ones. Ah! Would be great if this is listed on the QA page. If you know on which page it fits, just add it. I did not find a matching page when I swept through the QA pages. I don't -- Adam Williamson probably knows better. Adam? We have a page with general instructions for testing stuff in updates-testing: https://fedoraproject.org/wiki/QA/Updates_Testing and also a page of instructions for proven testers: https://fedoraproject.org/wiki/Proven_tester This is info that's probably useful for both, really. I certainly intended to extend the proven_tester page with instructions on the new functionality in f-e-k, as soon as it's available in a released f-e-k version (I really don't want to be bothering proventesters with suggestions to check their f-e-k out of git, so it'd be nice to have a new version pushed with the new features). We could certainly add the info on using yum to *install* only critpath updates too. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
Michael Schwendt wrote: One can quickly see that several (if not many) of them are due to orphans/retired packages in Fedora 12. And due to violated upgrade paths (e.g. compat-db): That just proves that we should avoid retiring packages, but try to keep them alive as long as we can, even if it's just rebuilds for new dependencies. == Broken packages in fedora-12-x86_64: 3:koffice-kivio-1.6.3-26.20090306svn.fc12.i686 requires koffice-core = 3:1.6.3-26.20090306svn.fc12 kdeedu-math-4.3.2-2.fc12.i686 requires libboost_python-mt.so.5 These are multilib problems. koffice-kivio and kdeedu-math are no longer multilib. But people should not have those installed as multilib anyway, since they're leaf packages. This just shows how the install everything as multilib option is harmful and we should finally stop supporting that nonsense completely (it stopped being the default in F9, thankfully). On all architectures: kdelibs-experimental-devel-4.3.5-1.fc12.i686 requires libknotificationitem-1.so.1 kdelibs-experimental-devel-4.3.5-1.fc12.i686 requires kdelibs-experimental = 0:4.3.5-1.fc12 This is because kdelibs-devel only Obsoletes kdelibs-experimental-devel on F12. pinentry-qt4-0.8.0-2.fc12.i686 requires pinentry = 0:0.8.0-2.fc12 Missing Obsoletes, I guess. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Sun, Jul 04, 2010 at 01:32:16AM +0200, Michel Alexandre Salim wrote: Could a flag be added to only output the package names, so that I can pipe the output directly to yum? Or even better, have that flag automatically cause the bodhi client to invoke yum with --enable-repo=updates-testing with the packages required. You can just install all critpath updates using: yum groupinstall --enable-repo=\*-testing critical-path\* core and then use f-e-k from git with --critpath-only to get only asked for the unapproved ones. Or if you apply this patch to bodhi: https://fedorahosted.org/bodhi/ticket/449 Then you can use: yum install --enable-repo=\*-testing $(bodhi 2/dev/null --critpath --untested --release F13 | cut -d -f 2) to achieve what you want. Also according to James Antill you can use yum install yum-filter-data plugin and then yum --filter-groups=critical-path\* --filter-groups=core update to install only the critpath updates that update packages on your system. But I did not yet test this. And I do not know how the two --filter-groups arguments behave, but unluckily core is currently a critical path comps group according to https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal#When_and_how_to_determine_packages_within_the_path :-/ I objected to this on the Talk page, so hopefully this will change. Regards Till pgpTEpOvaaibt.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
Broken deps in Fedora 13 + updates + updates-testing when also enabling Fedora 12 + updates + updates-testing. One can quickly see that several (if not many) of them are due to orphans/retired packages in Fedora 12. And due to violated upgrade paths (e.g. compat-db): Summary of broken packages (by src.rpm name): almanah bind-dyndb-ldap blacs bmpx bzr-gtk cjkuni-fonts compat-db dbxml dbxml-perl dnsperf eclipse-cdt gcc ghc-gtk2hs ghc-time gossip ibus-table kdeedu kdelibs-experimental koffice mrpt mysql netbeans orsa pdfcube pinentry qpidc scalapack sipwitch syncevolution tasks telepathy-feed xqilla10 == Broken packages in fedora-12-i386: blacs-lam-1.1-33.fc12.i686 requires blacs-common = 0:1.1-33.fc12 bmpx-0.40.14-15.fc12.i686 requires libboost_iostreams-mt.so.5 bmpx-0.40.14-15.fc12.i686 requires libboost_regex-mt.so.5 dbxml-2.4.16-0.5.fc12.i686 requires libxerces-c.so.28 dbxml-perl-2.0040016-2.fc12.i686 requires libxerces-c.so.28 dbxml-python-2.4.16-0.5.fc12.i686 requires libxerces-c.so.28 dbxml-utils-2.4.16-0.5.fc12.i686 requires libxerces-c.so.28 ghc-gtk2hs-compat-0.10.1-5.fc12.i686 requires ghc-glade-devel = 0:0.10.1-5.fc12 ghc-gtk2hs-compat-0.10.1-5.fc12.i686 requires ghc-gconf-devel = 0:0.10.1-5.fc12 ghc-gtk2hs-compat-0.10.1-5.fc12.i686 requires ghc-soegtk-devel = 0:0.10.1-5.fc12 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.i686 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.i686 requires ghc-prof = 0:6.10.4 gossip-0.31-3.fc12.i686 requires libedataserver-1.2.so.11 mrpt-monoslam-0.7.1-0.1.20090818svn1148.fc12.i686 requires libmrpt-hwdrivers.so.0.7 mrpt-monoslam-0.7.1-0.1.20090818svn1148.fc12.i686 requires libmrpt-core.so.0.7 netbeans-apisupport1-6.7.1-1.fc12.noarch requires netbeans-platform = 0:6.7.1 netbeans-apisupport1-6.7.1-1.fc12.noarch requires netbeans-platform-harness = 0:6.7.1 pdfcube-0.0.3-5.fc12.i686 requires libboost_program_options-mt.so.5 scalapack-lam-1.7.5-7.fc12.i686 requires scalapack-common = 0:1.7.5-7.fc12 sipwitch-php-swig-0.5.7-1.fc12.i686 requires sipwitch = 0:0.5.7-1.fc12 sipwitch-python-swig-0.5.7-1.fc12.i686 requires sipwitch = 0:0.5.7-1.fc12 tasks-0.16-2.fc12.i686 requires libedataserver-1.2.so.11 telepathy-feed-0.13-7.fc12.i686 requires libtelepathy.so.2 xqilla10-1.0.2-6.fc11.i586 requires libxerces-c.so.28 == Broken packages in fedora-12-x86_64: 3:koffice-kivio-1.6.3-26.20090306svn.fc12.i686 requires koffice-core = 3:1.6.3-26.20090306svn.fc12 blacs-lam-1.1-33.fc12.i686 requires blacs-common = 0:1.1-33.fc12 blacs-lam-1.1-33.fc12.x86_64 requires blacs-common = 0:1.1-33.fc12 bmpx-0.40.14-15.fc12.x86_64 requires libboost_iostreams.so.5()(64bit) bmpx-0.40.14-15.fc12.x86_64 requires libboost_regex.so.5()(64bit) dbxml-2.4.16-0.5.fc12.x86_64 requires libxqilla.so.4()(64bit) dbxml-2.4.16-0.5.fc12.x86_64 requires libxerces-c.so.28()(64bit) dbxml-perl-2.0040016-2.fc12.x86_64 requires libxqilla.so.4()(64bit) dbxml-perl-2.0040016-2.fc12.x86_64 requires libxerces-c.so.28()(64bit) dbxml-python-2.4.16-0.5.fc12.x86_64 requires libxqilla.so.4()(64bit) dbxml-python-2.4.16-0.5.fc12.x86_64 requires libxerces-c.so.28()(64bit) dbxml-utils-2.4.16-0.5.fc12.x86_64 requires libxqilla.so.4()(64bit) dbxml-utils-2.4.16-0.5.fc12.x86_64 requires libxerces-c.so.28()(64bit) ghc-gtk2hs-compat-0.10.1-5.fc12.x86_64 requires ghc-glade-devel = 0:0.10.1-5.fc12 ghc-gtk2hs-compat-0.10.1-5.fc12.x86_64 requires ghc-gconf-devel = 0:0.10.1-5.fc12 ghc-gtk2hs-compat-0.10.1-5.fc12.x86_64 requires ghc-soegtk-devel = 0:0.10.1-5.fc12 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 gossip-0.31-3.fc12.x86_64 requires libedataserver-1.2.so.11()(64bit) kdeedu-math-4.3.2-2.fc12.i686 requires libboost_python-mt.so.5 mrpt-monoslam-0.7.1-0.1.20090818svn1148.fc12.i686 requires libmrpt-hwdrivers.so.0.7 mrpt-monoslam-0.7.1-0.1.20090818svn1148.fc12.i686 requires libmrpt-core.so.0.7
Re: Bodhi 0.7.5 release
On Sun, Jul 04, 2010 at 12:34:59PM +0200, Michel Alexandre Salim wrote: On Sun, Jul 4, 2010 at 10:34 AM, Till Maas opensou...@till.name wrote: On Sun, Jul 04, 2010 at 01:32:16AM +0200, Michel Alexandre Salim wrote: Could a flag be added to only output the package names, so that I can pipe the output directly to yum? Or even better, have that flag automatically cause the bodhi client to invoke yum with --enable-repo=updates-testing with the packages required. You can just install all critpath updates using: yum groupinstall --enable-repo=\*-testing critical-path\* core and then use f-e-k from git with --critpath-only to get only asked for the unapproved ones. Ah! Would be great if this is listed on the QA page. If you know on which page it fits, just add it. I did not find a matching page when I swept through the QA pages. Regards Till pgp2yR1YiHfqh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
On Sun, Jul 04, 2010 at 12:31:57PM +0200, Michael Schwendt wrote: Broken deps in Fedora 13 + updates + updates-testing when also enabling Fedora 12 + updates + updates-testing. One can quickly see that several (if not many) of them are due to orphans/retired packages in Fedora 12. And due to violated upgrade paths (e.g. compat-db): I cannot see this quickly from this report! ;-) == Broken packages in fedora-12-x86_64: ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 Yum does not report any problem here when I try to install ghc-time-devel and ghc has the matching version: 6.10.4-2.fc12 Regards Till pgpdUR0NnGLnZ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
On Sun, 04 Jul 2010 13:32:14 +0200, Till wrote: On Sun, Jul 04, 2010 at 12:31:57PM +0200, Michael Schwendt wrote: Broken deps in Fedora 13 + updates + updates-testing when also enabling Fedora 12 + updates + updates-testing. One can quickly see that several (if not many) of them are due to orphans/retired packages in Fedora 12. And due to violated upgrade paths (e.g. compat-db): I cannot see this quickly from this report! ;-) == Broken packages in fedora-12-x86_64: ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4 ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4 Yum does not report any problem here when I try to install ghc-time-devel and ghc has the matching version: 6.10.4-2.fc12 Then you've not read the mail carefully enough. On F-13 you would see: $ yum list ghc-time\* Loaded plugins: auto-update-debuginfo, refresh-packagekit Error: No matching Packages to list $ repoquery --whatobsoletes ghc-time-devel $ repoquery --whatobsoletes ghc-time $ yum list ghc Loaded plugins: auto-update-debuginfo, refresh-packagekit Available Packages ghc.x86_64 6.12.1-5.fc13 fedora It's fairly easy to verify other broken deps, too: http://admin.fedoraproject.org/updates/compat-db-4.7.25-3.fc13 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
On Sun, Jul 04, 2010 at 02:06:08PM +0200, Michael Schwendt wrote:
On Sun, 04 Jul 2010 13:32:14 +0200, Till wrote:
On Sun, Jul 04, 2010 at 12:31:57PM +0200, Michael Schwendt wrote:
Broken deps in Fedora 13 + updates + updates-testing when
also enabling Fedora 12 + updates + updates-testing.
One can quickly see that several (if not many) of them are due
to orphans/retired packages in Fedora 12. And due to violated upgrade
paths (e.g. compat-db):
I cannot see this quickly from this report! ;-)
==
Broken packages in fedora-12-x86_64:
ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4
ghc-time-devel-1.1.2.4-2.fc12.i686 requires ghc = 0:6.10.4
ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4
ghc-time-devel-1.1.2.4-2.fc12.x86_64 requires ghc = 0:6.10.4
ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4
ghc-time-doc-1.1.2.4-2.fc12.x86_64 requires ghc-doc = 0:6.10.4
ghc-time-prof-1.1.2.4-2.fc12.x86_64 requires ghc-prof = 0:6.10.4
Yum does not report any problem here when I try to install
ghc-time-devel and ghc has the matching version: 6.10.4-2.fc12
Then you've not read the mail carefully enough. On F-13 you would see:
$ yum list ghc-time\*
Loaded plugins: auto-update-debuginfo, refresh-packagekit
Error: No matching Packages to list
$ repoquery --whatobsoletes ghc-time-devel
$ repoquery --whatobsoletes ghc-time
$ yum list ghc
Loaded plugins: auto-update-debuginfo, refresh-packagekit
Available Packages
ghc.x86_64 6.12.1-5.fc13
fedora
So I guess ghc needs to add some Obsoletes for
ghc-time{,-devel,-doc,-prof}? According to dead.package it is now
included in ghc:
http://cvs.fedoraproject.org/viewvc/rpms/ghc-time/devel/dead.package?revision=1.1view=markup
Would this be correct?
ghc:
Obsoletes: ghc-time 1.1.2.5
Obsoletes: ghc-time-devel 1.1.2.5
ghc-doc:
Obsoletes: ghc-time-doc 1.1.2.5
ghc-prof:
Obsoletes: ghc-time-prof 1.1.2.5
But what about provides, would it be
Provides: ghc-time-1.1.4-%{release} etc? Given that version 1.1.4 of
ghc-time is included in ghc?
It's fairly easy to verify other broken deps, too:
http://admin.fedoraproject.org/updates/compat-db-4.7.25-3.fc13
For me it is not that easy, because the information is confusion (or not
clearly arranged) or not directly accessible, e.g. to understand the
compat-db problems one needs to look at the koji page for the list of
built rpms. So here the release of compat-db needs to be increased to
11 in F13?
Regards
Till
pgphV2O3tQ2Lz.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
On Sun, 04 Jul 2010 14:40:20 +0200, Till wrote: It's fairly easy to verify other broken deps, too: http://admin.fedoraproject.org/updates/compat-db-4.7.25-3.fc13 For me it is not that easy, because the information is confusion (or not clearly arranged) or not directly accessible, e.g. to understand the compat-db problems one needs to look at the koji page for the list of built rpms. Hmmm ... most of the broken deps are of the form something requires something-unavailable where something-unavailable either has never existed before or is gone because of an update. One could attempt at writing code to automate checks that help with interpreting other results in the broken deps report. 1) Is something the newest (EVR)? If not, it would be an old multiarch package that is no longer multiarch. (Else, the repositories are broken and a later build of something is missing.) [1] 2) If something-unavailable is of the form key = value, does anything still provide key? If so, show latest EVR, and something will need an update, or is a missing obsolete, or is an old multiarch build that is missing a multiarch update. 3) If something-unavailable is a SONAME, try to find a similar SONAME and inform the library packager. This is not 100%, but is done already as in the Rawhide broken deps report. | Broken packages in fedora-updates-13-i386: | | compat-db-4.7.25-3.fc13.i686 requires compat-db46(x86-32) = 0:4.6.21-3.fc13 | compat-db-4.7.25-3.fc13.i686 requires compat-db45(x86-32) = 0:4.5.20-3.fc13 So here the release of compat-db needs to be increased to 11 in F13? -12.fc13, because compat-db45 and compat-db46 for F12 updates are -11.fc12 and newer than -3.fc13 [1] Some multiarch broken deps in F12 exist for a long time without the packagers showing interest in fixing them. That isn't anything like encouraging. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
On Sun, Jul 04, 2010 at 04:47:19PM +0200, Michael Schwendt wrote: On Sun, 04 Jul 2010 14:40:20 +0200, Till wrote: It's fairly easy to verify other broken deps, too: http://admin.fedoraproject.org/updates/compat-db-4.7.25-3.fc13 For me it is not that easy, because the information is confusion (or not clearly arranged) or not directly accessible, e.g. to understand the compat-db problems one needs to look at the koji page for the list of built rpms. Hmmm ... most of the broken deps are of the form something requires something-unavailable where something-unavailable either has never existed before or is gone because of an update. One could attempt at writing code to automate checks that help with interpreting other results in the broken deps report. 1) Is something the newest (EVR)? If not, it would be an old multiarch package that is no longer multiarch. (Else, the repositories are broken and a later build of something is missing.) [1] 2) If something-unavailable is of the form key = value, does anything still provide key? If so, show latest EVR, and something will need an update, or is a missing obsolete, or is an old multiarch build that is missing a multiarch update. 3) If something-unavailable is a SONAME, try to find a similar SONAME and inform the library packager. This is not 100%, but is done already as in the Rawhide broken deps report. For the non F13 repos: 4) something is retired, if it is renamed or merged into something else, obsoletes are missing, else it is not a problem afaik. In case something is retired, the script could e.g. show the contents of the respective dead.package. 5) if something is not retired, there is a upgrade path problem that should be fixed before it's called broken deps. Additionally the script could also tell if an affected package has been orphaned to show that nobody is taking care of it and maybe whether there is a newer version in CVS and whether it is built. This and maybe even more needs to be done manually anyhow. | Broken packages in fedora-updates-13-i386: | | compat-db-4.7.25-3.fc13.i686 requires compat-db46(x86-32) = 0:4.6.21-3.fc13 | compat-db-4.7.25-3.fc13.i686 requires compat-db45(x86-32) = 0:4.5.20-3.fc13 So here the release of compat-db needs to be increased to 11 in F13? -12.fc13, because compat-db45 and compat-db46 for F12 updates are -11.fc12 and newer than -3.fc13 Unless I am not spotting something special here, but 11.fc13 is newer than 11.fc12 and therefore 11 seems to be good enough. I opened a bug report about it: https://bugzilla.redhat.com/show_bug.cgi?id=611267 Regards Till pgpztvABjvSKv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
If there are any discrepancy with the proventesters critpath policy then please feel free to file a ticket with FESCo and allow our elected officials decide the fate of this. -AdamM (From Android) On Jul 2, 2010 8:16 PM, Kevin Kofler kevin.kof...@chello.at wrote: Will Woods wrote: The main reasons we want to perform testing are things like: to avoid pushing ... The right way to prevent that is to get AutoQA completed, which will, if it works as intended, automatically detect and throw out updates with broken dependencies without needlessly delaying all those updates which don't have broken dependencies. Once AutoQA is completed, the testing process will do NOTHING whatsoever to prevent broken dependencies because they wouldn't make it through AutoQA anyway. or updates that cause serious regressions requiring manual intervention / emergency update repl... No amount of testing is going to catch all such cases, and when it does happen, the testing requirements actually HINDER a quick fix, increasing the window of exposure to the bug and therefore making it affect many more users and for longer time. In fact, Kevin, given a set of metrics we're both happy with, I'd be willing to stake my subscr... No. Metrics just encourage working to the metric to game the system, and any improvement you measure from the new process might just be due to chance or to factors we aren't considering at all. Plus, do we even have the historical data to compare with, given that everything older than F12 is deleted from Bodhi? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listin... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
Adam Miller wrote: If there are any discrepancy with the proventesters critpath policy then please feel free to file a ticket with FESCo and allow our elected officials decide the fate of this. There isn't any such discrepancy, it's the policy which is broken and FESCo which refuses to understand the issues. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
On Fri, 2010-07-02 at 18:24 +0200, Ralf Corsepius wrote: On 07/02/2010 06:20 PM, Will Woods wrote: The main reasons we want to perform testing are things like: to avoid pushing updates with broken dependencies, or updates that cause serious regressions requiring manual intervention / emergency update replacements. That sort of thing. Should be done scripted as part of the package push process. No need for karmas, no need for provenpackager That only handles a subset of the 'broken dependencies' problem. We've already had an example this year of a dependency issue the proposed autoqa depcheck test wouldn't catch, and Michael's script didn't - the nss-softokn update (as the broken dep is only apparent if you take into consideration multilib issues and which repositories will have which updated packages available). Given Murphy's Law, I am willing to bet that, even when we have an automated dependency checker in place, someone will manage to push an update which causes a dependency problem which the automated test doesn't catch. Manual testing will help us catch that. And, again, though Will mentioned two types of broken update, you only considered one in your reply. Doesn't Michael Schwendt have a script for this? Yes. Is a script all you need to implement an automated step in the updaate push process? No. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
On Sat, 03 Jul 2010 10:05:07 -0700, Adam wrote: On Fri, 2010-07-02 at 18:24 +0200, Ralf Corsepius wrote: On 07/02/2010 06:20 PM, Will Woods wrote: The main reasons we want to perform testing are things like: to avoid pushing updates with broken dependencies, or updates that cause serious regressions requiring manual intervention / emergency update replacements. That sort of thing. Should be done scripted as part of the package push process. No need for karmas, no need for provenpackager That only handles a subset of the 'broken dependencies' problem. We've already had an example this year of a dependency issue the proposed autoqa depcheck test wouldn't catch, and Michael's script didn't - the nss-softokn update Which one was that? https://bugzilla.redhat.com/596840 ? (as the broken dep is only apparent if you take into consideration multilib issues and which repositories will have which updated packages available). There are multiple problems: * Upgrades from F12 to F13. The depcheck for F13 would need to enable F12 repos _always_ - to catch upgrade path violations that lead to dependency problems. I only do this a few times shortly before the release of FN+1 (=F13). * Yum depsolving behaviour on systems where multiarch packages are installed and an update isn't multiarch anymore. For example, where Yum on x86_64 would pull in lots of i686 packages to resolve dependencies, that would be considered a problem by the user but not by a depchecker, because there are no unresolvable dependencies to detect. Unless you teach the depsolver (and depchecker) that cross-arch dependencies are something to report as a problem. That would be more than repository closure. The depchecker doesn't look for file conflicts either. There could be a dependency chain, which doesn't suffer from unresolvable deps but from implicit file conflicts. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
On Sat, 2010-07-03 at 20:40 +0200, Michael Schwendt wrote: That only handles a subset of the 'broken dependencies' problem. We've already had an example this year of a dependency issue the proposed autoqa depcheck test wouldn't catch, and Michael's script didn't - the nss-softokn update Which one was that? https://bugzilla.redhat.com/596840 ? Yep. (as the broken dep is only apparent if you take into consideration multilib issues and which repositories will have which updated packages available). There are multiple problems: * Upgrades from F12 to F13. The depcheck for F13 would need to enable F12 repos _always_ - to catch upgrade path violations that lead to dependency problems. I only do this a few times shortly before the release of FN+1 (=F13). * Yum depsolving behaviour on systems where multiarch packages are installed and an update isn't multiarch anymore. For example, where Yum on x86_64 would pull in lots of i686 packages to resolve dependencies, that would be considered a problem by the user but not by a depchecker, because there are no unresolvable dependencies to detect. Unless you teach the depsolver (and depchecker) that cross-arch dependencies are something to report as a problem. That would be more than repository closure. The depchecker doesn't look for file conflicts either. There could be a dependency chain, which doesn't suffer from unresolvable deps but from implicit file conflicts. Yep, indeed. I'm really not criticising the script. I'm just pointing out that we know there are some pretty complex scenarios out there which we haven't yet figured out how to test in an automated way; I'm challenging the assumption that we can write a perfect depcheck test which will ensure there is never a dependency issue ever again. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, Jun 30, 2010 at 12:37 AM, Luke Macken lmac...@redhat.com wrote: Hi, I just pushed a version 0.7.5 of bodhi into production. This release contains the following notable changes: proventesters strict critical path update handling Critical path package[0] updates now require positive karma from two proventesters[1], and a single +1 from one other community member. You can get a list of critical path updates using the bodhi web interface: https://admin.fedoraproject.org/updates/critpath?release=F13untested=True You can optionally pass in a specific 'release' or an 'untested' flag, which will return a list of critical path updates that have yet to be approved. I have not added these links to the main interface yet, because at the moment they are fairly expensive calls. This will be addressed in an upcoming release. The latest command-line client also supports these options as well: $ bodhi --critpath --untested --release F13 Could a flag be added to only output the package names, so that I can pipe the output directly to yum? Or even better, have that flag automatically cause the bodhi client to invoke yum with --enable-repo=updates-testing with the packages required. If we need more testers, we should automate their task as much as humanly (or, in this case, computerly :p ) possible Thanks, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, Jul 01, 2010 at 03:13:55PM -0700, Jesse Keating wrote: On 7/1/10 2:55 PM, Till Maas wrote: But I guess somehow it boils down to the majority wants that other people to work for them, which might even be true. But in a FOSS community I doubt it is very healthy to follow this too much. I bet if we stopped making package reviews mandatory, none would get done. This follows the same. This is an interesting comparison, because there are still not enough reviewers even though it is mandatory. Also everyone directly benefits from the reviews, because there are clear statements what is checked and there are more often issues to be fixed in reviews, than there are updates that are bad. And in addition people who care already extra review packages and catch issues that were not found in the official review or check packages after guidelines changed, like there are checks for the static libs guidelines. So there is non mandatory action to fix brokenness and I am very sure that there would be more if more packages were when reviews were not mandatory, as long as the Guidelines make sense and help the packages to interact. There are even people catching mistakes in commits currently, which is also completely non mandatory. Regards Till pgpAZ0M5G2HyR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
measuring success [was Re: Bodhi 0.7.5 release]
On Thu, 2010-07-01 at 06:33 +0200, Kevin Kofler wrote: Fedora Legacy has shown how well this works… not! I completely agree with Ralf Corsepius and Tom Lane on this subject: this policy is very unhelpful, and applying it to security updates is just totally insane. We're going to see machines compromised because critical fixes are getting delayed by brainless technobureaucracy. Let's put aside the needless, inflammatory rhetoric for just a brief moment, and actually try to think about ways to solve problems, shall we? The main reasons we want to perform testing are things like: to avoid pushing updates with broken dependencies, or updates that cause serious regressions requiring manual intervention / emergency update replacements. That sort of thing. But your assertion seems to be something like: This is obviously going to fail horribly and therefore any testing is a waste of time. Various reasons for this have been bandied about - there isn't enough manpower and it's going to slow down updates and make people vulnerable for longer are the most prominent ones, as I see it. Now. For each of these reasons - pro and con - there should be some things we can actually measure. Turnaround time on security updates, for instance. Given measurements of some agreed-upon metrics over time, we can actually quantify whether or not this policy is a failure, rather than just SHOUTING and WAVING OUR ARMS and PREDICTING DOOM and QUOTING WAYNE'S WORLD at one another. Therefore: I propose that we choose a few metrics (turnaround time on security updates, average number of live updates with broken dependencies per day, etc.). Then we begin measuring them (and, if possible, collect historical, pre-critpath data to compare that to). I'm willing to bet that these metrics have improved since we started the critpath policies before F13 release, and will continue to improve over the course of F13's lifecycle and the F14 development cycle. In fact, Kevin, given a set of metrics we're both happy with, I'd be willing to stake my subscription to this list on it - for, say, 3 months. Are you willing to do the same? -w -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
On 07/02/2010 06:20 PM, Will Woods wrote: The main reasons we want to perform testing are things like: to avoid pushing updates with broken dependencies, or updates that cause serious regressions requiring manual intervention / emergency update replacements. That sort of thing. Should be done scripted as part of the package push process. No need for karmas, no need for provenpackager Doesn't Michael Schwendt have a script for this? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, Jun 30, 2010 at 02:48:26PM -0400, Luke Macken wrote: For critical path updates to be approved for pushing to the stable repository, they now require a minimum karma of 2, consisting of a +1 from a single proventester, and a +1 from another authenticated user. I am just wondering, is this some intermediate step until the Package update acceptance criteria[0] are implemented? Because these criteria only say that updates require positive Bodhi karma from a defined group of testers, so there is no need for the +1 from another authenticated user. Also they are about the important packages, which is a subset of critical path. And the policy says that it is not yet live. Regards Till [0] https://fedoraproject.org/wiki/Package_update_acceptance_criteria pgpKwhwwnCu8m.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/2/10 11:27 AM, Till Maas wrote: On Wed, Jun 30, 2010 at 02:48:26PM -0400, Luke Macken wrote: For critical path updates to be approved for pushing to the stable repository, they now require a minimum karma of 2, consisting of a +1 from a single proventester, and a +1 from another authenticated user. I am just wondering, is this some intermediate step until the Package update acceptance criteria[0] are implemented? Because these criteria only say that updates require positive Bodhi karma from a defined group of testers, so there is no need for the +1 from another authenticated user. Also they are about the important packages, which is a subset of critical path. And the policy says that it is not yet live. Regards Till [0] https://fedoraproject.org/wiki/Package_update_acceptance_criteria I believe it's a continuation of the criteria we used for F13 branched, which came from the No Frozen Rawhide proposals. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwuM+EACgkQ4v2HLvE71NVp/ACeJhYvjxvhmhglJR1O+4V+xVO+ 4hgAoI3YXJyFlkPv5j3rP4qBlAy159Y7 =wimC -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Fri, 02 Jul 2010 20:27:27 +0200 Till Maas opensou...@till.name wrote: On Wed, Jun 30, 2010 at 02:48:26PM -0400, Luke Macken wrote: For critical path updates to be approved for pushing to the stable repository, they now require a minimum karma of 2, consisting of a +1 from a single proventester, and a +1 from another authenticated user. I am just wondering, is this some intermediate step until the Package update acceptance criteria[0] are implemented? Because these criteria only say that updates require positive Bodhi karma from a defined group of testers, so there is no need for the +1 from another authenticated user. I have clarified this. This is using the same critical path setup that branched releases use, which is: +1 from a proventester, and +1 from any logged in user. Also they are about the important packages, which is a subset of critical path. Superset. :) In any case, the items mentioned there should be implemented. Bodhi calls them all 'critical path' so perhaps we should change to do that there too. And the policy says that it is not yet live. I have updated the page. Does it look clear now? Re-wording or tweaks very welcome. https://fedoraproject.org/wiki/Package_update_acceptance_criteria kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Fri, Jul 02, 2010 at 12:48:43PM -0600, Kevin Fenzi wrote: On Fri, 02 Jul 2010 20:27:27 +0200 Till Maas opensou...@till.name wrote: Also they are about the important packages, which is a subset of critical path. Superset. :) In any case, the items mentioned there should be implemented. Bodhi calls them all 'critical path' so perhaps we should change to do that there too. Yes, superset. If the important packages and critical path packages are the same and handled the same in any way, then the term import packages should imho vanish and never be used again. The inflation of different terms for the same thing is imho a major problem in the Fedora docs in general. :-( And the policy says that it is not yet live. I have updated the page. Does it look clear now? Re-wording or tweaks very welcome. I tried to make it more consistent. Regards Till pgpDRqXHYAy2N.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: measuring success [was Re: Bodhi 0.7.5 release]
Will Woods wrote: The main reasons we want to perform testing are things like: to avoid pushing updates with broken dependencies The right way to prevent that is to get AutoQA completed, which will, if it works as intended, automatically detect and throw out updates with broken dependencies without needlessly delaying all those updates which don't have broken dependencies. Once AutoQA is completed, the testing process will do NOTHING whatsoever to prevent broken dependencies because they wouldn't make it through AutoQA anyway. or updates that cause serious regressions requiring manual intervention / emergency update replacements. No amount of testing is going to catch all such cases, and when it does happen, the testing requirements actually HINDER a quick fix, increasing the window of exposure to the bug and therefore making it affect many more users and for longer time. In fact, Kevin, given a set of metrics we're both happy with, I'd be willing to stake my subscription to this list on it - for, say, 3 months. Are you willing to do the same? No. Metrics just encourage working to the metric to game the system, and any improvement you measure from the new process might just be due to chance or to factors we aren't considering at all. Plus, do we even have the historical data to compare with, given that everything older than F12 is deleted from Bodhi? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On 07/01/2010 12:47 AM, Kevin Kofler wrote: Jesse Keating wrote: There is a slight wrinkle in that right now, the bodhi code will automatically request a push of an item that reaches this karma threshold, and I don't believe there is a way yet to force it to wait for even greater amounts of karma. I believe that fine grained tuning of karma automation is planned for the next major version (and rewrite) of bodhi. That's not a slight wrinkle, that's a fatal showstopper which means this change should never have hit production. I consider it completely unacceptable for my updates to get promoted to stable when I didn't request it (e.g. I disable karma automatism for all my updates). If you disable karma automatism for your updates, they will not automatically get promoted to stable upon critpath approval. The way the workflow should work (*) is that: * case 1: The maintainer requests the push to stable before the promotion is approved. Then it will get withheld until approval. Once approval is obtained, the push is automatically requested by Bodhi. This is the workflow that occurs by default. All critpath updates go to testing first, even if the maintainer chooses stable. It's tested and approved, then bodhi automatically promotes it to stable. * case 2: The approval happens before a push to stable is requested. In that case, the update is marked as approved and the maintainer can queue it to stable at any time. That's the only sane way to handle such approval, everything else is just plain broken. (And isn't that how the security team approval works now? Why is the proventester approval implemented differently?) This is the workflow that occurs when you disable karma automatism. (*) under the (bad) assumption that this process makes sense at all, of course Your description of how the workflow should work is how the workflow works. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, 2010-07-01 at 07:00 +0200, Kevin Kofler wrote: Dave Airlie wrote: So in your mind, there is a majority of people on your side, but they are just too lazy to stand for election and take over the board? s/too lazy/too busy doing actual work/ (as opposed to wasting their time with politics or bureaucracy) Have you noticed that all the people who are complaining about the policies are highly experienced packagers? And there are actually many more people disagreeing with those broken policies than the ones you notice on the ML, they just don't have the time to write mails to complain about them. (For example, rumors are that several people in the Brno RH office share my concerns.) but these people are still in a minority. you are living in a fallacy. There is also a large percentage of people who agree with the changes are also too busy doing actual work, I agree with them, I don't run for the board, I barely vote, I am an experienced packager. Like I can totally handle you being anti-everything anyone does around here, I can't handle you thinking you are in a majority. I also work in Brisbane RH office, and I have lots of examples of people who don't share your concerns. I've seen surveys before where side A says, I have 100 scientists who agree with my POV, and you get the other side saying I have 100 scientists all called Dave, who agree with mine. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, Jul 01, 2010 at 05:23:06PM +1000, Dave Airlie wrote: On Thu, 2010-07-01 at 07:00 +0200, Kevin Kofler wrote: Dave Airlie wrote: So in your mind, there is a majority of people on your side, but they are just too lazy to stand for election and take over the board? s/too lazy/too busy doing actual work/ (as opposed to wasting their time with politics or bureaucracy) Have you noticed that all the people who are complaining about the policies are highly experienced packagers? And there are actually many more people disagreeing with those broken policies than the ones you notice on the ML, they just don't have the time to write mails to complain about them. (For example, rumors are that several people in the Brno RH office share my concerns.) but these people are still in a minority. you are living in a fallacy. How do you know who is a minority and who is not? I still wonder why there are so many claims that the majority of Fedora maintainers or users want to manually test all updates, but still the majority is not involved in testing the updates. When the discussion started, it was claimed that submitting karma was too complicated and took too much time. This is not the case for several months, but still there are updates that do not receive any karma for more than a month. The last Bodhi statistics showed 595 unique karma submitters for F13 and there seem to be 1035 approved packagers currently in Fedora. So if only packagers submitted karma, it would be the majority. But since there are a lotsmore users and also dedicated testers for Fedora, it does not look like a majority anymore. Regards Till pgpa3AYvppATv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, Jul 01, 2010 at 12:31:06AM -0400, James Antill wrote: On Thu, 2010-07-01 at 00:20 +0200, Till Maas wrote: On Wed, Jun 30, 2010 at 12:50:53PM -0700, Adam Williamson wrote: You can already view all pending critpath updates in Bodhi's web interface and command line client, as per Luke's initial mail. But a yum enhancement or plugin to restrict e.g. update or check-update on only critpath updates might be interesting for people only interested in critpath testing. I thought the idea was that critpath packages would be in a critpath group in comps? I just looked and there are two such groups: critical-path-base critical-path-gnome But how can they be used for this? From the manpage I get that e.g. yum groupupdate critical-path-base would also install all critical-path-base packages, but the command I was looking for is update all installed packages that are in the group critical-path-base. Is there a way to do this in yum? Regards Till pgpBtMppbK5Zh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: No. It means there haven't been enough such candidates. People did vote for me. But alone against 8 people who didn't agree with me, I wasn't able to achieve anything. If you give people ballots with only Evil Dictator on them, of course Evil Dictator will win. It doesn't say anything about the electorate. Why do you continue to hang around in a group you believe has a silent majority that agrees with you (but doesn't show up for elections) and that you think is run by Evil Dictators? That's really an insult to the people putting in effort to make Fedora better. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, 2010-07-01 at 06:29 +0200, Kevin Kofler wrote: Adam Williamson wrote: ...or convince enough others of your position that they will vote for the candidates you favour in our leadership elections. Since there've been several of these since you first stated you don't approve of Fedora's leadership, it seems the electorate doesn't agree with you... No. It means there haven't been enough such candidates. People did vote for me. But alone against 8 people who didn't agree with me, I wasn't able to achieve anything. I voted for you, but given how you behaved when actually a member of FESCo, I kind of came to regret it. I think your assessment is not entirely correct. It wasn't because (or not entirely because) it was You Versus 8, but because of how you conducted yourself in meetings and discussions. Essentially, you were a large part of *making* it You Versus 8, rather than nine people with various different opinions but also some broad common ground. This time I again made a point of voting for people who are not in 'the cabal' (which doesn't exist, of course), but tried to pick ones who I thought would work in productive and co-operative ways within FESCo. If you give people ballots with only Evil Dictator on them, of course Evil Dictator will win. It doesn't say anything about the electorate. I realize you're just drawing a rather shaky analogy and not suggesting the other FESCo candidates were Evil Dictators, but even still, I don't think this is an appropriate illustration of the process. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, 2010-06-30 at 18:38 -0400, Tom Lane wrote: 2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma. Is the restrictive policy in force for F-12 too? As far as I'm aware, no. We're starting at F-13. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, 2010-07-01 at 01:26 -0400, Luke Macken wrote: On 07/01/2010 12:47 AM, Kevin Kofler wrote: Jesse Keating wrote: There is a slight wrinkle in that right now, the bodhi code will automatically request a push of an item that reaches this karma threshold, and I don't believe there is a way yet to force it to wait for even greater amounts of karma. I believe that fine grained tuning of karma automation is planned for the next major version (and rewrite) of bodhi. That's not a slight wrinkle, that's a fatal showstopper which means this change should never have hit production. I consider it completely unacceptable for my updates to get promoted to stable when I didn't request it (e.g. I disable karma automatism for all my updates). If you disable karma automatism for your updates, they will not automatically get promoted to stable upon critpath approval. It would probably be good to advertise this more prominently somewhere. I must admit I wasn't aware we still had this wrinkle - I assumed you'd be getting it fixed this time around - and we should definitely alert maintainers to it. The way the workflow should work (*) is that: * case 1: The maintainer requests the push to stable before the promotion is approved. Then it will get withheld until approval. Once approval is obtained, the push is automatically requested by Bodhi. This is the workflow that occurs by default. All critpath updates go to testing first, even if the maintainer chooses stable. It's tested and approved, then bodhi automatically promotes it to stable. * case 2: The approval happens before a push to stable is requested. In that case, the update is marked as approved and the maintainer can queue it to stable at any time. That's the only sane way to handle such approval, everything else is just plain broken. (And isn't that how the security team approval works now? Why is the proventester approval implemented differently?) This is the workflow that occurs when you disable karma automatism. Perhaps it would surprise people less if we made case 2 default for critpath? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, 30 Jun 2010 18:38:03 -0400 Tom Lane t...@redhat.com wrote: I see that libtiff.fc13 and libpng.fc13 are now showing critical path approved, for which I thank those who did the work. Thanks. ;) I remain a bit unclear about a couple of things: 1. Bodhi is showing both packages as requested push-to-stable. Which *I* certainly didn't do, and considering they are only at +2 karma, this means that the threshold for auto-push is actually lower than it was before, not higher. WTF? Is the idea here to remove every last vestige of the maintainer's judgment from the process? No. Please stop assuming everything in a negative light. ;) This looks like a bug to me... if you didn't request stable, it shouldn't go yet. I can talk to Luke about it, perhaps you could file a bodhi bug on it? 2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma. Is the restrictive policy in force for F-12 too? I'm even less willing to believe that we have enough testing manpower to cover both back branches right away. Yes, it does appear to be there as well. I am just ramping up my f12 test machine now... but yeah, it's not clear that we intended this to go live for f12 too. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On 07/01/2010 03:38 PM, Kevin Fenzi wrote: On Wed, 30 Jun 2010 18:38:03 -0400 Tom Lanet...@redhat.com wrote: I see that libtiff.fc13 and libpng.fc13 are now showing critical path approved, for which I thank those who did the work. Thanks. ;) I remain a bit unclear about a couple of things: 1. Bodhi is showing both packages as requested push-to-stable. Which *I* certainly didn't do, and considering they are only at +2 karma, this means that the threshold for auto-push is actually lower than it was before, not higher. WTF? Is the idea here to remove every last vestige of the maintainer's judgment from the process? No. Please stop assuming everything in a negative light. ;) This looks like a bug to me... if you didn't request stable, it shouldn't go yet. I can talk to Luke about it, perhaps you could file a bodhi bug on it? There /was/ a bug with the initial release that left a small window of time where updates would have been auto-promoted even if karma automatism was enabled. This has since been resolved. 2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma. Is the restrictive policy in force for F-12 too? I'm even less willing to believe that we have enough testing manpower to cover both back branches right away. Yes, it does appear to be there as well. I am just ramping up my f12 test machine now... but yeah, it's not clear that we intended this to go live for f12 too. ;( It also wasn't clear that this was supposed to be for F13 only :( Right now bodhi treats *all* critical path packages the same, across all releases. If we only want this policy to be in place for F13, then I'm sure I could hack around it. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/1/10 2:48 AM, Till Maas wrote: How do you know who is a minority and who is not? I still wonder why there are so many claims that the majority of Fedora maintainers or users want to manually test all updates, but still the majority is not involved in testing the updates. When the discussion started, it was claimed that submitting karma was too complicated and took too much time. This is not the case for several months, but still there are updates that do not receive any karma for more than a month. The last Bodhi statistics showed 595 unique karma submitters for F13 and there seem to be 1035 approved packagers currently in Fedora. So if only packagers submitted karma, it would be the majority. But since there are a lotsmore users and also dedicated testers for Fedora, it does not look like a majority anymore. Simply, if it's not mandatory, it's too easy to be lazy and not do it. But when it is mandatory, more people participate. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwtBRMACgkQ4v2HLvE71NWXDQCgxUX/5EQwNK4TVASuAqK39ORI VKEAnjaND4F98KB0XtEjDeY+wOCdOP+q =RMEJ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, Jul 01, 2010 at 02:13:59PM -0700, Jesse Keating wrote: On 7/1/10 2:48 AM, Till Maas wrote: How do you know who is a minority and who is not? I still wonder why there are so many claims that the majority of Fedora maintainers or users want to manually test all updates, but still the majority is not involved in testing the updates. When the discussion started, it was claimed that submitting karma was too complicated and took too much time. This is not the case for several months, but still there are updates that do not receive any karma for more than a month. The last Bodhi statistics showed 595 unique karma submitters for F13 and there seem to be 1035 approved packagers currently in Fedora. So if only packagers submitted karma, it would be the majority. But since there are a lotsmore users and also dedicated testers for Fedora, it does not look like a majority anymore. Simply, if it's not mandatory, it's too easy to be lazy and not do it. But when it is mandatory, more people participate. Do the participate because they care or because they have to to get the things they care about done, when it is mandatory? I am very convinced that people who care about something will do it nonetheless, even if it is not mandatory and people who do something only because it is mandatory will perform not as good as convinced people, i.e. bend the rules to achieve what needs to be achieved with as little effort as possible instead of trying to be as good as one can be. I also found some other interesting number. According to http://fedoraproject.org/wiki/File:Accounts_2010-02.jpg there are more than 25.000 active Fedora Accounts. So for a majority there would be more than 12.500 people wanting manual testings and only about 5% of this interested people care enough to submit at least one karma comment in Bodhi for Fedora 13. And http://fedoraproject.org/wiki/Statistics#Who_uses_Fedora.3F claims that even millions of people use Fedora. But I guess somehow it boils down to the majority wants that other people to work for them, which might even be true. But in a FOSS community I doubt it is very healthy to follow this too much. Regards Till pgpscvzjrzeLb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/1/10 2:55 PM, Till Maas wrote: But I guess somehow it boils down to the majority wants that other people to work for them, which might even be true. But in a FOSS community I doubt it is very healthy to follow this too much. I bet if we stopped making package reviews mandatory, none would get done. This follows the same. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwtEyAACgkQ4v2HLvE71NXm3gCaA5I3IvWDhjkKEzaZFZXgjVRg sEYAoMRRWlHg9IXSHr3WuvvN/fTWZFe7 =Skyz -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, 2010-07-01 at 11:48 +0200, Till Maas wrote: On Thu, Jul 01, 2010 at 05:23:06PM +1000, Dave Airlie wrote: On Thu, 2010-07-01 at 07:00 +0200, Kevin Kofler wrote: Dave Airlie wrote: So in your mind, there is a majority of people on your side, but they are just too lazy to stand for election and take over the board? s/too lazy/too busy doing actual work/ (as opposed to wasting their time with politics or bureaucracy) Have you noticed that all the people who are complaining about the policies are highly experienced packagers? And there are actually many more people disagreeing with those broken policies than the ones you notice on the ML, they just don't have the time to write mails to complain about them. (For example, rumors are that several people in the Brno RH office share my concerns.) but these people are still in a minority. you are living in a fallacy. How do you know who is a minority and who is not? I still wonder why I think the fact that there is about x:1 people standing for the board/fesco with one view vs the other. The same reasons Kevin gives for nobody who shares his view as having motiviation for running for the board, can just as easily be applied to everyone who doesn't share his view. As one of the people who is too busy doing actual work to run for the board I see my views reflected by the x members of the board/fesco as opposed to the one. So it probably stacks up like a the majority of people don't care, the next sizeable minority agree with the decision, and the final group disagree and make most noise, and hence seem to imply they are largest. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Luke Macken lmac...@redhat.com writes: Critical path package[0] updates now require positive karma from two proventesters[1], and a single +1 from one other community member. Even for security updates? My experience says that this requirement will prevent me from *ever* pushing updates. Case in point: libtiff, which is a critpath package, has been in testing with a significant security update for a week now. Its karma is still zero. When I get the old package warning in another week, I am going to push it stable ... and if bodhi won't let me, I am going to come looking for a neck to wring. The proposed policy might be workable if we had a surplus of proventester manpower available, but we obviously have not got that. I would suggest a timeout: once the package has been in testing for two weeks, the maintainer may push it stable regardless of whether proventesters have fallen down on the job. Or if you really think maintainers of critpath packages cannot be trusted to make these decisions, I would be willing to accept *negative* karma from more than one proventester as being an override. But it is utterly unacceptable for inaction to represent a veto. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Tom Lane wrote: Even for security updates? My experience says that this requirement will prevent me from*ever* pushing updates. Case in point: libtiff, which is a critpath package, has been in testing with a significant security update for a week now. Its karma is still zero. When I get the old package warning in another week, I am going to push it stable ... and if bodhi won't let me, I am going to come looking for a neck to wring. The proposed policy might be workable if we had a surplus of proventester manpower available, but we obviously have not got that. If you follow the test list, there are many new proventester applications. I would suggest a timeout: once the package has been in testing for two weeks, the maintainer may push it stable regardless of whether proventesters have fallen down on the job. Or if you really think maintainers of critpath packages cannot be trusted to make these decisions, I would be willing to accept*negative* karma from more than one proventester as being an override. But it is utterly unacceptable for inaction to represent a veto. Time isn't the issue. It's man power. Updates that stay in testing for months with no one looking at them and then get pushed to stable have broken things before. Should the bodhi whine mail be CC'd to the test mailing list in a digest-type mail like the updates-testing pushes? Then all proventesters (and non-proventesters) are informed that there is a critpath pkg that is needing some TLC? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote: Luke Macken lmac...@redhat.com writes: Critical path package[0] updates now require positive karma from two proventesters[1], and a single +1 from one other community member. Even for security updates? My experience says that this requirement will prevent me from *ever* pushing updates. Case in point: libtiff, which is a critpath package, has been in testing with a significant security update for a week now. Its karma is still zero. We have not been doing proventesters testing since F13 release, because there has been no need for it. Additionally, because the critpath karma requirement has been disabled, there has been no convenient mechanism for finding critpath updates. Now both of these have changed; QA activated the proventesters yesterday, and Bodhi now has several ways to find critpath packages (and fedora-easy-karma hopefully soon will). All of this should result in rather more karma arriving. The proposed policy might be workable if we had a surplus of proventester manpower available, but we obviously have not got that. See above, you cannot judge this on current experience. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On 06/30/2010 06:18 PM, Adam Williamson wrote: On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote: The proposed policy might be workable if we had a surplus of proventester manpower available, but we obviously have not got that. And you think re-allocating the already scarce manpower to this process will help? I am having very strong doubts on this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, Jun 30, 2010 at 11:35:17AM -0400, Tom Lane wrote: Luke Macken lmac...@redhat.com writes: Critical path package[0] updates now require positive karma from two proventesters[1], and a single +1 from one other community member. Even for security updates? My experience says that this requirement will prevent me from *ever* pushing updates. Case in point: libtiff, which is a critpath package, has been in testing with a significant security update for a week now. Its karma is still zero. When I get the old package warning in another week, I am going to push it stable ... and if bodhi won't let me, I am going to come looking for a neck to wring. Refrain from making threats of bodily harm on this list. It is not warranted or wanted. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/30/10 9:31 AM, Ralf Corsepius wrote: On 06/30/2010 06:18 PM, Adam Williamson wrote: On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote: The proposed policy might be workable if we had a surplus of proventester manpower available, but we obviously have not got that. And you think re-allocating the already scarce manpower to this process will help? I am having very strong doubts on this. One of the big reasons the manpower was scarce is we did not have a proper system to locate, train, and promote new people into this manpower. The QA team has made great strides into fixing that and we do now have a process in place, and a good stream of incoming people willing to donate some time and effort to help the project. We are not just hoping that people will show up and test, we're actively building a community of people who will be dedicated to testing these things. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwrcjIACgkQ4v2HLvE71NVvUQCfbNY/aL9u3OVG+hV32Cki4R/7 2QQAoMHiq6MwEV2p2HMRsZC9Fjs30Beo =r6aw -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote: I would be willing to accept *negative* karma from more than one proventester as being an override. But it is utterly unacceptable for inaction to represent a veto. I would argue that it's utterly unacceptable for untested code to be pushed to users. Is it really so hard for you to find someone to test the thing? If so, maybe you could use the assistance of a co-maintainer? -w -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/30/10 10:48 AM, Ralf Corsepius wrote: My perception is: marketing has directed into a direction which drains away man-power into an uncertain process whose only immediate effect is bureaucracy, whose long term outcome is uncertain and who foundations are very questionable, to say the least. Well yes, you always can be relied upon for the cheery optimistic outlook :) - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwrhcsACgkQ4v2HLvE71NW9VgCePi19pnrMGuRmkcD973VzaAre LT4AoIF2N0vPJ/TR0BWHFdyfHdAaNQjs =1R+D -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote: Luke Macken lmac...@redhat.com writes: Critical path package[0] updates now require positive karma from two proventesters[1], and a single +1 from one other community member. Even for security updates? My experience says that this requirement will prevent me from *ever* pushing updates. Case in point: libtiff, which is a critpath package, has been in testing with a significant security update for a week now. Its karma is still zero. When I get the old package warning in another week, I am going to push it stable ... and if bodhi won't let me, I am going to come looking for a neck to wring. Checks and balances are actually quite important - even if we're not always the biggest fans of them - especially for existing shipping distributions. I'm a big fan of letting whatever happen before you ship, then locking it down and making it tough to screw over systems that are not explicitly asking to be affected by a major upgrade, etc. There's also the if you build it... argument. I think if it's actually necessary to get these ACKs then they will happen. And in the worst case, you probably just need to email this list/IRC/etc. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/30/10 11:09 AM, Ralf Corsepius wrote: On 06/30/2010 07:58 PM, Jesse Keating wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/30/10 10:48 AM, Ralf Corsepius wrote: My perception is: marketing has directed into a direction which drains away man-power into an uncertain process whose only immediate effect is bureaucracy, whose long term outcome is uncertain and who foundations are very questionable, to say the least. Well yes, you always can be relied upon for the cheery optimistic outlook :) If I were perceiving competence in Fedora's leadership, my comments would sound differently. You're welcome to try your hand at leadership, or find a project with different leadership. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwrjCwACgkQ4v2HLvE71NXV4QCeOBlTKRXmHNS9xShqcox1rxt1 vJQAoK+gR7rANslclt2mhG1eNoX07EKR =FgEj -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, 2010-06-30 at 11:25 -0700, Jesse Keating wrote: Well yes, you always can be relied upon for the cheery optimistic outlook :) If I were perceiving competence in Fedora's leadership, my comments would sound differently. You're welcome to try your hand at leadership, or find a project with different leadership. ...or convince enough others of your position that they will vote for the candidates you favour in our leadership elections. Since there've been several of these since you first stated you don't approve of Fedora's leadership, it seems the electorate doesn't agree with you... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Tue, 2010-06-29 at 18:37 -0400, Luke Macken wrote: proventesters strict critical path update handling Critical path package[0] updates now require positive karma from two proventesters[1], and a single +1 from one other community member. Sorry, I did not convey this correctly. For critical path updates to be approved for pushing to the stable repository, they now require a minimum karma of 2, consisting of a +1 from a single proventester, and a +1 from another authenticated user. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Adam Williamson awill...@redhat.com writes: On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote: The proposed policy might be workable if we had a surplus of proventester manpower available, but we obviously have not got that. See above, you cannot judge this on current experience. Yes I can. I have two critpath packages that are in testing with security bugs, both pretty small and easy to test, and both still have karma zero. That seems to me to be adequate proof that there's not the manpower out there to do this. The right way to go about this is to ramp up proventester manpower *first* before making it a required gating factor. If we were at the point where any significant fraction of packages were being auto-pushed due to +3 karma, I would be fine with the proposed policy. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote: Adam Williamson awill...@redhat.com writes: On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote: The proposed policy might be workable if we had a surplus of proventester manpower available, but we obviously have not got that. See above, you cannot judge this on current experience. Yes I can. I have two critpath packages that are in testing with security bugs, both pretty small and easy to test, and both still have karma zero. That seems to me to be adequate proof that there's not the manpower out there to do this. Have you actually asked anyone to test it? Or even considered *mentioning the names of the packages* so maybe someone here could help? You're putting way more effort into complaining about testing being required than it would actually take to get someone to perform the required testing. I find this to be a poor use of your time and mine. The right way to go about this is to ramp up proventester manpower *first* before making it a required gating factor. Chicken-and-egg problem. It turns out nobody does testing when it's optional. So now it's not optional. But take heart - if both packages are small and easy to test, surely it'll be really easy to find someone to test them both. -w -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Will Woods wwo...@redhat.com writes: Is it really so hard for you to find someone to test the thing? If so, maybe you could use the assistance of a co-maintainer? Huh? I don't need a co-maintainer, I need testers. proventesters, even. Or are you suggesting that the way to deal with this is to have two maintainers who each sign up as proventesters and then bump the karma on their own packages? Surely that's not the way to get more eyeballs on the problem. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Michael Cronenworth m...@cchtml.com writes: Should the bodhi whine mail be CC'd to the test mailing list in a digest-type mail like the updates-testing pushes? +1. As is, old-package whine mail is going to be directed to somebody who *isn't allowed to do anything about it*. A more dysfunctional system is hard to imagine. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote: Adam Williamson awill...@redhat.com writes: On Wed, 2010-06-30 at 11:35 -0400, Tom Lane wrote: The proposed policy might be workable if we had a surplus of proventester manpower available, but we obviously have not got that. See above, you cannot judge this on current experience. Yes I can. I have two critpath packages that are in testing with security bugs, both pretty small and easy to test, and both still have karma zero. That seems to me to be adequate proof that there's not the manpower out there to do this. The right way to go about this is to ramp up proventester manpower *first* before making it a required gating factor. If we were at the point where any significant fraction of packages were being auto-pushed due to +3 karma, I would be fine with the proposed policy. We've been doing both together. Please see the QA mailing list archives and meeting minutes for the last few weeks. As Will mentioned, we have a bunch (actually 14) proventester mentor requests which we have started to accept as of this morning, and I asked existing proventesters to start (or start again, as they were doing it during the pre-release F13 period) proactively testing critpath updates last night. I'd remind you that we've actually already had a period of several weeks where this system was active - before the F13 release, when critpath package pushes required feedback from a member of qa or releng - and that worked out fine, the packages got pushed and we did the release. Now we have a better process with a dedicated group and more people in it or about to be in it and fewer pushes to handle (I'd hope so, anyway; there should be fewer pushes for a release *after* it goes out than *before*), so it seems unlikely it would work any worse than it did then. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, 2010-06-30 at 15:08 -0400, Tom Lane wrote: Will Woods wwo...@redhat.com writes: Is it really so hard for you to find someone to test the thing? If so, maybe you could use the assistance of a co-maintainer? Huh? I don't need a co-maintainer, I need testers. I was suggesting that - since you seem to be so loath to actually perform the minimal effort required to find a proventester (pop into #fedora-qa, ask on t...@lists.fedoraproject.org, etc) - maybe you could use a co-maintainer to handle that part of the process for you? Also: each critpath package currently only requires one proventester, and one karma from any other registered Fedora account. So right here on the devel list you have hundreds of people listening who could fulfill half the requirement, if you actually were willing to ask. You're the maintainer of something critical to the proper functioning of the distribution. Arguing against the necessity of even minimal software testing really does not suit that position. -w -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Will Woods wwo...@redhat.com writes: On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote: Yes I can. I have two critpath packages that are in testing with security bugs, both pretty small and easy to test, and both still have karma zero. That seems to me to be adequate proof that there's not the manpower out there to do this. Have you actually asked anyone to test it? Or even considered *mentioning the names of the packages* so maybe someone here could help? I mentioned libtiff in my first comment in this thread. The other one is libpng. But in any case, are maintainers supposed to have to scare up testers on their own? Especially for packages that are supposed to be so central as to be critpath? If there aren't testers coming out of the woodwork, this scheme is doomed to failure. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/30/2010 03:29 PM, Tom Lane wrote: Will Woods wwo...@redhat.com writes: On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote: Yes I can. I have two critpath packages that are in testing with security bugs, both pretty small and easy to test, and both still have karma zero. That seems to me to be adequate proof that there's not the manpower out there to do this. Have you actually asked anyone to test it? Or even considered *mentioning the names of the packages* so maybe someone here could help? I mentioned libtiff in my first comment in this thread. The other one is libpng. But in any case, are maintainers supposed to have to scare up testers on their own? Especially for packages that are supposed to be so central as to be critpath? If there aren't testers coming out of the woodwork, this scheme is doomed to failure. regards, tom lane A suggestion: when critical path updates hit updates-testing, a notification should go to both devel@lists.fedoraproject.org and q...@lists.fedoraproject.org to encourage testing. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkwrnOcACgkQeiVVYja6o6N2/ACgsLvwWnvsy4kYnCytqrJ7C74g mIsAn1Ki153jDL5UmY+adobGRxr+zdMu =0KQL -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, Jun 30, 2010 at 8:29 PM, Tom Lane t...@redhat.com wrote: Will Woods wwo...@redhat.com writes: On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote: Yes I can. I have two critpath packages that are in testing with security bugs, both pretty small and easy to test, and both still have karma zero. That seems to me to be adequate proof that there's not the manpower out there to do this. Have you actually asked anyone to test it? Or even considered *mentioning the names of the packages* so maybe someone here could help? I mentioned libtiff in my first comment in this thread. The other one is libpng. But in any case, are maintainers supposed to have to scare up testers on their own? Especially for packages that are supposed to be so central as to be critpath? If there aren't testers coming out of the woodwork, this scheme is doomed to failure. I for one hope its effective. The recent issues with the evolution show that its needed! The fact is that people miss things or upstream will change things they should in a stable release that isn't expected. Life happens. Worse case if its not is a revert of the bodhi code that enabled it if it doesn't work. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, Jun 30, 2010 at 8:37 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/30/2010 03:29 PM, Tom Lane wrote: Will Woods wwo...@redhat.com writes: On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote: Yes I can. I have two critpath packages that are in testing with security bugs, both pretty small and easy to test, and both still have karma zero. That seems to me to be adequate proof that there's not the manpower out there to do this. Have you actually asked anyone to test it? Or even considered *mentioning the names of the packages* so maybe someone here could help? I mentioned libtiff in my first comment in this thread. The other one is libpng. But in any case, are maintainers supposed to have to scare up testers on their own? Especially for packages that are supposed to be so central as to be critpath? If there aren't testers coming out of the woodwork, this scheme is doomed to failure. regards, tom lane A suggestion: when critical path updates hit updates-testing, a notification should go to both devel@lists.fedoraproject.org and q...@lists.fedoraproject.org to encourage testing. I think a daily digest to test@ and qa@ would be better, I'm sure the last thing people need is more than one extra email a day. If its a security issue maybe an individual email would be worthwhile but even then there's only one push a day. Peter Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, 2010-06-30 at 15:37 -0400, Stephen Gallagher wrote: A suggestion: when critical path updates hit updates-testing, a notification should go to both devel@lists.fedoraproject.org and q...@lists.fedoraproject.org to encourage testing. This would probably be too high traffic. We're working on making sure there's easy processes for the proventesters to identify and quickly provide feedback on critpath updates. fedora-easy-karma will soon sprout options to list only critpath updates, or only critpath updates which do not yet have sufficient feedback; I'm talking to Till about this now. You can already view all pending critpath updates in Bodhi's web interface and command line client, as per Luke's initial mail. I think the updates-testing mails that get sent daily to test list (it's not called qa) anyway could have the information on which updates are critpath added, for sure. Or the critpath updates could even be listed in a separate section, at the top. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, Jun 30, 2010 at 03:37:11PM -0400, Stephen Gallagher wrote: A suggestion: when critical path updates hit updates-testing, a notification should go to both devel@lists.fedoraproject.org and q...@lists.fedoraproject.org to encourage testing. The qa-list has already lost a lot of it's readability for me because of all the trac-mails that are now being sent there (yes - I could filter but I'm not filtering and I notice that I'm paying less attention to the list these days). I would suggest not doing the same for the devel@ list. Call me old-fashioned but I prefer my mailinglist either being filled with human or computer generated messages - not both. -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/30/10 12:29 PM, Tom Lane wrote: Will Woods wwo...@redhat.com writes: On Wed, 2010-06-30 at 15:04 -0400, Tom Lane wrote: Yes I can. I have two critpath packages that are in testing with security bugs, both pretty small and easy to test, and both still have karma zero. That seems to me to be adequate proof that there's not the manpower out there to do this. Have you actually asked anyone to test it? Or even considered *mentioning the names of the packages* so maybe someone here could help? I mentioned libtiff in my first comment in this thread. The other one is libpng. But in any case, are maintainers supposed to have to scare up testers on their own? Especially for packages that are supposed to be so central as to be critpath? If there aren't testers coming out of the woodwork, this scheme is doomed to failure. regards, tom lane It worked just fine when F13 branched before F13 released. We're putting even more resources into it now, ergo it should work just as fine. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwrqMEACgkQ4v2HLvE71NUDxgCgpPyHdKSQi0XVng1fc3HGCEzg gqEAniEOlhRJrctTk4iKOqrfCz21y4bC =GLK5 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Wed, Jun 30, 2010 at 12:50:53PM -0700, Adam Williamson wrote: On Wed, 2010-06-30 at 15:37 -0400, Stephen Gallagher wrote: A suggestion: when critical path updates hit updates-testing, a notification should go to both devel@lists.fedoraproject.org and q...@lists.fedoraproject.org to encourage testing. This would probably be too high traffic. We're working on making sure there's easy processes for the proventesters to identify and quickly provide feedback on critpath updates. fedora-easy-karma will soon sprout options to list only critpath updates, or only critpath updates which do not yet have sufficient feedback; I'm talking to Till about this now. Just to make sure, that this is not overseen. fedora-easy-karma will only list the critpath updates that are currently installed, not the one that are available. For this only these options exist: You can already view all pending critpath updates in Bodhi's web interface and command line client, as per Luke's initial mail. But a yum enhancement or plugin to restrict e.g. update or check-update on only critpath updates might be interesting for people only interested in critpath testing. Regards Till pgpqS0GBX66Ph.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Jesse Keating jkeat...@j2solutions.net writes: On 6/30/10 12:29 PM, Tom Lane wrote: I mentioned libtiff in my first comment in this thread. The other one is libpng. But in any case, are maintainers supposed to have to scare up testers on their own? Especially for packages that are supposed to be so central as to be critpath? If there aren't testers coming out of the woodwork, this scheme is doomed to failure. It worked just fine when F13 branched before F13 released. We're putting even more resources into it now, ergo it should work just as fine. I see that libtiff.fc13 and libpng.fc13 are now showing critical path approved, for which I thank those who did the work. I remain a bit unclear about a couple of things: 1. Bodhi is showing both packages as requested push-to-stable. Which *I* certainly didn't do, and considering they are only at +2 karma, this means that the threshold for auto-push is actually lower than it was before, not higher. WTF? Is the idea here to remove every last vestige of the maintainer's judgment from the process? 2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma. Is the restrictive policy in force for F-12 too? I'm even less willing to believe that we have enough testing manpower to cover both back branches right away. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/30/10 3:38 PM, Tom Lane wrote: Jesse Keating jkeat...@j2solutions.net writes: On 6/30/10 12:29 PM, Tom Lane wrote: I mentioned libtiff in my first comment in this thread. The other one is libpng. But in any case, are maintainers supposed to have to scare up testers on their own? Especially for packages that are supposed to be so central as to be critpath? If there aren't testers coming out of the woodwork, this scheme is doomed to failure. It worked just fine when F13 branched before F13 released. We're putting even more resources into it now, ergo it should work just as fine. I see that libtiff.fc13 and libpng.fc13 are now showing critical path approved, for which I thank those who did the work. I remain a bit unclear about a couple of things: 1. Bodhi is showing both packages as requested push-to-stable. Which *I* certainly didn't do, and considering they are only at +2 karma, this means that the threshold for auto-push is actually lower than it was before, not higher. WTF? Is the idea here to remove every last vestige of the maintainer's judgment from the process? That is not the idea or intent. However since we value proventester karma above all others, it was deemed only necessary to have one confirming karma beyond the proventester karma. This is how things worked throughout the F13 branched phase. There is a slight wrinkle in that right now, the bodhi code will automatically request a push of an item that reaches this karma threshold, and I don't believe there is a way yet to force it to wait for even greater amounts of karma. I believe that fine grained tuning of karma automation is planned for the next major version (and rewrite) of bodhi. 2. libtiff.fc12 and libpng.fc12 are still lonely with zero karma. Is the restrictive policy in force for F-12 too? I'm even less willing to believe that we have enough testing manpower to cover both back branches right away. I believe only F-13 requires proventester karma at this time. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwryHcACgkQ4v2HLvE71NWduQCgioaA2nrN89eelsinYa0OXLF0 8iYAn0Gt2dc/gwhrzuUtH190GR/dWRmA =qyet -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Luke Macken wrote: Critical path package[0] updates now require positive karma from two proventesters[1], and a single +1 from one other community member. Why two? The policy FESCo voted said one (plus one other community member, giving a total karma of 2). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Adam Williamson wrote: ...or convince enough others of your position that they will vote for the candidates you favour in our leadership elections. Since there've been several of these since you first stated you don't approve of Fedora's leadership, it seems the electorate doesn't agree with you... No. It means there haven't been enough such candidates. People did vote for me. But alone against 8 people who didn't agree with me, I wasn't able to achieve anything. If you give people ballots with only Evil Dictator on them, of course Evil Dictator will win. It doesn't say anything about the electorate. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, 2010-07-01 at 00:20 +0200, Till Maas wrote: On Wed, Jun 30, 2010 at 12:50:53PM -0700, Adam Williamson wrote: You can already view all pending critpath updates in Bodhi's web interface and command line client, as per Luke's initial mail. But a yum enhancement or plugin to restrict e.g. update or check-update on only critpath updates might be interesting for people only interested in critpath testing. I thought the idea was that critpath packages would be in a critpath group in comps? -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On Thu, 2010-07-01 at 06:29 +0200, Kevin Kofler wrote: Adam Williamson wrote: ...or convince enough others of your position that they will vote for the candidates you favour in our leadership elections. Since there've been several of these since you first stated you don't approve of Fedora's leadership, it seems the electorate doesn't agree with you... No. It means there haven't been enough such candidates. People did vote for me. But alone against 8 people who didn't agree with me, I wasn't able to achieve anything. If you give people ballots with only Evil Dictator on them, of course Evil Dictator will win. It doesn't say anything about the electorate. So in your mind, there is a majority of people on your side, but they are just too lazy to stand for election and take over the board? Not that you are in a minority? Twisted. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Jesse Keating wrote: One of the big reasons the manpower was scarce is we did not have a proper system to locate, train, and promote new people into this manpower. The QA team has made great strides into fixing that and we do now have a process in place, and a good stream of incoming people willing to donate some time and effort to help the project. We are not just hoping that people will show up and test, we're actively building a community of people who will be dedicated to testing these things. Fedora Legacy has shown how well this works… not! I completely agree with Ralf Corsepius and Tom Lane on this subject: this policy is very unhelpful, and applying it to security updates is just totally insane. We're going to see machines compromised because critical fixes are getting delayed by brainless technobureaucracy. You have seen Fedora Legacy fail, why are you forcing your personal ideas which DID NOT WORK onto all of us? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Adam Williamson wrote: I'd remind you that we've actually already had a period of several weeks where this system was active - before the F13 release, when critpath package pushes required feedback from a member of qa or releng - and that worked out fine, the packages got pushed and we did the release. Now we have a better process with a dedicated group and more people in it or about to be in it and fewer pushes to handle (I'd hope so, anyway; there should be fewer pushes for a release *after* it goes out than *before*), so it seems unlikely it would work any worse than it did then. There are actually more updates after a release, especially for critical packages. Before the release, we try hard not to break the live images, which cannot be fixed by post-release updates. After the release, that's not an issue, and any small issues we introduce can just be fixed with another update (which also means less QA is needed). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Jesse Keating wrote: There is a slight wrinkle in that right now, the bodhi code will automatically request a push of an item that reaches this karma threshold, and I don't believe there is a way yet to force it to wait for even greater amounts of karma. I believe that fine grained tuning of karma automation is planned for the next major version (and rewrite) of bodhi. That's not a slight wrinkle, that's a fatal showstopper which means this change should never have hit production. I consider it completely unacceptable for my updates to get promoted to stable when I didn't request it (e.g. I disable karma automatism for all my updates). The way the workflow should work (*) is that: * case 1: The maintainer requests the push to stable before the promotion is approved. Then it will get withheld until approval. Once approval is obtained, the push is automatically requested by Bodhi. * case 2: The approval happens before a push to stable is requested. In that case, the update is marked as approved and the maintainer can queue it to stable at any time. That's the only sane way to handle such approval, everything else is just plain broken. (And isn't that how the security team approval works now? Why is the proventester approval implemented differently?) (*) under the (bad) assumption that this process makes sense at all, of course Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Tom Lane wrote: The right way to go about this is to ramp up proventester manpower first before making it a required gating factor. +1 Why was this implemented BEFORE proventester requests were approved? If we don't even have the mentoring process defined, then that should have happened before enabling proventester. And why does somebody like Rex Dieter need mentoring to get into proventesters at all? He has been doing rel-eng work including approval of freeze overrides for years. I'm sure several of the other early applicants are also people which should be just trusted and added instead of waiting for a vaporware process. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
I wrote: Why two? The policy FESCo voted said one (plus one other community member, giving a total karma of 2). Nevermind, I just noticed the later mail from Luke correcting this. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
Dave Airlie wrote: So in your mind, there is a majority of people on your side, but they are just too lazy to stand for election and take over the board? s/too lazy/too busy doing actual work/ (as opposed to wasting their time with politics or bureaucracy) Have you noticed that all the people who are complaining about the policies are highly experienced packagers? And there are actually many more people disagreeing with those broken policies than the ones you notice on the ML, they just don't have the time to write mails to complain about them. (For example, rumors are that several people in the Brno RH office share my concerns.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi 0.7.5 release
On 06/29/2010 06:37 PM, Luke Macken wrote: You can get a list of critical path updates using the bodhi web interface: https://admin.fedoraproject.org/updates/critpath?release=F13untested=True Oops, broken link. Sorry about that. https://admin.fedoraproject.org/updates/critpath?release=F13untested=True ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
