19:00:16 <lmacken> #startmeeting Bodhi 2.0 Planning (2012-07-19)
19:00:16 <zodbot> Meeting started Thu Jul 19 19:00:16 2012 UTC.  The chair is lmacken. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:20 <lmacken> #meetingname bodhi
19:00:20 <zodbot> The meeting name has been set to 'bodhi'
19:00:25 <lmacken> #topic Who's around?
19:00:34 <lmacken> nirik, dgilmore, sgallagh, adamw, tflink: ping
19:00:44 <lmacken> others?
19:00:47 <sgallagh> pong
19:00:47 <nirik> hey.
19:00:49 <adamw> yo, thanks for the ping
19:01:13 <lmacken> cool. I don't expect many more
19:01:46 <lmacken> I've only got a few things on the agenda for this meeting. So, feel free to jump in with anything that is on your mind.
19:01:53 * threebean shows up
19:01:55 <lmacken> My goal is just to sync up and make sure we're all on the same page going forward.
19:01:56 <adamw> lmacken: just posted some references in #fedora-qa
19:02:07 <lmacken> adamw: cool. I'll link to that in a few
19:02:31 <lmacken> #topic bodhi "2.0" (the pyramid branch) status
19:02:41 <lmacken> So bodhi2 development has been coming along, and will be picking up much more steam during this release cycle.
19:02:52 <lmacken> Anyway, the status page on the wiki is mostly up-to-date, so I won't go over each item in detail.
19:02:55 <lmacken> #link https://fedoraproject.org/wiki/Bodhi/2.0
19:03:02 * pingou lurks around
19:03:11 <lmacken> I feel that the current core is extremely solid and the code is already much cleaner and way more maintainable than bodhi1.
19:03:28 <lmacken> I recently finished porting bodhi's save() method (the core of bodhi's webapp), which was a giant method-of-doom in bodhi1. Now in bodhi2, each sanity check is a proper "validator", and the actual save method is just a few lines of code.
19:03:45 <lmacken> But now I feel like I'm at a good point in the porting process to take a step back and prioritize the various feature requests that have been thrown around over the past few years, before I dive back in to the code.
19:03:58 <lmacken> Which is why I wanted to to talk with you guys about the most important features in your minds, so I can prioritize and focus my cycles going forward.
19:03:59 <nirik> so, database changes, so once we move to trying 2.0, we can't easily go back to using 1.0 if we hit something, right?
19:04:20 <lmacken> nirik: correct. completely different database schema.
19:04:27 <lmacken> SQLAlchemy vs. SQLObject.
19:04:40 <nirik> yeah, so when we deploy we need a flag day I guess?
19:04:40 <lmacken> I already wrote a tool that migrates the bodhi1 database over to bodhi2, which works great
19:04:48 <lmacken> yeah, I think so.
19:05:13 <nirik> ok, just making sure.
19:05:21 <lmacken> #info bodhi2.0 database schema very different from bodhi1.0. There will be no turning back.
19:05:36 <lmacken> #topic New testing feedback system
19:05:42 <lmacken> #link https://lists.fedoraproject.org/pipermail/devel/2011-November/159874.html
19:05:55 <lmacken> adamw described a fairly comprehensive testing feedback schema that I think would be a great improvement to our current karma system.
19:06:16 <lmacken> I think it will be fairly easy to implement, but it'll require changing the updates policy to account for the new types of feedback.
19:07:00 <adamw> yep, it would require that.
19:07:18 <adamw> fesco has never had a problem with changing the updates policy when it made sense, so that shouldn't be a big problem.
19:07:30 <lmacken> yeah, I don't think it will be an issue.
19:07:31 <adamw> do we need to figure a way to combine the processes of bodhi 2.0 design and updates policy revision?
19:08:03 <lmacken> yeah, I think they'll have to stay in sync one way or another
19:08:10 <nirik> yeah, I think fesco will be fine with changing it, but we might want to look at whipping up a Updates-policy-2.0 page with the outline
19:08:42 <lmacken> #action Create an Updates-policy-2.0 page with an outline of new proposed changes
19:09:50 <lmacken> more relevant conversations around this stuff
19:09:53 <adamw> i think that'll assign the action 'an Updates-policy-2.0 page...' to the person 'Create'
19:09:54 <lmacken> #link https://lists.fedoraproject.org/pipermail/devel/2010-March/134087.html
19:09:56 <adamw> just fyi =)
19:10:03 <lmacken> #link https://lists.fedoraproject.org/pipermail/test/2012-June/108700.html
19:10:12 <lmacken> oops :)
19:10:19 <lmacken> this is my first time playing with zodbot & meetings
19:10:23 <adamw> it's no biggie
19:10:53 <lmacken> word. so I think we're all on the same page with regard to this testing feedback mechanism, right?
19:10:53 <nirik> (also, #link isn't needed, it automagically sees links)
19:11:04 <lmacken> it's just a matter of implementing it, and drafting the policy changes
19:11:09 <lmacken> nirik: cool, thanks
19:11:13 <nirik> I'm happy with the described setup as a first cut. ;)
19:11:34 <lmacken> cool. I see that as one of the highest priority features going forward, so it'll be on my plate to implement ASAP.
19:11:55 <lmacken> #action lmacken Will implement proposed testing feedback system
19:12:04 <lmacken> #topic New testing dashboard
19:12:10 <lmacken> A few FUDCons ago, mizmo and I sat down and came up with a new frontpage for bodhi.
19:12:13 <lmacken> http://lewk.org/img/bodhi-20-frontpage.png
19:12:27 <lmacken> I'm still a fan of this design, and I think it'll help revive our tester community. Any comments/suggestions on this?
19:12:47 <threebean> lmacken: first time I've seen it.  looks amazing
19:12:48 <sgallagh> lmacken: This may not be achievable, but
19:12:56 * adamw looks
19:13:09 <sgallagh> lmacken: I don't suppose we could offer a Firefox plugin to restrict the view to packages that the user has installed?
19:13:19 <sgallagh> Then they could easily see what might be heading their way
19:13:28 <lmacken> sgallagh: kinda like fedora-easy-karma for the web?
19:13:39 <sgallagh> Sort of a little ahead of that
19:13:50 <sgallagh> Show them what packages the already run that are available for testing
19:13:54 <adamw> yeah, I like that design. it doesn't lose anything important from the current one, and adds some good things. i don't think the metrics need to be on the front page, and the 'latest comments' in practice have rarely turned out to be much use
19:13:56 <lmacken> does smolt track installed packages?
19:13:58 <sgallagh> Gives people a quick look at what they want to review
19:14:15 <adamw> lmacken: iirc no
19:14:16 <lmacken> adamw: yup.
19:14:18 <adamw> because of the design of smolt
19:14:19 <lmacken> ah
19:14:32 <adamw> it's set up to run at firstboot and then never, automatically, again
19:14:42 <nirik> it runs monthly
19:14:42 <lmacken> sgallagh: I think that's a cool idea, but I have no idea if it's technically feasible. I've never done any firefox plugin work.
19:14:47 <adamw> nirik: ah, imbw then
19:14:49 <nirik> but it doesn't collect installed packages.
19:14:55 <nirik> census might.
19:15:14 * nirik notes not everyone runs firefox. :)
19:15:17 <adamw> i remember a discussion where it was said that it doesn't collect or report installed packages because it's usually run at firstboot, when that information is likely to be inaccurate (user won't have installed the stuff they use yet)
19:15:29 <sgallagh> lmacken: Well, from Bodhi's perspective, maybe doing something as simple as maintaining an optional hidden parameter which is a list of packages to consider for display
19:15:52 <sgallagh> Then we can use Greasemonkey or grow our own extension to submit that when GETting from the Bodhi 2.0 homepage
19:16:00 <lmacken> sgallagh: like the ability to create a personalized testing dashboard for stuff you care about only?
19:16:12 <adamw> lmacken: so, neither you nor mizmo had any more mockups/whiteboards for design? You're really starting with a clean slate plus my ideas?
19:16:41 <misc> sgallagh: having the list of package people care about would also permit to know what package are well covered by testers and whose are not
19:16:42 <lmacken> well, since this'll all be hooked into the new fedmsg system, we could potentially have client-side tools that listen to all updates for all of your installed packages and notifies you in realtime of changes, etc
19:16:58 <lmacken> adamw: as far as UI design, that's about it.
19:17:07 <adamw> ok
19:17:37 <lmacken> adamw: the biggest push for bodhi2 was around the backend, which is limiting the frontend currently
19:17:41 <adamw> right
19:17:52 <adamw> so, i guess the other thing we should look at is the design of the backend
19:18:04 <sgallagh> lmacken: Yes, a personalized testing dashboard would be perfect (and the ideal would be for it to be autodetected based on installed packages)
19:18:07 * nirik has questions about the rel-eng side of things if we get to that later.
19:18:11 <sgallagh> But certainly one step at a time never hurts
19:18:25 <lmacken> #idea Personalized testing dashboard, letting users see only the packages they care about
19:18:35 <lmacken> nirik: yup, in a few
19:18:41 <adamw> i guess if you look at my ideas they're based around the concept of multiple types of feedback per update, with a very 'generic' model - a bit of feedback can be open-ended text entry, numeric value, yes/no question, quite a few things
19:18:42 <lmacken> we're working our way down the stack :)
19:18:58 <nirik> it seems like it shouldn't be too hard for a user to upload a package list for it. but of course thats more per user data to store.
19:19:24 <nirik> adamw: right, and the maintainer looks at all those to determine when something is 'stableable'
19:19:27 <lmacken> adamw: yeah, it'll have to be very flexible in it's implementation, allowing us to tweak it on the fly
19:19:28 <adamw> is that how bodhi2 really works on the back end? or am i working from bad assumptions?
19:19:44 <adamw> lmacken: right, that's the key thing, we really need to have a design that lets us adjust it based on experience
19:20:23 <lmacken> adamw: right now the database simply has an integer column in the db for karma. The new system will have to be much more robust :)
19:20:40 <adamw> yep.
19:20:47 <lmacken> but yeah, the goal is to make it so we can change things on the fly. not just with testing feedback, but also with policy.
19:21:13 <adamw> we definitely need to get away from the concept of a single karma score, that just doesn't really work.
19:21:23 <lmacken> so, before I start implementing the new feedback mechanism, I am going to try and tackle the New Update Form Widget.
19:21:27 <lmacken> #topic Creating new updates
19:21:33 <nirik> so, with all the various checkboxes and things people could add to note about an update... how does this affect fedora-easy-karma? I guess it would need a rewrite or a gui version to handle things
19:21:59 <lmacken> nirik: probably just some tweaks to it's menus to make it more obvious
19:22:18 <lmacken> i don't think it'll be too hard to bring f-e-k up to speed. but yeah, I would like to see a GUI tool for it, hooked into fedmsg, at some point.
19:22:49 <nirik> ok
19:22:53 * lmacken paste dumps
19:22:57 <lmacken> So one of the main areas that I want to revamp in bodhi2 is the new update creation widget.
19:23:00 <lmacken> I don't have any mockups for my vision at the moment, but what I would like to see happen is:
19:23:08 <lmacken> - developer interacts with a slick widget that autocompletes the package names (I'm thinking http://ivaynberg.github.com/select2). No need to punch in full n-v-r builds, only package names.
19:23:12 <lmacken> - for multi-package updates, the developer can choose to save the "Update Group" for future use.
19:23:15 <lmacken> - The next time around, the maintainer just says "I want to create a new update for this group for these releases", and bodhi automatically determines the proper candidate builds and creates the update(s) accordingly.
19:23:35 <lmacken> does that seem sane?
19:24:10 <nirik> seems fine. I mostly use the command line tool here... 'fedpkg update'
19:24:13 <lmacken> any other ideas for the new update creation form? obviously a lot of people will still use the command-line method, which will be much harder to bring up to this level.
19:24:56 <lmacken> The goal of this is to improve how we handle Mega Updates
19:25:36 <lmacken> sgallagh filed a ticket recently requesting that bodhi allow updates to be dependent on other updates
19:25:39 <lmacken> https://fedorahosted.org/bodhi/ticket/663
19:25:40 <nirik> yeah, I think folks who do those will like improvements.
19:25:47 <sgallagh> I recall ;-)
19:25:56 <lmacken> I'm not sure how exactly we want to implement this, but I do agree it needs to happen
19:26:09 <lmacken> Bodhi needs to somehow ensure that all dependencies of all packages in a given update are met before pushing to testing/stable.
19:26:18 <lmacken> I've seen talk of having AutoQA handle this step, we could also potentially query the Fedora Packages webapp for dependency information, or we could have bodhi do it all.
19:26:30 <sgallagh> Yes, and the current solution of "put them all in one update" has definite limitations
19:26:32 <nirik> so, instead of putting all of them in one update, can you just make them all and 'mark' them as dependent?
19:26:50 <lmacken> nirik: so 1 update per build, you're saying?
19:26:55 <nirik> but yeah, it gets complex
19:26:55 <nirik> yeah.
19:27:02 <lmacken> that could work.
19:27:07 <adamw> lmacken: not a direct suggestion, but i'd say 'go ask the gnome team'
19:27:12 <adamw> they're the ones who deal with megaupdates all the time
19:27:27 <lmacken> adamw: yeah, fair enough. I'll definitely ping mclasen & hughsie about that.
19:27:36 <nirik> so foo bar and baz are all built. You add them each as updates, then you mark foo as requiring baz and baz needing bar... then if bar gets unpushed the others cannot/don't push out.
19:27:37 <adamw> there's also the question of whether we're going to make the various forms of feedback selectable by the update submitter, and if so how
19:27:57 <adamw> do we want to let them set up their own question/answer feedback element, say, if they want to?
19:28:42 <adamw> or are we going to go more down the route of, say, 'auto-generating' feedback elements - if the update submitter says 'this update fixes bugs #1, #2 and #3' we automatically put in feedback elements for 'does this update fix bug #1, bug #2, bug #3'?
19:28:45 <lmacken> nirik: that would work, but then we're relying on humans to create the relationship, when the relationship is really at the RPM level and should be determined by code :\
19:28:52 <sgallagh> adamw: I deal with FreeIPA updates all the time too. Hence this ticket :)
19:29:01 <nirik> lmacken: true
19:29:13 <nirik> also, rdieter does kde megaupdates all the time too
19:29:39 <sgallagh> There's another problem with the GNOME and KDE updates, though
19:29:40 <nirik> adamw: yeah, if we use bugs like that we could do that instead of totally free form, then if you had a specific thing to test you could make a bug on it and add it to update ?
19:30:00 <sgallagh> Splitting them into completely separate packages might block the full set from getting pushed in reasonable time
19:30:16 <nirik> sure, if a dependent package failed... but don't you want that?
19:30:18 <adamw> sgallagh: ah =)
19:30:20 <sgallagh> Because a lot of people test gnome-shell, but most people wouldn't think about gtk3 offhand
19:30:34 <sgallagh> nirik: Not about failure, about lack of testing.
19:30:40 <nirik> yeah, agreed.
19:30:55 <sgallagh> Failure blocking is expected and desired
19:31:38 <lmacken> so wrt update groups, do we still want to have the current behavior of 1 update per release? or do we want to have a single update that covers multiple packages across multiple releases?
19:31:43 <sgallagh> So I think we probably also want UI highlighting the dependencies of a particular package and encouraging testers to also test those
19:32:39 <nirik> lmacken: I think per release still makes sense...
19:33:01 <sgallagh> I agree
19:33:26 <lmacken> ok cool. and jwb hit an issue the other day with karma thresholds... he wanted older fedora releases to have a larger stable_karma threshold, and newer ones to have less. Right now bodhi1 doesn't support that, but I'm going to make sure 2.0 does.
19:33:28 <sgallagh> Just because the upstream bits might look the same on F16 and F17 doesn't mean that some other piece of the system is going to break it
19:34:02 <lmacken> that way we can enforce more testing for older releases
19:34:09 <lmacken> if the maintainer wants, of course
19:34:41 <sgallagh> backtracking a bit, one of the problems with the "This update fixes bug A,B,C" is the GNOME team's process.
19:35:03 <sgallagh> Most of the time, they clone the bug to their upstream and just mark the Fedora report CLOSED UPSTREAM
19:35:19 <sgallagh> (Though, maybe having this interface will finally convince them to stop being mean like that)
19:35:43 <lmacken> I also recall someone requesting that bodhi be able to handle linking to external bug trackers...
19:35:59 * lmacken not sure about that though
19:36:08 <sgallagh> That's an interesting idea.
19:36:22 <adamw> lmacken: there's a problem with that proposal in practice (more karma for older releases)
19:36:22 <sgallagh> Maybe make the bug system pluggable and only implement Fedora's BZ as the default plugin?
19:36:28 <adamw> it makes perfect sense in theory; in practice it would be a horrible failure
19:36:38 <adamw> in practice we get far more testing of the _current_ release than we do of older ones
19:36:40 <lmacken> adamw: due to less testers?
19:36:41 <adamw> yeah
19:36:51 <nirik> yep.
19:36:55 <lmacken> yeah, that's a valid concern...
19:37:01 <adamw> of course, things may change with the completely different bodhi 2.0 feedback system, but based on current experience, it just wouldn't work
19:37:19 <lmacken> well, I think it's important for the kernel guys, for instance, to be able to enforce that kind of policy on their own updates.
19:37:19 <sgallagh> It sounds like we're trying to imply that Fedora N-1 should be treated like EPEL. I don't think that will work.
19:37:27 <nirik> I doubt they will... most people using fedora like being on the leading edge, so the N-1 isn't very appealing...
19:37:37 <sgallagh> lmacken: There's nothing stopping them from setting the karma above the required minimum.
19:37:49 <lmacken> sgallagh: well, yes there is a problem...
19:37:58 <sgallagh> Which is?
19:38:07 <lmacken> sgallagh: the issue is bodhi has a single field for the stable/unstable karma thresholds, at the *package* level.
19:38:16 <lmacken> so if one update changes it, it changes it for all updates of that package
19:38:43 <lmacken> basically a problem with the implementation of the thresholds. In 2.0, they will be update specific.
19:38:59 <sgallagh> That's the way it is right now?
19:39:02 <lmacken> yeah
19:39:08 <sgallagh> That doesn't sound right to me.
19:39:23 <nirik> it's not nice, no. ;)
19:39:25 <sgallagh> But I'll trust you
19:39:37 <sgallagh> No, I didn't think I'd seen that happening. But maybe I just ignored it
19:39:43 <adamw> i think sgallagh / lmacken are talking about different things?
19:39:47 <lmacken> we may be
19:39:50 <adamw> the 'push allowed' threshold vs. the 'autopush' threshold
19:40:08 <lmacken> right, I'm talking about autopushing via stable_karma thresholds.
19:40:14 <adamw> in practice, if you want your update to be really safe, you can just set the autopush threshold really high or disable it entirely, and then just _not push_ until you're happy. being able to pushdoesn't mean you _have_ to.
19:40:17 <sgallagh> ah, I was talking about autopushing
19:40:47 <sgallagh> Right, but I didn't think setting autopush at karma 3 meant that all updates of my package would do so.
19:40:48 <lmacken> adamw: yeah, or autokarma can be disabled completely right now.
19:40:55 * sgallagh shrugs
19:41:05 <lmacken> sgallagh: yeah :\
19:41:27 <lmacken> anyway... anything else from a QA perspective?
19:41:35 <lmacken> before we get into relengery
19:41:37 <nirik> in 2.0, how will that work... as a maintainer can I say:
19:42:09 <nirik> if test case passes x 2 > stable and/or if bug X is fixed x 3 > stable
19:42:28 <lmacken> hmm, good question.
19:42:57 <lmacken> we'll want those thresholds to be configurable by the maintainer, as well as mandatory requirements for critpath updates in the policy, right?
19:43:03 <adamw> lmacken: i think the main thing is to make sure the backend is as flexible as possible and keep the design i proposed more or less in mind, together with mo's awesome mockup
19:43:11 <nirik> if critpath fails -> don't allow push
19:43:16 <lmacken> adamw: yup, that's the goal.
19:43:17 <adamw> as long as there's lots of flexibility in the design we can tweak the implementation based on experience
19:43:21 <nirik> yeah.
19:43:58 <nirik> so perhaps a karma module for each type of thing... and we can add new modules or tweak existing ones...
19:44:11 <nirik> or whatever makes sense code wise there
19:44:16 <lmacken> yeah
19:44:34 <lmacken> maybe a database table of feedback types, and an interface for tweaking them
19:44:51 <lmacken> either way... we'll be able to tweak them on the fly
19:45:14 <lmacken> #topic The Masher
19:45:23 <lmacken> So I have yet to try and port any of The Masher, but I suspect it's going to be a fairly big endeavour.
19:45:30 <lmacken> My main goals for it:
19:45:31 <lmacken> - decouple it from the webapp. make it a stand-alone daemon (as opposed to running in apache).
19:45:34 <lmacken> - prioritized pushes. make security updates go faster.
19:45:36 <lmacken> - do more things in parallel.
19:45:56 <lmacken> anything else? from a releng perspective?
19:46:19 <nirik> yeah, parallel is good.
19:46:40 <lmacken> yeah, there is a lot of low-hanging fruit from an optimization perspective here.
19:46:41 <nirik> can we mash all the things we are pushing in parallel?
19:46:49 <lmacken> I believe so.
19:47:02 <nirik> ie, pushing f16/f17, fire off 4 mashes at once instead of doing them one at a time.
19:47:19 <lmacken> yup. and we can generate the updateinfo.xml while that is happening, etc.
19:48:02 <nirik> also, being able to do a branched push while stable branches are pushing would be nice.
19:48:21 <lmacken> ah, yeah.
19:48:29 <nirik> ie, pushing 16/17, then doing a f18 branched one that doesn't wait on those. or interfere with them
19:48:30 <lmacken> well, a branched push is just tagging, right?
19:48:46 <lmacken> yeah, it should allow for that to happen
19:48:53 <nirik> yeah. but currently you can't do it because it locks Fedora*
19:49:13 <lmacken> yup. right now the mashing lock mechanism is really dumb. but that'll be taken care of.
19:49:29 <lmacken> cool.
19:49:33 <nirik> currently there's some race conditions too.
19:49:38 <nirik> would 2.0 help/fix those?
19:49:44 <lmacken> yup, that's a huge issue that we're still hitting
19:49:51 <nirik> ie, a push is in progress and something gets karma or requests to stable when it was pushing to testing.
19:50:03 <lmacken> yeah, there are a couple of different approaches we can take to fixing those.
19:50:22 <lmacken> one being to 'lock' the update while it is being pushed, to prevent state changes, etc.
19:50:37 <nirik> perhaps queue them?
19:50:39 <lmacken> I think I should be able to iron all of those races out
19:50:46 <lmacken> yeah, that's another approach
19:50:57 <nirik> ie, 'there's a push happening now, but this will take effect after it's over'
19:51:54 * nirik doesn't care which ,they are just a pain to deal with. ;)
19:51:56 <lmacken> yeah. I think a lot of it is just dumb code, and also the masher being an out-of-band thing that doesn't really reflect the state of things in the webapp until it's over
19:52:14 <lmacken> but yeah, that's a priority item, for sure.
19:52:36 <lmacken> anyway, that's all I had on the agenda for this meeting.
19:52:42 <lmacken> #topic Anything else?
19:53:01 <nirik> I hate to ask... but...
19:53:11 <nirik> is there any kind of eta when we might like to land 2.0? ;)
19:53:22 <nirik> are we looking at post f18? or ?
19:53:57 <lmacken> heh, I hate giving ETAs, but I usually say "$NEXTRELEASE+1" :)
19:54:12 <lmacken> I think we're looking at post f18, but I will try and have something we can poke at in staging by f18
19:54:52 <nirik> ok, planning on landing it after f18 might be nice, then we have a goal, and it's often quiet after a release (well after the bugfixes right after release)
19:55:14 <lmacken> sounds good to me. it'll be my highest priority until then.
19:55:20 <lmacken> (until spot tasks me with something else ;)
19:56:15 <nirik> yeah, would love to finally get it out. ;)
19:56:25 <nirik> oh, question:
19:56:36 <nirik> do we want to meet again next week? or just as there's things to report? or ?
19:57:03 <lmacken> I think next week is too soon... i'd like to meet again once I've got this new feedback system in place at least
19:58:29 <nirik> ok, sounds good.
19:59:05 <lmacken> alright, well thank you guys for coming! this has been fairly productive, and has definitely helped me prioritize on where my cycles need to go.
19:59:33 <lmacken> we'll touch base again once I have some of these features implemented.
19:59:40 <lmacken> #endmeeting