Re: bodhi: Notified "can be pushed", but refuses to push
On Sun, Mar 01, 2015 at 11:33:35AM +0100, Ralf Corsepius wrote: > On 03/01/2015 10:20 AM, Samuel Sieb wrote: > >On 02/28/2015 10:42 PM, Ralf Corsepius wrote: > >>I receive a yellow box telling me: "This update has not yet met the > >>minimum testing requirements defined in the Package Update Acceptance > >>Criteria" > >> > >>Something definitely doesn't work right. > >> > >Isn't it Alpha freeze right now? > > Well, then bodhi likely should not send out such false notifications. The bodhi backend/frontend configuration got out of sync. This problem should now be resolved in production. luke signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Mon, Jan 20, 2014 at 05:01:24PM -0800, Adam Williamson wrote: > On Mon, 2014-01-20 at 17:00 -0800, Adam Williamson wrote: > > On Mon, 2014-01-20 at 15:35 -0500, Matthew Miller wrote: > > > On Mon, Jan 20, 2014 at 09:48:28AM -0800, Adam Williamson wrote: > > > > I'd suggest this test should be a high priority for implementation once > > > > taskotron is operational, perhaps equal in importance to re-implementing > > > > the current AutoQA tests. > > > > > > *nod* Sounds good to me. > > > > > > > > > > what we have. I don't know how to quantify that point, though. All's I > > > > can do is reiterate that yes, this is a really significant pain point in > > > > our current processes, the proposed Bodhi 2.0 design would make things > > > > almost immeasurably better, and plead with anyone reading this who has > > > > the power to bump up the importance of / resources assigned to Bodhi > > > > 2.0's development to do so. > > > > > > So many things at top priority. :) I know Luke Macken is actually actively > > > working it. > > > > I know he is. He's been actively working on it for the said three-four > > year period. Every FUDCon/Flock he tells me it's nearly done. ;) > > > > Not ragging Luke, but it rather seems like we need about six more of Unfortunately, bodhi has not had dedicated full-time development resources in a long time. Thankfully, I now have the cycles to put into new features, such as improving the feedback mechanisms. Many components of the "Bodhi 2.0" vision are long-term, and rely on a plethora of other pieces to fall into place, such as python-fedora+fas-openid, koji+mash, taskotron, depcheck-mk-2, and so on. Other pieces of the puzzle can be implemented and deployed incrementally within the current tools now. My focus lately has been around the releng/infra side of the updates process, but for a feature that would make things 'immeasurably better' (even though I think it would actually be measurable :P), I'd be happy to shift gears to the QA/frontend side of things to help get it done sooner rather than later. As far as I can tell, you sent some ideas to a mailing list a few years ago about it, and then Mathieu started a prototype. I can't find any RFEs filed for it, so I'll create one and see what I can do about getting the existing prototype polished and integrated for testing. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On Wed, Jan 22, 2014 at 02:11:31PM -0500, Matthew Miller wrote: > On Wed, Jan 22, 2014 at 12:09:25PM +, Richard Hughes wrote: > > As the subject suggests, Fedora 22 will require applications to have a > > long description to be shown in the software center. We're introducing > > this change so that we can show a powerful application full of > > high-quality content, rather than what we have now which is a equal > > mixture of awesome and sadness. > > Has anyone looked at (or would it be interesting for someone to) integration > with https://apps.fedoraproject.org/tagger/? Richard already wrote a plugin :) https://github.com/GNOME/gnome-software/blob/e80d751ae0768a8969ff52e1cfc29a692a79bda0/src/plugins/gs-plugin-fedora-tagger.c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
bodhi 0.9.9 deployed
Hi all, A new version of bodhi has just hit production. This release contains a few karma-related changes that packagers should be aware of. https://admin.fedoraproject.org/updates Summary of changes -- * Reset the karma to 0 when new builds are added to an existing update (Mathieu Bridon) https://fedorahosted.org/fesco/ticket/1238 https://fedorahosted.org/bodhi/ticket/388 * Disable karma automatism upon AutoQA test failures (Luke Macken) https://fedorahosted.org/fesco/ticket/1242 https://github.com/fedora-infra/bodhi/issues/36 * Do not trigger the stablekarma threshold if the update is being pushed (Luke Macken) https://fedorahosted.org/bodhi/ticket/649 * Prefix the updateinfo file with its hash in the repo metadata (Mathieu Bridon) https://github.com/fedora-infra/bodhi/pull/35 * Fixed a bug with querying the RPM changelogs, which are used in update announcements (Mathieu Bridon) https://github.com/fedora-infra/bodhi/pull/38 Complete list of changes https://github.com/fedora-infra/bodhi/compare/0.9.8...0.9.9 Bugs & Enhancements --- If you encounter any issues, or want to suggest an enhancement, please file a ticket here: https://fedorahosted.org/bodhi/newticket pgpLyvZlcIKW5.pgp Description: PGP signature ___ 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About F19 Firewall
On Fri, Sep 20, 2013 at 10:15:33AM -0400, Matthew Miller wrote: > And, the python stack is a meaningfully-large portion of the minimal > install. Right now, that's unavoidable because of yum, but in the not-so-far > future dnf may make it possible to remove that. If we're putting in _more_ > python-dependent infrastructure code, we'll never get there. dnf is written in Python, so I don't think that'll be possible. The roadmap for 2.0 is apparently going to involve porting to Python3, which will most likely help with the memory usage, but not with the installation size. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How long do 0-karma packages stay in testing (in F20) now?
On Mon, Oct 14, 2013 at 11:10:19AM +0100, Paul Howarth wrote: > On 13/10/13 22:43, Kevin Fenzi wrote: > >On Sun, 13 Oct 2013 22:35:08 +0100 > >"Richard W.M. Jones" wrote: > > > >>Ah, easy when you know where! So it looks like 3 days, although some > >>have spent a bit longer, eg: > >> > >>https://admin.fedoraproject.org/updates/FEDORA-2013-18415/libguestfs-1.23.25-1.fc20 > >> > >>which seems to have spent 5 days in testing (before being obsoleted). > >>The actual push to testing event is not where it starts counting? > > > >It should be. I would have expected a bodhi message there on the 9th > >saying it could be pushed stable. > > I've been getting the bodhi messages after 7 days but could mark updates > stable after 3. So it seems the messages are out of sync with policy, but > bodhi itself is OK. Fixed. The F20 pre-beta policy configuration got out of sync with the bodhi masher, which runs those periodic nagmail jobs. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Releasing ownership of packages
On Wed, Feb 27, 2013 at 11:08:04AM -0500, Karel Klic wrote: > notmuch -- system for indexing, searching, and tagging email I'll take this one. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi - new update obsoleted an older update that had been submitted for stable
On Wed, Jan 20, 2016 at 07:17:10AM -0500, Josh Boyer wrote: > On Wed, Jan 20, 2016 at 5:55 AM, Richard Fearn wrote: > > Hi, > > > >> https://github.com/fedora-infra/bodhi/issues/763 > > > > You beat me to it :) Thanks for doing that! > > > > And Luke seems to have fixed the problem already. Thanks Luke! > > He fixed the code, but it isn't merged yet nor is it deployed in > Fedora Infrastructure from what I can tell. The fix is now in production. Sorry about the annoying regression, folks. Bodhi previously would avoid obsoleting updates that had an open request, even if it hasn't gotten pulled into a push yet. A recent improvement to this logic allows for updates with a testing request to get obsoleted if a newer update gets submitted before it gets "locked" into a push. The bug that snuck in allowed this to happen to unlocked updates with a stable request too. luke signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Build control-center in mock fail
On Wed, May 08, 2013 at 08:43:11AM +0400, Igor Gnatenko wrote: > https://admin.fedoraproject.org/updates/control-center-3.8.1.5-1.fc19?_csrf_token=348752c9889bf273010d694694059fece3649eae > I need bugfix of https://bugzilla.redhat.com/show_bug.cgi?id=955257 > In stable source FC19 with small patch I have same problem. > Karma: 2 > Stable karma: 2 > But > Pushed: False It also says 'Requested: stable', which means it's in the queue and will go out in the next stable push. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: \n in taskotron's depcheck messages
On Wed, Jan 07, 2015 at 07:58:49AM -0700, Dave Johansen wrote: > On Tue, Jan 6, 2015 at 4:12 PM, Kevin Fenzi wrote: > > On Tue, 6 Jan 2015 16:04:07 -0700 > Dave Johansen wrote: > > > I'm not sure if this is the right place to post this, but there are > > \n's in the messages from taskotron's depcheck. The problem is that > > some email clients (gmail in particular) parse that as part of the > > URL and make the links incorrect. It's a pretty minor thing, but > > would make it a lot easier to use and hopefully is an easy fix. > > Likely related to: > > https://fedorahosted.org/bodhi/ticket/767 > > > Ya, that looks like the same issue. Good to hear it's already on the radar. > Thanks, > Dave This started occurring after we upgraded from postgresql-server-8.4.20-1.el6 to postgresql-server-9.2.7-1.el7, and is probably a python-sqlobject bug. I pushed out a new version of bodhi this morning that works around this issue in the mean time. luke pgpre_RVThIEP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Bodhi policy for pushing updates to stable
On Thu, Jan 15, 2015 at 10:19:19AM +0100, Tomas Hozza wrote: > Hi all. > > When upgrading F20 to F21 using FedUp, some users had a problem > with some packages not being upgraded (e.g. [1]). The problem was > caused by broken update path F20 -> F21. > > For example in wget's case I pushed updates for the same NVR in F20 > and F21 with auto-karma. However the wget update for F20 got the > stable karma and was pushed to stable before the update for F21. > > I think bodhi should enforce the update path is not broken and > hold the update for F20 until the update for F21 is in stable. > I know I can do it manually and disable auto-karma and push updates > to stable as they should be. However I think such task should be > automated. > > Would it be possible to enforce such a thing for updates in bodhi? The broken upgrade path for the F20 wget update was detected by Taskotron[0], and then bodhi immediately disabled autokarma[1]. However, the stable karma threshold was reached about 5 minutes before it was detected, so it went out anyway. Bodhi2 already has Taskotron-based gating baked into the push process[2], but this specific issue can also be fixed in the current bodhi1 codebase. Upon Taskotron failure, if the update has already reached the stable karma threshold, bodhi should revoke the stable request. I opened an upstream ticket to track this issue[3] luke [0]: https://admin.fedoraproject.org/updates/FEDORA-2014-17194/wget-1.16.1-2.fc20 [1]: https://fedorahosted.org/fesco/ticket/1242 https://github.com/fedora-infra/bodhi/pull/41 [2]: https://github.com/fedora-infra/bodhi/pull/109 [3]: https://github.com/fedora-infra/bodhi/issues/116 pgpj3nyCP1nUt.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New bodhi release in production
A new version of bodhi has just hit production. This release contains
a number of bugfixes and improvements, along with some important process
changes.
https://admin.fedoraproject.org/updates
ChangeLog
=
- Package update acceptance criteria compliance
https://fedoraproject.org/wiki/Package_update_acceptance_criteria
- Disable direct-to-stable pushes
(https://fedorahosted.org/bodhi/ticket/434)
- Minimum time-in-testing requirements
- Every day bodhi will look for updates that have been
in testing for N days (fedora: N=7, epel: N=14), and will
add a comment notifying the maintainer that the update is
now able to be pushed to stable.
- When someone tries to push an update to stable, bodhi will
look to see if it has the appropriate karma, or if it has
been in testing for more than N days.
- Critical path update changes
- Hide obsolete updates in our critpath view
(https://fedorahosted.org/bodhi/ticket/447)
- Disabled strict critical path procedures for EPEL
- EPEL is back to the same process that it has always had
- Add a new nagmail message for unapproved critical path updates
- RSS feed & grid of unapproved critical path updates
https://admin.fedoraproject.org/updates/rss/rss2.0?critpath=True&release=F13
https://admin.fedoraproject.org/updates/critpath?unapproved=True&release=F13
- RSS feed & grid of user-specific comments
(https://fedorahosted.org/bodhi/ticket/445)
https://admin.fedoraproject.org/updates/comments?user=lmacken
https://admin.fedoraproject.org/updates/rss/rss2.0?comments=True&user=lmacken
- Package-specific RSS feeds of updates
(https://fedorahosted.org/bodhi/ticket/339)
https://admin.fedoraproject.org/updates/rss/rss2.0?package=kernel
- Add more links to the package-specific page
https://admin.fedoraproject.org/updates/TurboGears2
- Show 7 days worth of entries in our RSS feeds, as opposed to 20
entries (https://fedorahosted.org/bodhi/ticket/339)
- Bodhi command-line client fixes
- Output now goes to stdout, instead of stderr
(https://fedorahosted.org/bodhi/ticket/449)
(Thanks to Till Maas)
- Duplicate logging issue resolved
(https://bugzilla.redhat.com/show_bug.cgi?id=613533)
- Support using --critpath and --type with --testable
- Link to the submitter and release on the home page & testing
list (Thanks to Till Maas)
- Made the suggest_reboot flag actually configurable
(https://fedorahosted.org/bodhi/ticket/352)
- Notify the security team when an update is edited and turned into
a security update (https://fedorahosted.org/bodhi/ticket/403)
- Only verify the autokarma thresholds if it is enabled (Thanks to
Till Maas)
- Only touch bugs under the Fedora/EPEL Bugzilla products
(https://fedorahosted.org/bodhi/ticket/448)
- Prevent the masher from pushing obsolete updates
- Prevent obsolete updates from getting auto-promoted to stable
- Obsolete updates upon deletion, as opposed to destroying them.
- Added more unit tests (up to 122)
- Link up bug numbers and other URLs in the text of comments
- Document the `newpackage` update type in the bodhi-client commands
(https://bugzilla.redhat.com/show_bug.cgi?id=621828)
- Set bugs to MODIFIED upon submission
(https://fedorahosted.org/bodhi/ticket/343)
- Added a `bodhi --push-request={stable,testing}` command to
improve our releng updates push workflow
- A new /updates/releases JSON API and python-fedora
BodhiClient.get_releases() method for AutoQA
- Have the build auto-completion widget query candidate builds
from koji, as opposed to looking in /mnt/koji/packages
(https://fedorahosted.org/bodhi/ticket/173)
Bugs & RFEs
===
Please file and bug reports or enhancement requests here:
https://fedorahosted.org/bodhi/newticket
___
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
Re: New bodhi release in production
On 08/12/2010 07:12 PM, Orcan Ogetbil wrote: > On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote: >>- Minimum time-in-testing requirements >>- Every day bodhi will look for updates that have been >> in testing for N days (fedora: N=7, epel: N=14), and will >> add a comment notifying the maintainer that the update is >> now able to be pushed to stable. > > Suppose I submit a package to testing and it gets pushed. Six days > later, I find a terrible bug in the package (or a user reports this to > me). I fix the package and edit the update, request the fixed package > to be pushed to testing again and it gets pushed the next day. > > Now without any further testing the package can be pushed to stable, > which contradicts the purpose of this whole change in bodhi. > > I think, for packages that are modified during the testing period, > this N should be calculated from the day the last push was made to > testing. Yes, this was my initial intention. However, looking at the code a bit closer, your scenario would currently be allowed, as it currently only calculates the time-in-testing based on the first push to testing. Fixed in https://fedorahosted.org/bodhi/changeset/97b1a9d1f9ceecaaa2128837cc5bbd7f8e495f36 luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/12/2010 07:15 PM, Kevin Kofler wrote: > Orcan Ogetbil wrote: >> Now without any further testing the package can be pushed to stable, >> which contradicts the purpose of this whole change in bodhi. > > Sssh, why can't you keep quiet about this?! > >> I think, for packages that are modified during the testing period, >> this N should be calculated from the day the last push was made to >> testing. > > NO! I really don't want any small fix to my update to restart the whole > testing cycle from scratch! Imagine I want to edit something in the update > notes, e.g. add a Bugzilla reference, I have to edit the update for that, > but does this warrant new testing? No! Ok, so the problem here is that bodhi unpushes updates when you edit *anything* in it. If it only unpushed an updated when you add/remove builds from it, then this scenario would be sane. I'm going to tackle this issue next, to ensure that you can add bugs/notes to a testing update without having it reset the time-in-testing. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 07:20 AM, Michael Schwendt wrote: > On Thu, 12 Aug 2010 17:57:28 -0400, Luke wrote: > >> A new version of bodhi has just hit production. This release contains >> a number of bugfixes and improvements, along with some important process >> changes. > >> - Minimum time-in-testing requirements >> - Every day bodhi will look for updates that have been >> in testing for N days (fedora: N=7, epel: N=14), and will >> add a comment notifying the maintainer that the update is >> now able to be pushed to stable. > > This sent notifications also for packages in "pending". > > | bodhi - 2010-08-12 21:09:52 (karma: 0) > | This update has reached 274 days in testing and can be pushed > | to stable now if the maintainer wishes Yes, this happened due to a last-minute tweak I made in the approve_testing_updates job. I have since reverted this change. Ideally, we shouldn't have obsolete updates in the pending state. I think when an update is unpushed, it currently gets moved back to pending. I'll most likely change this to make it 'obsolete' the update instead. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 11:29 AM, Till Maas wrote: > On Fri, Aug 13, 2010 at 01:27:18AM +0200, Kevin Kofler wrote: > >> "fix" breaks that. Plus, edits can also be only to the description or bug >> references, Bodhi doesn't allow me to edit those without editing the whole >> update. > > Bodhi also allows you to edit the stable karma value and unless it is > implemented differently (or has changed again), you can just use a > stable karma value of 1 and ask someone except the update submitter to > provide the +1 karma and the update can be pushed to stable. This is > imho reasonable even after only a one line change to a build. I think this is currently a viable option. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 01:57 AM, Ralf Corsepius wrote: > On 08/13/2010 01:23 AM, Luke Macken wrote: >> On 08/12/2010 07:12 PM, Orcan Ogetbil wrote: >>> On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote: >>>> - Minimum time-in-testing requirements >>>> - Every day bodhi will look for updates that have been >>>>in testing for N days (fedora: N=7, epel: N=14), and will >>>>add a comment notifying the maintainer that the update is >>>>now able to be pushed to stable. >>> >>> Suppose I submit a package to testing and it gets pushed. Six days >>> later, I find a terrible bug in the package (or a user reports this to >>> me). I fix the package and edit the update, request the fixed package >>> to be pushed to testing again and it gets pushed the next day. >>> >>> Now without any further testing the package can be pushed to stable, >>> which contradicts the purpose of this whole change in bodhi. >>> >>> I think, for packages that are modified during the testing period, >>> this N should be calculated from the day the last push was made to >>> testing. > > This would very unhelpful. > >> Yes, this was my initial intention. However, looking at the code a bit >> closer, your scenario would currently be allowed, as it currently only >> calculates the time-in-testing based on the first push to testing. > This behavior is helpful, because otherwise updates would "starve". The only case for update starvation that I can think of is if you keep adding/removing builds from an update before it reaches a week in testing or the karma thresholds. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/12/2010 07:47 PM, Orcan Ogetbil wrote: > On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote: >>- Minimum time-in-testing requirements >>- When someone tries to push an update to stable, bodhi will >> look to see if it has the appropriate karma, or if it has >> been in testing for more than N days. > > I have another question: > > What happens if a package is submitted to testing the same day on > F-(x) and F-(x+1), then the F-(x) package reaches +3 karma the next > day and is automatically pushed to stable? Let's say the F-(x+1) > package still has 0 karma (or maybe even negative karma). > > The F-(x) package will have higher EVR than the F-(x+1) one. This > will break the upgrade path. Is there any measures to prevent this? Bodhi checks for broken upgrade paths upon submission, but this would not mitigate the breakage that you describe here. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/13/2010 10:16 AM, Till Maas wrote: > On Thu, Aug 12, 2010 at 05:57:28PM -0400, Luke Macken wrote: > >> - Show 7 days worth of entries in our RSS feeds, as opposed to 20 >> entries (https://fedorahosted.org/bodhi/ticket/339) > > This is nice, I forgot to add myself to the CC list, so I did not notice > this before. > >> - Only verify the autokarma thresholds if it is enabled (Thanks to >> Till Maas) > > This is still faulty. Is there a way to get access to a running bodhi > instance that I can patch and test directly? A local instance set up > according to > https://fedorahosted.org/bodhi/wiki/Development > does not allow to edit updates, because of tagging problems. Making this > possible would of course be great. I just pushed out a fix that should allow you to edit updates with your local development instance. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On 08/14/2010 07:17 AM, Till Maas wrote: > On Fri, Aug 13, 2010 at 07:07:44PM -0400, Luke Macken wrote: > >> I just pushed out a fix that should allow you to edit updates with your >> local development instance. > > Thank you very much, it works. Patches for the autokarma javascript will > soon be attached to bodhi's trac. With these, there is only a cosmetic > issue left afaics. Excellent, thank you! > Btw. would you mind if I triage some Bodhi tickets and close the ones I > think are fixed in the current version? If they are not, the original > submitter can still re-open them. That would be great. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [kernel/f14/master] add in patch from lmacken to support more mac models with efifb
TEM_ID("Apple Inc.", "MacBookPro3,1", M_MBP_SR),
> diff --git a/kernel.spec b/kernel.spec
> index d5c3638..77630ec 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -48,7 +48,7 @@ Summary: The Linux kernel
> # reset this by hand to 1 (or to 0 and then use rpmdev-bumpspec).
> # scripts/rebase.sh should be made to do that for you, actually.
> #
> -%global baserelease 13
> +%global baserelease 14
> %global fedora_build %{baserelease}
>
> # base_sublevel is the kernel version we're starting with and patching
> @@ -663,6 +663,8 @@ Patch1824: drm-intel-next.patch
> Patch1825: drm-intel-make-lvds-work.patch
> Patch1900: linux-2.6-intel-iommu-igfx.patch
>
> +Patch2000: efifb-add-more-models.patch
> +
> # linux1394 git patches
> Patch2200: linux-2.6-firewire-git-update.patch
> Patch2201: linux-2.6-firewire-git-pending.patch
> @@ -1262,6 +1264,8 @@ ApplyOptionalPatch drm-intel-next.patch
> ApplyPatch drm-intel-make-lvds-work.patch
> ApplyPatch linux-2.6-intel-iommu-igfx.patch
>
> +ApplyPatch efifb-add-more-models.patch
> +
> # linux1394 git patches
> #ApplyPatch linux-2.6-firewire-git-update.patch
> #ApplyOptionalPatch linux-2.6-firewire-git-pending.patch
> @@ -1892,6 +1896,10 @@ fi
> # and build.
>
> %changelog
> +* Tue Aug 31 2010 Kyle McMartin 2.6.35.4-14
> +- efifb-add-more-models.patch: Add patch from Luke Macken to
> + support more Mac models (rhbz#528232)
> +
> * Tue Aug 31 2010 Dave Jones 2.6.35.4-13
> - Fix incorrect DMA size freeing error in via-velocity.
>
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
bodhi v0.7.9 deployed
A new version of bodhi has just hit production. This release contains a number
of bugfixes and enhancements.
https://admin.fedoraproject.org/updates
Web UI Changes
==
- Improved editing functionality
- Only unpush edited updates when builds are altered
- Make a note in the comments of which builds were added/removed
- Allow people to revert their karma vote more than once
- Add mouseover tooltips to the update status with more details
- Prevent different versions of a package from being added to the same update
- Handle more types of bugzilla auto-linking in comments (ex: rhbz#1234)
- Link to the newer update in the obsoleted ones
- Link to gitweb instead of viewvc
- Set default (un)stable karma values if re-enabled
- Anonymous karma has never effected karma, so we now mark them as being ignored
in the interface to make it obvious
- Get the 'suggest reboot' flag working again
- Allow non-critpath updates to be pushed to stable after meeting our critpath
requirements
- Allow maintainers to request that their update be pushed to stable before the
automatic approval job runs, if it already meets the time-in-testing
requirements.
Client Changes
==
- Add --stablekarma, --unstablekarma, and --disable-autokarma client arguments
- Fix a bug in using `bodhi --push-build=` on multi-build updates
- Add a --bodhi-url command-line option
- Instead of requiring only one argument with a comma separated list of updates,
support several builds as several arguments.
API Changes
===
- Remove our API pagination query limit of 1000
- Add a new 'author_group' field to each comment in our JSON API
Backend Changes
===
- Add the new 'dist-fN-updates{-testing,}-pending' tags to builds so AutoQA can
start testing them before they get pushed
- List security & critpath testing updates in our updates-testing digest emails
- Download and inject the pkgtags sqlite db into our repodata from the pkgdb
(which will be utilized by `yum search`)
- Email the proventesters about stale unapproved critical path updates
- Update the bug titles for all security updates before pushing (since security
bug titles frequently change after the update is submitted to reflect the CVE
id)
- Improved sanity checking in the masher when resuming pushes
- Properly capture & log stderr from our mash subprocess
- Improved metrics report generator (soon to be integrated into the web
interface)
Bugs & RFEs
===
Please file and bug reports or enhancement requests here:
https://fedorahosted.org/bodhi/newticket
___
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
Re: bodhi v0.7.9 deployed
On Mon, Sep 20, 2010 at 02:19:06PM -0400, Luke Macken wrote:
> Backend Changes
> ===
>
> - Add the new 'dist-fN-updates{-testing,}-pending' tags to builds so AutoQA
> can
> start testing them before they get pushed
> - List security & critpath testing updates in our updates-testing digest
> emails
> - Download and inject the pkgtags sqlite db into our repodata from the pkgdb
> (which will be utilized by `yum search`)
> - Email the proventesters about stale unapproved critical path updates
> - Update the bug titles for all security updates before pushing (since
> security
> bug titles frequently change after the update is submitted to reflect the
> CVE id)
> - Improved sanity checking in the masher when resuming pushes
> - Properly capture & log stderr from our mash subprocess
> - Improved metrics report generator (soon to be integrated into the web
> interface)
I forgot to add a couple more changes in this release:
- Security updates no longer need to be "approved" before they go to testing
- Update announcement mails no longer butcher the formatting of the notes
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi v0.7.9 deployed
On Thu, Sep 23, 2010 at 10:10:16AM +0200, Michael Schwendt wrote: > On Mon, 20 Sep 2010 14:19:06 -0400 (EDT), Luke wrote: > > > A new version of bodhi has just hit production. This release contains a > > number > > of bugfixes and enhancements. > > > > https://admin.fedoraproject.org/updates > > > - Email the proventesters about stale unapproved critical path updates > > But daily? For F12, F13 and F14? This is a lot of noise, and I wonder > what its goal is? Other than to see these messages be filtered and ignored. This was kind of a "lets start spamming and see who complains" feature. It /should/ only send 1 nagmail a week for each unapproved critical path update that has been in testing for over 2 weeks. However, now that the updates-testing digests will contain security/critpath updates that need testing, firing these off to the proventesters may suffice instead? luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Mon, Nov 01, 2010 at 09:35:49AM -0600, Kevin Fenzi wrote: > On Sun, 31 Oct 2010 10:16:41 -0400 > "Clyde E. Kunkel" wrote: > > > On 10/31/2010 03:18 AM, Michael Schwendt wrote: > > > Okay, feedback time. > > > > > > Lately, there have been several attempts at urging proventesters > > > (and not just testers in general) to give positive karma for aging > > > critpath updates. It also has been decided by someone (or maybe > > > even a comittee) to spam proventesters daily with > > > "[old_testing_critpath]" messages for all three dist releases, with > > > no day to unsubscribe from that (other than leaving proventesters > > > group, which is what at least one person has threatened with, or > > > filtering those messages). > > Yeah, I am not sure at all how usefull those emails are. > There are a variety of ways to see what things need testing, sending > emails to proventesters a bunch isn't likely to be a very nice one. I've disabled this behavior in git, and will update our production instance this week. This spam is unnecessary now that this information is available in the updates-testing digests sent to the test list. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Fri, Nov 12, 2010 at 11:46:36AM -0800, Adam Williamson wrote: > On Fri, 2010-11-12 at 14:32 -0500, Tom Lane wrote: > > > It's absolutely crystal clear to me that we don't have enough tester > > manpower to make the current policy workable; it's past time to stop > > denying that. I'd suggest narrowing the policy to a small number of > > critical packages, for which there might be some hope of it actually > > working as designed. > > BTW, another point worth noting is that there is not actually a specific > rule against +1ing your own updates. It's 'frowned upon', I guess, but > actually I think it's probably workable to say it's fine for the > developer to +1 their own update in Bodhi: *as long as you actually have > tested it*. For non-critpath updates especially. The Bodhi system is > essentially an honor system anyway. So how I'd see this working is if it > becomes clear that some maintainer is gaming the system by just +1ing > everything they submit, even if it actually turns out to be broken, we > look at saying they can't +1 their own updates any more. But if you > actually are conscientiously testing your own updates, that's probably > worth a +1 in Bodhi, for me. The ability to +1 your own updates was disapproved by FESCo, and will be disabled in a future version of bodhi. https://fedorahosted.org/bodhi/ticket/277 luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Mon, Nov 29, 2010 at 01:36:18PM +, Petr Pisar wrote: > On 2010-11-29, Peter Robinson wrote: > > On Mon, Nov 29, 2010 at 9:56 AM, Petr Pisar wrote: > > > > Proven testers do get copies of these emails (dozens of them) and its > > also summarised in the updates-testing report for all to see. > > > Oh, I thought described as `For testers of Fedora > development releases' concerns alpha and similar (pre-)releases only. > > In that case, only one issue remains: to stop spamming package > maintainer. The next release of bodhi that I'm going to push out to our releng servers this week will stop spamming proventesters and maintainers about these, since this data is now in the updates-testing digests that get sent out to the test-list with each push. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Wed, Dec 01, 2010 at 10:41:20AM -0800, Adam Williamson wrote: > On Wed, 2010-12-01 at 13:23 -0500, Doug Ledford wrote: > > > That being said, F14 went out with a broken mdadm *purely* because of > > this policy. > > > Evidently my update was approved somewhere along the way, but because of > > the volume of bodhi spam I get, I missed it. > > ...so what you're saying is that F14 did not in fact go out with a > broken mdadm *purely* because of the policy, but in a small part because > of the policy and in a large part because you don't read / filter your > emails carefully enough. > > > So I'm not sure if it > > could have made F14 final or not, but I know it didn't because I was > > working on other things at the time. > > bodhi - 2010-10-14 22:36:08 > Critical path update approved > > The final change deadline was 10-18; you had four days to push the > update. Also, if karma automatism was enabled for that update, it would have been queued for pushing right when it was approved. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Wed, Dec 01, 2010 at 04:49:07PM -0500, Doug Ledford wrote: > On 12/01/2010 04:40 PM, Luke Macken wrote: > > On Wed, Dec 01, 2010 at 10:41:20AM -0800, Adam Williamson wrote: > >> On Wed, 2010-12-01 at 13:23 -0500, Doug Ledford wrote: > >> > >>> That being said, F14 went out with a broken mdadm *purely* because of > >>> this policy. > >> > >>> Evidently my update was approved somewhere along the way, but because of > >>> the volume of bodhi spam I get, I missed it. > >> > >> ...so what you're saying is that F14 did not in fact go out with a > >> broken mdadm *purely* because of the policy, but in a small part because > >> of the policy and in a large part because you don't read / filter your > >> emails carefully enough. > >> > >>> So I'm not sure if it > >>> could have made F14 final or not, but I know it didn't because I was > >>> working on other things at the time. > >> > >> bodhi - 2010-10-14 22:36:08 > >> Critical path update approved > >> > >> The final change deadline was 10-18; you had four days to push the > >> update. > > > > Also, if karma automatism was enabled for that update, it would have been > > queued for pushing right when it was approved. > > > > luke > > I don't enable karma automatism because in the past I've seen people > report testing karma +1 when they did not, in fact, doing anything > useful in terms of testing (aka, they had no software raid devices, yet > they said the system still works...well, duh, it's only used on software > raid devices so if you don't have any, then it doesn't make any > difference to you). Yep, that happens. There are also people that add +0 comments to updates saying "Untested". There is an obvious need for more fine-grained karma types. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New bodhi release in production
A new release of Bodhi has just been deployed to production. https://admin.fedoraproject.org/updates Bugs and enhancement requests can be filed here: http://bodhi.fedorahosted.org Major changes in bodhi 0.9.2 - fedmsg support! Bodhi now fires off messages for various events that occur. Join #fedora-fedmsg to see it in action. (Ralph Bean) - Re-organized the links on the front page, and link to the new Update Feedback Guidelines - The submitter of an update can no longer effect the karma (Till Maas) - Fix duplicate status change email notifications. (Till Maas) - Mention age of updates in testing digest mails (Till Maas) - Support e-mail threading in notification e-mails (Till Maas) - Add X-Bodhi mail headers (Till Maas) - Gracefully handle private bugs (Cole Robinson) - Set the default request for new updates to 'testing' in the web form - Fix a bug in our critpath policy that occurs when a critical path update to a pre-release reaches the minimum amount of time in testing, but is unable to push to stable. - Fixed the input box alignment in the login box (Kalpa Welivitigoda) Full list of changes since 0.8.7 Kalpa Welivitigoda (1): fixed input box alignment issue in login box #579 Luke Macken (25): Convert our tags_url to a byte string before passing it to urlgrabber. Add a script to detect when older builds become the 'latest' in stable Update our test suite to reproduce ticket [ticket:683] Fix a bug in our critpath policy ([ticket:683]). Set the default request for new updates to 'testing' Clean up EOL buildroot overrides in our rmrelease tool (bz#818617) Fix a busted unit test (test_push_EPEL_critpath_before_tested) Add pkg_resources __requires__ hacks to bodhi tools to mitigate version conflicts Handle the case where a release doesn't have any overrides Change our X-Bodhi-Update-Release header to use the short name Apply a modified patch from Cole Robinson to gracefully handle private bugs (#639605) Update our unit tests to assume submitters cannot alter karma Merge branch 'bodhi1-fedmsg' into feature/bodhi1-fedmsg Merge branch 'feature/bodhi1-fedmsg' into develop Fix a typo in the metrics tool Fix a typo in the new mail headers Re-organize our links, and add one to the new update feedback guidelines Clean up stray buildroot overrides Version bump for 0.9.2 Our build script uses bz2 Merge branch 'release/0.9.2' Mathieu Bridon (6): Have bodhi-init create all the tables masher: Fix the comparison masher: Reuse variable setup: Fix the Turbogears version requirement Don't version control auto-generated files setup: Add missing dependencies Ralph Bean (19): Sending messages with fedmsg. No longer using fedmsg schema/validation. fedmsg.ini -> fedmsg-config.py More detail in the update.complete message. More concise send_message calls. Ignore dev db. Merge branch 'master' into bodhi1-fedmsg Updates for the latest fedmsg. Getting tests passing. Merge branch 'master' into bodhi1-fedmsg Ignore mashing fedora file. Fixed what I think is a regression in login template. Merge branch 'master' into bodhi1-fedmsg Update to test fedmsg config. Work with both tests and under WSGI. Version bump for fedmsg in staging. Only send the comment with a comment is added, not the whole update. Using a "bodhi" user/group for mod_wsgi. fedmsg+ssl changes to bodhi.spec. Use modern fedmsg config format. Disable message signing for bodhi tests. Till Maas (8): Add X-Bodhi mail headers Support e-mail threading in notification e-mails Mention age of updates in testing digest mails Use format string instead of string concatenation Import exceptions from sqlite3 Remove files used by mercurial model.py: Change karma from Submitter to 0 Fix notification on automatic status change ___ 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
Re: Bodhi issues
On Sat, Aug 11, 2012 at 12:01:15PM -0600, Orion Poplawski wrote: > I just got: > > 500 Internal error > > The server encountered an unexpected condition which prevented it from > fulfilling the request. > > Powered by CherryPy 2.3.0 > > submitting a karma update to an update. It did take something because I got > email(s) of my comments This issue should be resolved. Can you try again? Thanks, luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi issues
On Mon, Aug 13, 2012 at 03:13:20PM -0500, Bruno Wolff III wrote: > On Mon, Aug 13, 2012 at 12:29:52 -0600, > Orion Poplawski wrote: > >On 08/13/2012 11:51 AM, Luke Macken wrote: > >> > >>This issue should be resolved. Can you try again? > >> > > > >I posted a karma comment recently without issue. > > I just got a 500 status twice, though both copies of the comment ended up > being recorded. Sorry about that, it looks like my fix didn't make it's way out to all of the app servers. Should be all set now. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
bodhi 0.9.3 deployed to production
A new bugfix release of Bodhi has just been deployed to production. https://admin.fedoraproject.org/updates Bugs and enhancement requests can be filed here: http://bodhi.fedorahosted.org Major user-facing changes in 0.9.3 -- - Bodhi will no longer alter the bug status if it is already VERIFIED or ON_QA - Fixed grid pagination (Mathieu Bridon) - Allow CLI users to enable automatic bug closing (Ralph Bean) - Automatically submit updates that are edited with new builds back to testing - Fixed Message-ID and X-Bodhi message headers (Till Maas) - Publish messages upon buildroot override tag/untag (Ralph Bean) - Don't trigger fedmsg notifications for internal bodhi or autoqa comments Full list of changes ---- Luke Macken (25): Sync up our specfic with rawhides Fix an out of order changelog entry Suppress tgmochikit, and include it in the one place that we actually need it. Revert "Suppress tgmochikit, and include it in the one place that we actually need it." The tooltip.css was merged into our main stylesheet Require python-tgcaptcha2 Move the deployment message to master.kid, and tweak the style Don't send messages for internal bodhi comments Don't send messages for autoqa comments Fix the deployment status in the genshi template as well Avoid calling fedmsg from our MashTask until it is thread-safe. Don't add email headers for buildroot overrides Reference the update in the Comment.__json__ for fedmsg Revert "Reference the update in the Comment.__json__ for fedmsg" Cast our SQLObject results set to a list Revert "Avoid calling fedmsg from our MashTask until it is thread-safe." import fedmsg helps Require fedmsg 0.3.3+ for thread safety Add the update_title to our Comment.__json__ Fix fedmsg requirement Submit updates that are edited with new builds back to testing (#678) Fix a typo Handle cookielib.LoadErrors when initializing python-bugzilla. Don't change the bug status if it is already VERIFIED (#698) Bump version to 0.9.3 Mathieu Bridon (8): Improved message after new Buildroot override Prettify an error message Fix unit test Use the new TurboGears pagination parameter The Fedora infrastructure moved to cgit Make the 'Administration' button more useful Only suggest candidate builds Remove unused parameter Patrick Uiterwijk (1): Add different headers for different deployment types Ralph Bean (8): s/send_message/publish/ Some more fedmsg notifications. Publish messages on buildroot_override tag and untag. Merging. Agent information for fedmsg. Allow CLI users to enable automatic bug closing. Removed tools/fedmsg-watch.py (it was from *way* back in the day). Change fedmsg topic from done to complete (for consistency). fedmsg config values required for zeromq3. Remi Collet (1): Fix config for Apache >= 2.4 Till Maas (3): Use a string for X-Bodhi-Update-Builds mail header Fix generated message IDs model: fix closing of bugs using bz._update_bug ___ 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
Re: bodhi 0.9.3 deployed to production
On Thu, Nov 15, 2012 at 05:52:23AM +0100, Kevin Kofler wrote: > Luke Macken wrote: > > A new bugfix release of Bodhi has just been deployed to production. > > > > https://admin.fedoraproject.org/updates > > > > Bugs and enhancement requests can be filed here: > > > > http://bodhi.fedorahosted.org > > This seems to be closing bugs as CURRENTRELEASE rather than ERRATA now, is > that intentional? If yes, why? This change slipped through the cracks when fixing a problem with closing bugs with python-bugzilla. https://fedorahosted.org/bodhi/changeset/0f2651f2095bc5952468d2eb0af39ecc077521e3/ I just changed it back to CLOSED->ERRATA in git. Thanks for the heads up, luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bugz.fedoraproject.org trouble
On Fri, Dec 07, 2012 at 11:52:40PM +0100, Michael Schwendt wrote: > On Fri, 7 Dec 2012 11:46:49 -0500, Ralph Bean wrote: > > > > http://bugz.fedoraproject.org/SOURCE-RPM-NAME > > > e.g. > > > http://bugz.fedoraproject.org/gnome-packagekit > > > I introduced the switch-over as per this ticket > > https://fedorahosted.org/fedoracommunity/ticket/381 > > Waiting for fedorahosted.org… > > It has taken several attempts and unusually long time to load that ticket. Our Trac instances have definitely been dragging lately. Help wanted: https://fedorahosted.org/fedora-infrastructure/ticket/3582 > I've noticed the new web page interface some days ago, and it has rarely > managed to complete loading the dynamic contents without displaying > errors. Yeah, after the last Bugzilla upgrade multicall queries stopped working, and a lot of our apps have suffered. https://bugzilla.redhat.com/show_bug.cgi?id=824241 I'm working on a few optimizations to the fedora-packages bugs dashboard, but until this bug gets fixed it's not going to be fast. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: json error from bodhi update
Excerpts from Neal Becker's message of Fri May 20 07:40:41 -0400 2011:
> 3083146 build (dist-f14-updates-candidate,
> /uncrustify:6a8dd0eea2183240177154f27c10a730f20994eb) completed successfully
> Creating a new update for uncrustify-0.58-1.fc14
> ServerError(https://admin.fedoraproject.org/updates/save, 200, Error returned
> from json module while processing
> https://admin.fedoraproject.org/updates/save:
> No JSON object could be decoded: line 1 column 0 (char 0))
> Traceback (most recent call last):
> File "/usr/bin/bodhi", line 201, in main
> data = bodhi.save(**extra_args)
> File "/usr/lib/python2.7/site-packages/fedora/client/bodhi.py", line 111,
> in
> save
> 'bugs': bugs,
> File "/usr/lib/python2.7/site-packages/fedora/client/baseclient.py", line
> 344,
> in send_request
> auth_params=auth_params, retries=retries)
> File "/usr/lib/python2.7/site-packages/fedora/client/proxyclient.py", line
> 427, in send_request
> {'url': to_bytes(url), 'err': to_bytes(e)})
> ServerError: ServerError(https://admin.fedoraproject.org/updates/save, 200,
> Error returned from json module while processing
> https://admin.fedoraproject.org/updates/save: No JSON object could be
> decoded:
> line 1 column 0 (char 0))
I'm seeing the POST requests in logs, but they're not hitting bodhi's
controller. This usually happens when the account system is having
issues, or when an exception is tossed in the identity layer of bodhi.
I believe there is already an upstream ticket to handle this better.
Try doing `rm ~/.fedora/.fedora_session` then resubmit your update.
luke
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Bodhi v0.8 in production
https://admin.fedoraproject.org/updates Frontend Web/Client Changes --- * Buildroot Override Management http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides * Make update notes mandatory (fesco#457) * Gracefully handle invalid update template values (#597) * Fixed a bug that would prevent people from editing updates Backend Changes --- * Support blacklisting certain users from receiving bodhi emails (for autoqa) * More robust handling of 'pending' koji tags (#594) * More configurable for non-Fedora deployments * Added more metrics to our report generator * # of updates that reach the stable karma threshold * # of updates that spent the minimum time in testing * # of proventester karma types * output: https://fedorahosted.org/fesco/ticket/517#comment:5 API Changes --- * Optimize our 'list' API when querying updates by bug number (#610) * Support adding comments without triggering email notifications (to prevent AutoQA spamming) signature.asc Description: PGP signature ___ 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
Re: how to push to stable?
Excerpts from José Matos's message of Mon Jun 13 03:26:03 -0400 2011: > On Monday 13 June 2011 08:09:48 Honza Horak wrote: > > I think bodhi behaves correctly, but this auto-generated message is a > > failure, while according https://fedoraproject.org/wiki/Updates_Policy a > > non critical package must spend at least one week in updates-testing. > > > > I've reported the same issue before a couple of days: > > https://fedorahosted.org/bodhi/ticket/614 > > > > After one week a package can be submitted for stable without any problems. > > > > Cheers, > > > > Honza > > That is probably a leftover from the development stage of F15 where the > threshold time was three days. Now that F15 was released this does not hold > any more, it goes back to one week but it seems that the timer was not set > accordingly. Yep, this is eactly what happened. While implementing the different pre-release phases in bodhi for F15, I accidently hardcoded some of these values in bodhi's config. F15 is now back to the 7 days in testing minimum requirement. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi v0.8 in production
Excerpts from Stephen Gallagher's message of Mon Jun 13 13:02:29 -0400 2011: > This is a great feature. Is there a guide somewhere on how to use it? > > If not, can you point me at the relevant upstream documentation and I'll > write up an SOP for doing this. This is the closest thing to a guide that we have at the moment, which could definitely use some improvements: http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides The old SOP can be found here, and I added a little deprecation message at the top: http://fedoraproject.org/wiki/Buildroot_override_SOP luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Guide to setting karma thresholds?
Excerpts from Kevin Fenzi's message of Mon Jun 13 12:49:43 -0400 2011: > On Mon, 13 Jun 2011 10:43:42 -0500 > Michael Ekstrand wrote: > > > I'm working on pushing my first bugfix to F15 (#711261), using the > > guides I found in the wiki[1][2]. For a non-critical-path package, > > the Update Policy says that it needs to meet the positive karma > > threshold set by the submitter, but does not indicate what that > > threshold should be or guidance for determining appropriate values. > > The default is 3; I'm assuming that leaving it there is a reasonable > > thing to do (and I won't be surprised if the 7-day criteria will be > > hit first for this package). > > > > However, I am still wondering: is there any guidance or policy > > published on how to determine appropriate karma thresholds? What > > justifies increasing or decreasing the thresholds? Userbase? Impact > > of change? > > There isn't that I know of. ;) Perhaps this would be a good chance to > try and draft one. In the end it's up to the maintainer, but there > could be some ideas to help along. Off the top of my head: Yeah, we have yet to step back and really think about the defaults for the karma thresholds, after having the +3/-3 defaults for so long. Some maintainers set the values very low to decrease the amount of time their update spends in testing, and some set the values really high (or disable them) to ensure that their update doesn't change state without mantainer intervention. It's designed to fit both maintainer styles. > * Are the changes small/well contained (less karma) > * Is this a security update with a single security change (less karma) > * Is this a popular package with lots of testers (more karma) > * Is this something that has been tested already by upstream or another > distro? (less karma) > * Is this a bug that only affects a small number of users? (more karma) > * Is there likely to be another update soon? (less if you want to try > and get this fix out now, more if you just wanted testing on this, to > be obsoleted by another update when ready). These are all sound suggestions, but it seems like they refer to the stable karma threshold only. There are still a variety of scenarios for setting different unstable threshold values. For example, for updates that shouldn't cause *any* problems/regressions, setting an unstable threshold to -1 would cause the update to back-out as soon as anyone encounters a single issue. On the other hand, some updates, like the kernel, are inevitably going to get a bunch of negative karma no matter what so this wouldn't be ideal for that case. Hopefully we can come up with and document some best-practices for this based on maintainer experience. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Wed, Dec 01, 2010 at 02:02:48PM -0800, Adam Williamson wrote: > On Wed, 2010-12-01 at 16:54 -0500, Luke Macken wrote: > > > Yep, that happens. There are also people that add +0 comments to > > updates saying "Untested". There is an obvious need for more > > fine-grained karma types. > > I've sent out notes to the test list to ask people not to do either of > those things in future, I think the occurrence of them has gone down > significantly since those emails went out. (I also updated the proven > tester instructions page). > > More fine-grained karma is still coming in Bodhi 2.0, right? My > understanding was that we'd already agreed on the framework for it (in > those threads on this list a few months back) and we were just waiting > for the implementation now. Yes, that's the plan. I finally got the Bodhi v2.0 plans/ideas/status out of my brain and on to the wiki: https://fedoraproject.org/wiki/Bodhi/2.0 I linked to a couple of pages regarding karma improvements, but please update it with any more recent discussions regarding this change if you know of any. Also, more QA feature ideas are welcome. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
bodhi v0.7.10 production update
I just pushed a new release of bodhi into production. http://bodhi.fedoraproject.org It's a minor release that contains a small number of fixes, including: Backend bug fixes - Don't try and remove the -pending koji tags when resuming a push - Don't fetch security bug details when resuming a push - Don't show obsolete critpath updates in our testing digest - Ensure the updateinfo epoch is '0' as opposed to None (rel-eng#3971) - Stop spamming proventesters with old critpath mails, as this data is available in the updates-testing digests that go out with each push Web frontend changes - Fix the testing status tooltips for EPEL (#486) - Add the update ID back to the search results (#558) - Don't hide updates that are not approved by the security team from the admin push view, since we no longer require approval API changes (for AutoQA) - Support querying and commenting on updates by the Update ID, as well as title Tool changes - Make `bodhi --push-type` work for updates going to testing as well as stable (rel-eng only) - Add pkg_resources __requires__ hacks to get things working on F14 As always, please file tickets here: https://fedorahosted.org/bodhi/newticket Thanks, luke ___ 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
Re: AutoQA Comments in Bodhi
On Wed, Mar 23, 2011 at 03:00:52PM -0600, Tim Flink wrote: [...] > Two bugs were found in Bodhi's tag handling logic and we're hoping for > fixes in the next day or so. Once those fixes are in and we've verified > that the tests are pulling in packages correctly, we'll re-enable > AutoQA's Bodhi comments with less spam and more testing awesomeness. I just fixed[0][1] the two tagging issues that I mentioned yesterday and pushed out a new release to production. I also went through and cleaned up stray builds with the pending tags. Hopefully this will solve the problem. If it doesn't, then I know of a way to easily brute-force the solution in bodhi's push process. Thanks for all of the great work you guys have done with AutoQA. We are very close to solving the 4-year-old bodhi ticket #79[2]! :) luke [0]: https://fedorahosted.org/bodhi/changeset/b12c324072823df7ee1afe7b681f1d0df2f6c97b [1]: https://fedorahosted.org/bodhi/changeset/6402bad40bb587934ae6a126fa35c86be4ccf3ac [2]: https://fedorahosted.org/bodhi/ticket/79 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi hash collision?
On Thu, Feb 18, 2010 at 03:57:58PM -0500, Josh Kayse wrote: > On 02/18/2010 02:35 PM, Jonathan Underwood wrote: > >Hi, > > > >I just logged into the bodhi web interface and clicked on "my > >updates". In the list I see a recent package I pushed to testing - > >shorewall-4.4.6-2.fc12. When I click on it, it takes me to a screen > >for luckybackup-0.3.5-2.fc12. Something seems to have gone awry with > >the hash generation or linking or something. I'd file a bug report but > >I am not sure where the problem lies exactly. Any pointers? > > > >Cheers, > >Jonathan > Both packages have the same Update ID. You can access your update > by going to > https://admin.fedoraproject.org/updates/shorewall-4.4.6-2.fc12 It looks like today's push started overlapping IDs... I'm looking into it, and will reassign ID's once it is fixed. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi hash collision?
On Sat, Feb 20, 2010 at 01:42:29AM +0100, Christian Krause wrote: > Hi Luke, > > On 02/18/2010 10:08 PM, Luke Macken wrote: > > On Thu, Feb 18, 2010 at 03:57:58PM -0500, Josh Kayse wrote: > >> On 02/18/2010 02:35 PM, Jonathan Underwood wrote: > >>> Hi, > >>> > >>> I just logged into the bodhi web interface and clicked on "my > >>> updates". In the list I see a recent package I pushed to testing - > >>> shorewall-4.4.6-2.fc12. When I click on it, it takes me to a screen > >>> for luckybackup-0.3.5-2.fc12. Something seems to have gone awry with > >>> the hash generation or linking or something. I'd file a bug report but > >>> I am not sure where the problem lies exactly. Any pointers? > >>> > >>> Cheers, > >>> Jonathan > >> Both packages have the same Update ID. You can access your update > >> by going to > >> https://admin.fedoraproject.org/updates/shorewall-4.4.6-2.fc12 > > > > It looks like today's push started overlapping IDs... I'm looking into > > it, and will reassign ID's once it is fixed. > > A couple of my updates suffer from the same problem. Is it still under > investigation and should I just wait or should I report the specific > problems? A large number of updates currently suffer from duplicate IDs, and I need to figure out a clever way to fix it. If you want some details as to how this happened... Bodhi's PackageUpdate.assign_id method is insane, mainly to hack around SQLObject shortcomings. This method apparently relied on the PackageUpdate.date_pushed field *not* getting updated when an update goes from testing->stable in order to determine the last ID assigned. I recently made a change that updates this timestamp when a testing update hits stable, and thus broke the id assignment algorithm (sadly, not the test suite (which is up to 101 unit tests, btw)). I'm working on a script to fix all of these duplicates at once, as well as an improved ID assignment algorithm. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi hash collision?
On Fri, Feb 19, 2010 at 11:40:42PM -0500, Tom Lane wrote: > Luke Macken writes: > > A large number of updates currently suffer from duplicate IDs, and I > > need to figure out a clever way to fix it. > > Would it be prudent to not push new updates until you've fixed it? The duplicate update ID issue should be fixed, and the code I wrote to fix it is in bodhi/tools/fix_dupe_ids.py luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi hash collision?
On Sun, Feb 21, 2010 at 09:29:51PM -0500, Jon Masters wrote: > On Sun, 2010-02-21 at 15:36 -0500, Luke Macken wrote: > > On Fri, Feb 19, 2010 at 11:40:42PM -0500, Tom Lane wrote: > > > Luke Macken writes: > > > > A large number of updates currently suffer from duplicate IDs, and I > > > > need to figure out a clever way to fix it. > > > > > > Would it be prudent to not push new updates until you've fixed it? > > > > The duplicate update ID issue should be fixed, and the code I wrote to > > fix it is in bodhi/tools/fix_dupe_ids.py > > OOI, what happened? I described the issue earlier on in this thread, but basically... Bodhi's PackageUpdate.assign_id method is a little crazy, mainly to hack around SQLObject shortcomings (like not storing miliseconds in datetime columns). This method apparently relied on the PackageUpdate.date_pushed field *not* getting updated when an update goes from testing->stable in order to determine the last ID assigned, since we assign update ID's right when updates hit testing (which I am thinking about changing in the next major release). I recently made a subtle change that updates this date_pushed timestamp when a testing update hits stable, and thus broke the id assignment algorithm. Sadly, the test suite did not initially catch this issue, but I have since added a test to reproduce the issue, and have written code to detect these duplicates and re-assign their IDs. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Mon, Mar 08, 2010 at 09:59:29PM +, Matthew Garrett wrote: > This is the policy that I expect to be discussed during the Fesco > meeting tomorrow. This is entirely orthogonal to the ongoing discussions > regarding whether updates in stable releases should be expected to > provide features or purely bugfixes, and I don't see any conflict in > introducing it before those discussions have concluded. > > Introduction > > > We assume the following axioms: > > 1) Updates to stable that result in any reduction of functionality to > the user are unacceptable. > > 2) It is impossible to ensure that functionality will not be reduced > without sufficient testing. > > 3) Sufficient testing of software inherently requires manual > intervention by more than one individual. > > Proposal > > > The ability for maintainers to flag an update directly into the updates > repository will be disabled. Before being added to updates, the package > must receive a net karma of +3 in Bodhi. I don't think this is ideal. I'm having déjà vu from a lot of these discussions & proposals -- we've been here before. When I created bodhi, it initially disallowed pushes directly to stable. This behavior... didn't sit well with The Community, for a variety of reasons. As you can tell by the uproar in every single one of these threads, if these same restriction are put in place again we will lose a lot of important contributors. Instead of re-implementing old controversial behavior, lets look at some recent behavioral changes in bodhi and see if we can build on top of those to solve these problems. For example, I recently implemented various policy restrictions for critical path/no frozen rawhide updates for pending releases. In order for a critical path update to get marked as 'stable' for a pending release, it must have at least +1 karma from releng/qa members, and at least +1 from an authenticated user. These values, of course, are configurable. I think a much better solution would be to require similar critical path policies, across *all* releases, not just pending ones, while still allowing non-critpath packages to go directly to stable. Requiring a static amount of karma across all updates is not going to be sufficient, especially with the current karma system (which I think needs improvement). Especially now with the easy-karma script, people can +1 dozens of updates at a time, reaching +3 will be almost too easy for certain packages, and yet not not easy enough for others. Having configurable karma thresholds for different packages seems to be sufficient, and it allows package maintainers to use their intuition to tweak these thresholds accordingly to fit their workflow and tester base. For example, the kernel maintainers disable karma automation entirely, and one could argue that this flexibility is important. Regarding the current karma system, I think Doug Ledford brought up some good ideas in the earlier thread 'Bodhi karma feature request', and I know other bodhi developers agree. With an improved karma system, stricter critpath update handling, AutoQA integration, and giving The User more fine-grained control over what types of updates they actually want, I think we'll be much better off than we currently are. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Tue, Mar 09, 2010 at 01:48:42PM -0500, Jon Masters wrote: > On Tue, 2010-03-09 at 12:26 -0500, Luke Macken wrote: > > > I think a much better solution would be to require similar critical path > > policies, across *all* releases, not just pending ones, while still > > allowing non-critpath packages to go directly to stable. > > That is an acceptable fallback. But just for the record, I consider the > critical path on my desktop to include not just kernel/udev/modules/etc. > but also GNOME, cups, and other things I use each day. Right, the critical path package list does contain the GNOME stack, cups-libs, etc. http://kojipkgs.fedoraproject.org/mash/rawhide-20100309/logs/critpath.txt luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bodhi error?
On Fri, Mar 19, 2010 at 06:47:44PM +0200, Ville Skyttä wrote: > On Friday 19 March 2010, Jon Ciesla wrote: > > ServerError(https://admin.fedoraproject.org/pkgdb/acls/name/barrage/Fedora/ > > 13, 500, Unknown HTTP Server Response) > > > > This is while creating an update. > > I got that earlier today too, when the "close bugs" checkbox was ticked. I > managed to submit the same update after unticking it. If you try again, it will most likely work. These sporadic errors are probably due to the FAS identity provider/ visit manager that our TurboGears apps use. However, the pkgdb isn't logging tracebacks properly, so we really don't know exactly where it is coming from, though I assume it's pycurl throwing an error while trying to connect to FAS. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Pkgdb update and infrastructure freeze
On Sun, Mar 21, 2010 at 01:54:10PM -0400, Toshio Kuratomi wrote: > Things that are known: > > * maxamillion's firefox search plugin currently doesn't work. We're looking > at changing pkgdb search parameters so that it can work again. > * some non-pkgdb code is broken by the update. These should be ported to > python-fedora or you can ask me for hints on updating the minimum > necessary to get them working for now. > * UI for search is confusing. (for example, entering a package name in the > search box on the front page and hitting enter will do an application > search which likely won't return any matches. Clicking the packages button > should work.) We're trying to figure out a way to remedy that but if you > have ideas feel free to give them to me. This likely won't be fixed > before F-13 releases. > * Currently only showing ix86 and noarch packages to download and install. > This is a problem in the import script. We'll likely hotpatch it when we > figure out the fix for it. > * No way to add tags and comments on binary packages. Not all packages are > Applications (currently just the packages that have a .desktop file). The > pkgdb database knows about tags and comments on binary packages but > there's no way to add these in the WebUI; only to packages that have > Applications. Adding UI for this is likely to be a post-F-13 update. * This pkgdb update completely broke Fedora Community's PkgdbConnector, thus the majory of Fedora Community is now broken. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 12: Make Dell machines boot again
On Tue, Apr 06, 2010 at 01:46:53PM -0700, Adam Williamson wrote: > On Tue, 2010-04-06 at 16:19 -0400, Jarod Wilson wrote: > > > > From what I can tell, it looks like the -90 update got 'auto-pushed' by > > > hitting +3 karma, despite the fact that two people had reported the > > > regression in Bodhi. This is a classic case of 'works for me' positive > > > feedback overriding 'there's a regression!' feedback, which is one of > > > the issues we're trying to fix with the proposals to improve Bodhi. > > > > > > For now, might I suggest disabling auto-push for kernel updates? > > > > Even more fun, the request was initially submitted and told to ignore > > karma for auto-push, but the initial submission had an incorrect bug > > number in it. Went in to fix that, and apparently didn't notice that > > bodhi had helpfully decided to re-enable the auto-push check box when > > all I wanted to do was fix a bug number. (in other words, "edit" > > doesn't properly honor the current settings of the ticket). > > Ah, that definitely sounds like a bug to be fixed in Bodhi, can you > report it to Bodhi trac? Hmm, I thought we fixed that bug already. I just re-opened https://fedorahosted.org/bodhi/ticket/353 luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New bodhi bugfix release in production
bodhi v0.8.3 Yesterday I pushed out a new bugfix release of bodhi into production. The bodhi-client is currently on it's way to updates-testing for all releases. https://admin.fedoraproject.org/updates I raced to get this out before the infrastructure freeze today, and since then there have already been many more bugfixes in git, so expect another release shortly after F16 is released. Please file bugs here: https://fedorahosted.org/bodhi/newticket Client fixes - bodhi -L dies with out-of-range exception after branching f16 https://fedorahosted.org/bodhi/ticket/625 https://bugzilla.redhat.com/show_bug.cgi?id=746780 - bodhi -r dist-f14 -b 676195 don't respect -r option https://bugzilla.redhat.com/show_bug.cgi?id=747939 Server fixes - Default to update ID-based URLs https://fedorahosted.org/bodhi/ticket/632 - fedora-easy-karma submits too many comments to bodhi when bodhi has a server problem (edit) https://bugzilla.redhat.com/show_bug.cgi?id=698441 - Bodhi no longer adds comments to Security Response bugs https://fedorahosted.org/bodhi/ticket/485 Buildroot override fixes - Buildroot overrides require commit access to devel branch rather than branch override applies to https://fedorahosted.org/bodhi/ticket/620 - Cannot request build root override https://bugzilla.redhat.com/show_bug.cgi?id=729722 - buildroot overrides stay after expiration date https://bugzilla.redhat.com/show_bug.cgi?id=723071 Masher fixes - Updates-testing report emails should use package names not update number https://fedorahosted.org/bodhi/ticket/644 - Current updateinfo data is broken (epoch="None") https://bugzilla.redhat.com/show_bug.cgi?id=652296 - Fedora Update System suggests to reboot when not asked to do so https://bugzilla.redhat.com/show_bug.cgi?id=681850 Package fixes - - bodhi-server should require python-fedora-turbogears https://bugzilla.redhat.com/show_bug.cgi?id=743975 pgpcXyy8mbom9.pgp Description: PGP signature ___ 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
Re: New bodhi bugfix release in production
On Tue, Oct 25, 2011 at 02:59:51PM -0700, Adam Williamson wrote: > On Tue, 2011-10-25 at 17:18 -0400, Luke Macken wrote: > > bodhi v0.8.3 > > > > > > Yesterday I pushed out a new bugfix release of bodhi into production. The > > bodhi-client is currently on it's way to updates-testing for all releases. > > > Server fixes > > > > > > - Default to update ID-based URLs > > https://fedorahosted.org/bodhi/ticket/632 > > In case you hadn't noticed, response to this has so far been pretty > negative. It seems people liked being able to tell from the URL what the > update actually *was*. I must admit I do to. I've resorted to creating > the 'old-style' URLs manually when I do lists of updates on test@ or in > trac, now. I'd be happy to revert this if the majority of people prefer the other format. Bodhi will still use the n-v-r style URLs for the updates-testing digests, but will default to the static IDs otherwise. The biggest problem with using the builds in the URL is that the URLs break if they are edited to add/remove/update them. I guess we could add some additional logic to try and be clever and find the update even if one of the builds is missing or modified. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On Wed, Oct 26, 2011 at 03:04:12PM -0700, Garrett Holmstrom wrote: > On Wed, Oct 26, 2011 at 12:07 PM, Kevin Fenzi wrote: > > Or perhaps even: > > > > https://admin.fedoraproject.org/updates/FEDORA--N/package1-1.1.fc16,package2-1.1.fc16 > > > > where anything after the FEDORA--N doesn't matter, but could > > contain all the current packages in the update. > > This sounds reasonable to me. How feasible is teaching bodhi to parse > that sort of URI that way? Very feasible :) https://fedorahosted.org/bodhi/changeset/86ec2fb28d15c2fc76866924a84f1380221948d6 luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On Wed, Oct 26, 2011 at 07:17:10PM -0400, Luke Macken wrote: > On Wed, Oct 26, 2011 at 03:04:12PM -0700, Garrett Holmstrom wrote: > > On Wed, Oct 26, 2011 at 12:07 PM, Kevin Fenzi wrote: > > > Or perhaps even: > > > > > > https://admin.fedoraproject.org/updates/FEDORA--N/package1-1.1.fc16,package2-1.1.fc16 > > > > > > where anything after the FEDORA--N doesn't matter, but could > > > contain all the current packages in the update. > > > > This sounds reasonable to me. How feasible is teaching bodhi to parse > > that sort of URI that way? > > Very feasible :) > > https://fedorahosted.org/bodhi/changeset/86ec2fb28d15c2fc76866924a84f1380221948d6 Of course, I pulled the git-push trigger too early, and the above commit has a couple of issues, which have since been resolved. Kevin Fenzi's suggestion for using /updates// as a default URL structure has been implemented. Since it only looks for the update by the ID the builds can change and it will still take you to the same update. The update IDs are assigned when they are first pushed to testing, so pending updates will still have the same /updates/ URL that they always have. Thanks to everyone who contributed their ideas in this thread! luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bodhi 0.8.4 in production
Hi! A new bugfix release of bodhi has just hit production. https://admin.fedoraproject.org/updates Changes --- - A new URL structure implemented, based on discussions from fedora devel list[0]. Testing & stable updates will now have the following URLs: /updates// Bodhi only cares about the ID of the update, as the builds may be edited over time. This new URL scheme is complementary, and all previous URLs will continue to work. - Fixed an issue with email encoding using TurboMail 3.0[1]. This bug prevented various email notifications from going out properly[2] - Changed the login link so that it can be friendlier if only a missing csrf_token is preventing a use from being deemed logged in. - Allow provenpackagers to submit any buildroot override - Added some new critical path proventester metrics[3] - Less update comment spam when we have to resume failed pushes. - Fixed a bug in the auto-obsoletion code that occurs when a multi-build update contains the same number of builds as a previous update for that package, but with at least one different package.[4] - Fixed a CSS bug that prevented the unit tests from being visible in some browsers[5] [0]: https://lists.fedoraproject.org/pipermail/devel/2011-October/158770.html [1]: https://fedorahosted.org/bodhi/ticket/648 [2]: https://fedorahosted.org/bodhi/ticket/647 [3]: https://fedorahosted.org/fesco/ticket/517#comment:7 [4]: https://fedorahosted.org/bodhi/ticket/617 [5]: https://fedorahosted.org/bodhi/ticket/598 ___ 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
Bodhi critical path updates policy adjustment
FESCo recently made an adjustment to the updates policy to no longer require proventester karma for a critical path update to be deemed as stable. Critical path updates will now require just one regular +1 karma vote during the pre-beta phase and two regular +1 karma votes in other phases to be pushed to the stable updates repo. Anonymous karma is not taken into account. This policy change has been implemented and deployed to production with Bodhi v0.8.6. https://admin.fedoraproject.org/updates Please report any issues in bodhi's trac: http://bodhi.fedorahosted.org Thanks, luke pgpT8uFHtXnb9.pgp Description: PGP signature ___ 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
Re: Issues with bodhi (No JSON object could be decoded)
On Thu, 2010-05-13 at 17:19 -0500, BJ Dierkes wrote:
> Hello all,
>
> Is anyone else experiencing these issues?
>
> $ bodhi -n --type bug mysql-mmm-2.2.1-1.fc12 --username derks
> Creating a new update for mysql-mmm-2.2.1-1.fc12
> ServerError(https://admin.fedoraproject.org/updates/save, 200, Error returned
> from simplejson while processing
> https://admin.fedoraproject.org/updates/save: No JSON object could be decoded)
> Traceback (most recent call last):
> File "/usr/bin/bodhi", line 178, in main
> data = bodhi.save(**extra_args)
> File "/usr/lib/python2.6/site-packages/fedora/client/bodhi.py", line 111,
> in save
> 'bugs': bugs,
> File "/usr/lib/python2.6/site-packages/fedora/client/baseclient.py", line
> 316, in send_request
> req_params = req_params, auth_params = auth_params)
> File "/usr/lib/python2.6/site-packages/fedora/client/proxyclient.py", line
> 313, in send_request
> {'url': url, 'err': str(e)})
> ServerError: ServerError(https://admin.fedoraproject.org/updates/save, 200,
> Error returned from simplejson while processing
> https://admin.fedoraproject.org/updates/save: No JSON object could be decoded)
>
>
> I just did a successful push for EL5, now this. I had these issues 2 days
> ago with el5,fc12,fc13... which was the last time I tried. Am I missing
> something? Seems I'm getting a 200 response, but the update doesn't show up
> in admin updates at all.
>
> Using: bodhi-client-0.7.4-1.fc12
I'm seeing your POST requests in the logs, but some of them are not
hitting bodhi's save() method, which means it's not getting past the
identity layer. Does it work after you `rm ~/.fedora/.fedora_session`?
Also, does passing -v to bodhi show anything useful?
Thanks,
luke
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
bodhi statistics
I recently wrote some code to generate detailed statistics of Fedora & EPEL updates within bodhi. Eventually this will be auto-generated and exposed within bodhi itself, but for now here are the initial metrics. This report definitely conveys the shortcomings in our testing, however, it does show us improving with each release. For Fedora 13, we implemented the No Frozen Rawhide process with improved Critical Path policies, which were definitely a success. With these enhanced procedures, along with the upcoming implementation of AutoQA and the new Package update acceptance criteria (https://fedoraproject.org/wiki/Package_update_acceptance_criteria), I think we'll see these numbers drastically improve in the future. You can find the code that generates these statistics here: https://fedorahosted.org/bodhi/browser/bodhi/tools/metrics.py https://fedorahosted.org/bodhi/browser/bodhi/tools/log_stats.py. If you have any ideas or suggestions for different types of metrics to generate, or if you find any bugs in my code, please let me know. luke = Bodhi Statistics Report (Generated on June 8th, 2010) = Out of 17412 total updates, 2958 received feedback (16.99%) Out of 1045 total unique karma submitters, the top 30 are: * notting (424) * mclasen (366) * jkeating (321) * adamwill (283) * cwickert (161) * rdieter (159) * pbrobinson (141) * kevin (141) * cweyl (122) * tomspur (119) * mtasaka (110) * xake (97) * cschwangler (86) * kwright (84) * peter (83) * hadess (80) * michich (72) * tagoh (69) * pfrields (69) * bpepple (69) * iarnell (68) * lkundrak (66) * shinobi (65) * sundaram (64) * spot (62) * pravins (62) * markmc (62) * thomasj (61) * smooge (60) * fab (59) Fedora 13 * 3562 updates * 3065 stable updates * 427 testing updates * 62 pending updates * 8 obsolete updates * 2371 bugfix updates (66.56%) * 745 enhancement updates (20.92%) * 89 security updates (2.50%) * 357 newpackage updates (10.02%) * 410 critical path updates (11.51%) * 1155 updates received feedback (32.43%) * 12120 +0 comments * 2477 +1 comments * 155 -1 comments * 595 unique authenticated karma submitters * 133 anonymous users gave feedback (1.57%) * 2261 out of 3562 updates went through testing (63.48%) * 1317 testing updates were pushed *without* karma (58.25%) * 21 critical path updates pushed *without* karma * Time spent in testing: * mean = 11 days * median = 9 days * mode = 7 days * 4 updates automatically unpushed due to karma (0.11%) * 0 of which were critical path updates * 231 updates automatically pushed due to karma (6.49%) * 2 of which were critical path updates * Time spent in testing of updates that were pushed by karma: * mean = 11 days * median = 7 days * mode = 7 days * Time spent in testing of updates that were unpushed by karma: * mean = 9 days * median = 5 days * mode = 5 days * 2445 packages updated (top 10 shown) * selinux-policy: 13 * jd: 12 * openoffice.org: 12 * gdb: 12 * ibus-pinyin: 11 * nautilus: 10 * kernel: 10 * evolution: 9 * libfm: 9 * libmx: 9 Fedora 12 * 4844 updates * 4291 stable updates * 371 testing updates * 113 pending updates * 69 obsolete updates * 2905 bugfix updates (59.97%) * 1054 enhancement updates (21.76%) * 201 security updates (4.15%) * 684 newpackage updates (14.12%) * 407 critical path updates (8.40%) * 960 updates received feedback (19.82%) * 16311 +0 comments * 1899 +1 comments * 554 -1 comments * 758 unique authenticated karma submitters * 576 anonymous users gave feedback (5.33%) * 2873 out of 4844 updates went through testing (59.31%) * 2138 testing updates were pushed *without* karma (74.42%) * 188 critical path updates pushed *without* karma * Time spent in testing: * mean = 14 days * median = 13 days * mode = 17 days * 12 updates automatically unpushed due to karma (0.25%) * 4 of which were critical path updates * 133 updates automatically pushed due to karma (2.75%) * 13 of which were critical path updates * Time spent in testing of updates that were pushed by karma: * mean = 11 days * median = 7 days * mode = 7 days * Time spent in testing of updates that were unpushed by karma: * mean = 9 days * median = 5 days * mode = 5 days * 2902 packages updated (top 10 shown) * qbittorrent: 25 * gdb: 25 * selinux-policy: 22 * kernel: 15 * xorg-x11-server: 14 * ibus: 13 * jd: 13 * abrt: 11 * gvfs: 11 * gtk2: 11
Re: bodhi statistics
On Wed, 2010-06-09 at 01:46 +0200, Kevin Kofler wrote: > Luke Macken wrote: > > This report definitely conveys the shortcomings in our testing, however, > > it does show us improving with each release. By 'shortcomings in our testing', I mean, 'shortcomings in the process by which we currently use bodhi for "testing" updates'. > For Fedora 13, we implemented > > the No Frozen Rawhide process with improved Critical Path policies, which > > were definitely a success. With these enhanced procedures, along with the > > upcoming implementation of AutoQA and the new Package update acceptance > > criteria > > (https://fedoraproject.org/wiki/Package_update_acceptance_criteria), I > > think we'll see these numbers drastically improve in the future. > > Only because those numbers are taylored towards that very process (they > measure the exact same things that process is going to enforce) and do not > reflect the actual quality of the packages in any way. > > You can make really anything a "success" by measuring the very symptoms of > the process and calling them a metric of "quality". These metrics do not reflect the actual quality of our updates, the policy or process behind them, or even the quality of testing that they endured before being released. It is simply a measurement of how we have been interacting with this specific piece of infrastructure. By "success" I mean that I felt we were successful in drafting, implementing, deploying, and utilizing the mentioned policies as expected, and the results show increased community engagement. Attempting to quantify the quality of these community interactions is another story. As to whether or not the policies behind the processes have helped or hindered the release quality overall, that has yet to be determined. > The reasons for which Bodhi karma (especially in its current incarnation) is > a completely broken indicator of quality have been pointed out in several > past threads. I'm well aware, and I agree that the current bodhi karma implementation does not convey an effective measurement of update quality. The problem is not a lack of good ideas for improvement, but rather a lack of developers to help improve. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi statistics
On Tue, 2010-06-08 at 16:51 -0400, Luke Macken wrote: > > Fedora 13 > > > * 231 updates automatically pushed due to karma (6.49%) >* 2 of which were critical path updates So I thought that this last metric would take into account critical path updates that were approved under the new policy, but it did not. The actual metric is for Fedora 13 is: * 333 critical path updates approved -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi statistics
On Tue, 2010-06-08 at 21:20 -0400, Matthias Clasen wrote: > On Tue, 2010-06-08 at 16:51 -0400, Luke Macken wrote: > > > > > Fedora 13 > > > > > > * 3562 updates > > * 3065 stable updates > > * 427 testing updates > > * 62 pending updates > > * 8 obsolete updates > > Hey Luke, > > are these the numbers of F13 updates since we branched, or since the F13 > release ? The numbers certainly look like the former, but I think the > latter would be much more interesting. These numbers are since we branched for F13. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi statistics
On Wed, 2010-06-09 at 08:38 +0200, Kevin Kofler wrote: > Luke Macken wrote: > > By "success" I mean that I felt we were successful in drafting, > > implementing, deploying, and utilizing the mentioned policies as > > expected, and the results show increased community engagement. > > This definition of "success" does not match mine nor the one you'll find in > a dictionary. So your terminology is misleading. Really, Kevin? We're digressing to a dictionary battle? Fine, I'll play. First definition in the dictionary[0]: "an event that accomplishes its intended purpose". ...which is exactly what I meant to being with. luke [0]: http://www.google.com/search?q=define%3Asuccess -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi statistics
On Wed, 2010-06-09 at 09:35 +0200, Marcela Mašláňová wrote: > On 06/08/2010 10:51 PM, Luke Macken wrote: > > I recently wrote some code to generate detailed statistics of Fedora& EPEL > > updates within bodhi. Eventually this will be auto-generated and exposed > > within bodhi itself, but for now here are the initial metrics. > > > > This report definitely conveys the shortcomings in our testing, however, it > > does show us improving with each release. For Fedora 13, we implemented the > > No Frozen Rawhide process with improved Critical Path policies, which were > > definitely a success. With these enhanced procedures, along with the > > upcoming implementation of AutoQA and the new Package update acceptance > > criteria > > (https://fedoraproject.org/wiki/Package_update_acceptance_criteria), I > > think we'll see these numbers drastically improve in the future. > > > I can't agree that this update policy is success (in any dictionary). If you can't agree that we, as a community, were successful in accomplishing our intended purpose of implementing the No Frozen Rawhide & Critical Path package processes that we drafted, then you're not understanding the use of the word. Again, the "update policy" that is currently rubber stamped does not match what is enforced by the process. The "package update acceptance criteria"[0] has been "approved", but not yet implemented. So, if you feel like you have suggestions or some sort of constructive criticism to offer, I recommend bringing it up with FESCo. [0]: https://fedoraproject.org/wiki/Package_update_acceptance_criteria > Since I'm forced to wait two weeks for pushing into stable For EPEL updates, yes, that is their policy. For Fedora, there is nothing stopping you from pushing your non-critpath updates straight to stable. > Other thing is that I'm forgetting packages in bodhi, because I believed > until yesterday that updates will be pushed after two weeks > automatically. Not sure whether policy changed or it's a bug [1]. Bodhi has never done this, ever. According to the new acceptance critera, updates will have to "spend some minimum amount of time in updates-testing, currently one week". Now, as to whether or not bodhi should auto-push after that week, that I'm not quite sure. > Karma in bodhi updates doesn't speak about quality of updates at all. At > least my packages which has more dependencies are pushed without > testing, and less important are "tested" even testers don't know what > does it do [2]. For example here were testers happy because it was > updated without any warning message, but they don't know if it's working > or not. Right, karma does not equate quality. I don't think anyone ever claimed that it did? > I'm looking forward to qa project that could really improve quality - > like testing updates, which fixed bugs with bugzilla and testers really > reproduce them before and not after. Otherwise is bodhi good only for > checking update by yum without errors. Yes, I'm looking forward to AutoQA as well. We all are. The majority of karma is "this ran without exploding", which is far from sufficient testing, but it's still valuable information. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi statistics
On Wed, 2010-06-09 at 09:10 +0200, Ralf Corsepius wrote: > On 06/09/2010 08:54 AM, Luke Macken wrote: > > On Wed, 2010-06-09 at 08:38 +0200, Kevin Kofler wrote: > >> Luke Macken wrote: > >>> By "success" I mean that I felt we were successful in drafting, > >>> implementing, deploying, and utilizing the mentioned policies as > >>> expected, and the results show increased community engagement. > >> > >> This definition of "success" does not match mine nor the one you'll find in > >> a dictionary. So your terminology is misleading. > > > > Really, Kevin? We're digressing to a dictionary battle? > > > > Fine, I'll play. First definition in the dictionary[0]: "an event that > > accomplishes its intended purpose". > Exactly. Your definition differs from Kevin's (and mine). Neither of you have mentioned "your" definition of the word "success". Care to enlighten us? > > ...which is exactly what I meant to being with. > > To me, your definition of success is "compliance with *your* process". If by "your process" you mean "the processes created by the Fedora Community". I have had almost no say in the new updates criteria, nor am I on any rubber-stamping committee to approve it. I am, however, one of the *few* developers who actually works on bodhi, and I have a vested interested in improving it for the greater good of the community. Now, if the policies that are being approved do not actually benefit the greater good of the community, we have bigger problems. > Whether this process is suitable to improve package quality, whether the > technical system behind it is a good approach and whether your approach > actually improves package quality or is mere bureaucray is highly > questionable. Yes, all of those are highly questionable, with regard to this "quality" metric. To improve a process we must first observe how it is currently being utilized. What comes out of bodhi is what the maintainers put into it. Aside from that, we've been essentially been using it to "croud-source" QA. As expected, this is far from perfect, but it's a start until we have code in place that can perform rigorous and comprehensive testing. > That said, all you demonstrated is your system not being entirely > broken, but I don't see any "success" related to QA in your statistic. The numbers show an increase in community interaction. More eyes are looking at the updates and providing feedback. Considering we're croud-sourcing QA, an increase in participation is called a success. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution update in F13
On Fri, 2010-06-25 at 22:50 -0700, Adam Williamson wrote: > I talked to notting &c about this earlier, and we've hit this situation > before. The 'scenario' is simply that there's really no screening > between 'submit' and 'push' for stable updates, and this one was > submitted to stable before any negative karma came in. There's no > reliable process whereby whoever's doing the push to stable actually > looks at feedback before doing it; unless they happen to have been made > aware that a particular package shouldn't be pushed, they just push > everything that's been submitted. There actually is a way to get feedback on updates before pushing. Bodhi's admin request list interface gives everything in the list headed to stable a color based on some heuristics. So it's quite easy to scan the list and look at the red updates, which have negative karma, or haven't been in testing long. However, I think all of our bodhi admins who kick off the pushes use the command-line instead. I think that in this case, the command-line bodhi client could be improved to make it obvious that they're about to push an update with negative karma. [...] > The requirement for proventester feedback for critpath updates, when we > turn it on, should also catch problems like this in the critpath. Evo > isn't critpath, though, I believe. evolution-data-server is in the critpath, and having the proventester feedback policy implemented would have definitely caught this issue. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bodhi 0.7.5 release
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 Auto-obsoletion re-enabled -- I re-enabled the auto-obsoletion code in bodhi. This means that new updates will automatically obsolete older testing updates containing the same packages. The new update will also inherit all of the old updates bugs and notes. This code had been disabled for a while now, due to some nasty edge cases, but those have since been resolved. If you experience any problems, please file tickets here: https://fedorahosted.org/bodhi/newticket Thanks, luke [0]: https://fedoraproject.org/wiki/Critical_Path_Packages [1]: https://fedoraproject.org/wiki/QA/JoinProvenTesters ___ 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
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=F13&untested=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
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
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 07/01/2010 03:38 PM, Kevin Fenzi wrote: > On Wed, 30 Jun 2010 18:38:03 -0400 > Tom Lane 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: measuring success
On 07/03/2010 06:50 AM, Till Maas wrote: > Also Bodhi does not allow to fix updates by other people than the update > submitter afaik. Anyone with commit privs to the rawhide branch of a package should be able to submit/edit updates for that package. Yes, it's not ideal, but that is how it is currently implemented. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: depcheck test (was Re: measuring success)
On 07/06/2010 04:09 PM, Till Maas wrote: > On Tue, Jul 06, 2010 at 03:06:37PM -0400, Will Woods wrote: >> On Tue, 2010-07-06 at 19:21 +0200, Till Maas wrote: >>> On Tue, Jul 06, 2010 at 09:40:01AM -0700, Jesse Keating wrote: On 7/6/10 8:52 AM, Till Maas wrote: > IMHO it should not be a +1 karma but some different flag that is set for > updates that passed the tests. Using karma is viewed as the path of least resistance to getting support in current bodhi for this. For future bodhi yes, it makes some sense to use some different flagging mechanism. >>> >>> Essentially using a different flag is just re-using the code used to >>> flag a package as critpath-approved only with a different name. >>> Therefore it should not need that much more effort. >> >> Feel free to help write the code to prove this point! >> >>> Btw. using the "path of least resistance" to implement policy >>> changes seems to be what makes the new workflows suck for package >>> maintainers, e.g. with the change in place using a auto-karma value of 1 >>> will become 0. >> >> Well that's only one *proposed* idea. We could just as easily have >> autoqa give a comment with neutral (0) karma on updates which pass, and >> -1 on failed updates, which would serve all the same purposes. That >> might be a better idea, actually. > > Using karma 0 the patch could be this one: > http://till.fedorapeople.org/tmp/0001-support-passed_autoqa.patch This patch looks good at a first glance -- it's pretty much exactly what I was planning to do. The only tweak that is needed is to ensure that anonymous people can't pretend to be AutoQA: -if comment.author == "autoqa": +if not comment.anonymous and comment.author == "autoqa": This patch, along with my critpath/nofrozenrawhide/epel changes, avoid making database schema changes to bodhi. This makes it very easy to perform upgrades. For the TurboGears2 port of bodhi that is underway, these flags should definitely be proper columns in the db model. Another benefit of the TG2 port is we will be able to utilize the SQLAlchemy migration tools, which will allow us to change the schema as we need to, instead of hacking together these "path of least resistance" changes. Thank you for all of your help with Bodhi, Till. Your work is much appreciated. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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 Maas 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: depcheck test (was Re: measuring success)
On 07/13/2010 04:59 PM, Till Maas wrote: > On Tue, Jul 13, 2010 at 03:55:46PM -0400, Luke Macken wrote: >> This patch looks good at a first glance -- it's pretty much exactly what >> I was planning to do. The only tweak that is needed is to ensure that >> anonymous people can't pretend to be AutoQA: >> >> -if comment.author == "autoqa": >> +if not comment.anonymous and comment.author == "autoqa": > > Yes, I thought about this later, too and forgot it again. But now I also > remembered a second issue. If autoqa uses -1 comments to indicate that > an update is not approved (anymore), then it must use +1 comments to > indicate that they are approved (again) to not influence the karma. Yep, good call. >> This patch, along with my critpath/nofrozenrawhide/epel changes, avoid >> making database schema changes to bodhi. This makes it very easy to >> perform upgrades. For the TurboGears2 port of bodhi that is underway, >> these flags should definitely be proper columns in the db model. >> Another benefit of the TG2 port is we will be able to utilize the >> SQLAlchemy migration tools, which will allow us to change the schema as >> we need to, instead of hacking together these "path of least resistance" >> changes. > > How long do think it will take till the TG2 port is ready? In the git > tg2 branch there has not been any activity since February. If it is a > very long term project, it might still be useful to keep the old bodhi > code cleaner for easier maintenance. I'd like to have it in beta testing phase by F14, but we'll see how that goes. The current tg2 branch has the entire model ported to SQLAlchemy, with a variety of improvements, and a lot of the test suite is ported over as well. The next step is to port the controllers & templates. I've been holding off on doing this for little while, as I have been doing a lot of bugfixing in the current branch, and I want to avoid having two out-of-sync code bases. However, we're pretty much at the point where I'm about ready to freeze the current branch and start porting the controllers over in the very near future. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
- "Till Maas" wrote: > On Thu, Aug 05, 2010 at 02:55:05PM -0400, David Malcolm wrote: > > > workflow, or merely an RFE I need to file against Bodhi? > > The RFE is already there: > https://fedorahosted.org/bodhi/ticket/343 Implemented. It'll hit production shortly. luke -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
