Fedora Community/Research/PackageMaintainerProcesses

= Notes =

Package List Per Package Columns

 * package name
 * NVRE
 * last build (date or age)
 * last update (version / date?)
 * dl latest binaries
 * cvs link
 * overall status?

= Package Details =


 * dependencies
 * cvs checkout command
 * repoview link to sources
 * koji widget
 * latest rpms
 * step in process broken in
 * log files
 * upstream

= Package Build Lifecycle =


 * 1) bug report opened.
 * 2) changes checked into cvs
 * 3) changes tagged in cvs
 * 4) tag built in koji
 * 5) build pushed in bodhi
 * 6) build pushed to stable in bodhi
 * 7) End of lifecycle

= Issues to solve = mizmo: Yes. And ideally, prepopulates some of the bodhi fields too.
 * no way to associate build with bugzilla until you enter it into bodhi
 * So I'd be using this to check that I don't have builds that I forgot to push in bodhi (fill out bodhi form) - any way we can indicate to people that they have unpushed updates sitting in bodhi is good. We still have too many folks who push to testing and think they're done. tibbs, so if theres a list of your recent successful builds in koji, if they haven't been pushed to bodhi yet, there should be a button next to them saying 'create bodhi update now' or something where it takes them to the correct bodhi form mizmo: that would be ideal
 * I'd also like to find builds that I forgot to promote from testing to stable. tibbs, if they have been pushed to bodhi but not beyond testing-updates, then there should be another button maybe 'push to final release' or something?
 * currently I haven't had any of my packages reach the karma threshold before I've decided to push it to stable - it may be difficult to add karma so maybe my fedora will make it easier
 * Actually, I wonder if I can bribe anyone to consider putting "random package review ticket" or "most recent new package review tickets" somewhere.
 * Now, being able to click somewhere on a list of my recent koji builds and be taken to a page for generating an update might be useful.
 * with adequate community feedback (karma), updates can automatically hit stable.. but right now there is no automatic timeout in which an update will go from testing->stable
 * It would be awesomely cool if I could have a list of open bugs against a package when creating a bodhi update. bodhi can take care of closing bugs out when the update actually gets pushed to stable.

= Process Notes =


 * push to bodhi = package in testing
 * push to stable = package in stable repos

mizmo: so, successful builds in koji (for released branches) get tagged as being an 'update candidate'. To get it into bodhi from there, you can use the web form, type 'make update' in the branch, or use the bodhi command-line tool to get it in there... by default it will get pushed to updates-testing lmacken, so without any user input it gets pushed to updates-testing from koji if it was successfully built? mizmo: nope... user input is required to get it into bodhi but once it is in bodhi, it defaults to pushing right to updates-testing so when i do make update or bodhi command line or the bodhi webui, im filling out details like what bug # it fixed and what type of update it is (bug, enhancement, security, etc) mizmo: exactly

mizmo: Screenshot of the bodhi new update form: v http://toshio.fedorapeople.org/bodhi.png

http://fpaste.org/paste/4448 -- this is what the `make update` template will look like in the near future

I guess to be useful it would have to show more than the bug number, but yeah. Also, it needs to take more than one bug.

To be honest, I think bugs are more important than FAS stauts

http://bugz.fedoraproject.org/yum kernel is bigger :-) but maybe it doesnt make sense to show new, only assigned maybe? maybe a checkbox widget would be more scalable It'd be cool if new vs. assigned were configurable, or could be changed with a click :-)

Full Log (package lifecycle)
hiii i have more questions for package maintainers if any of u have got some time? Hey! oh do u want to see my mockup from yesterdy first? check it https://fedoraproject.org/w/uploads/0/0a/Myfedora-overview-mock1.png  (at fedoraproject.org) What's the inquiry? Any plan to interface with bugzilla there as well? ivazquez, so im wondering, if you're looking at a set of packages that you own jeremy, think I should try a newer boot image? Or should I just hold off for a while? ivazquez, sort of at a glance ivazquez, what kinds of information about each are you looking for? I'm not seeing any good way around this... tibbs, yep i think so ivazquez, eg, what i was thinking was maybe Deps, both up and down.  BZ new request page too slow :-/ package name |  current release/version |  last build (date or age)  |  last update (version / date?) ivazquez, what does having the deps there tell u? I suppose they don't need to be on *that* page. ivazquez, like, if it's a list of 20 packages you maintain say, would it be useful to have a show/hide widget to show the deps? for each row/package? Nah, they can be on the details page. ivazquez, would it be useful to have a dl link for the latest srpm in the list per row? How about bugs filed against each package? Also in details? ivazquez, or maybe an overall status icon? like if it has an alert attached to it, like u need to push an update or your latest build failed, it has a red mark but if it's all good a green one? The only *really* important at-a-glance stuff is name, EVRA, and distro. More useful to have the latest binary rpms, I think. mizmo: +1 for a link to the logs/results on the koji widget Anything other than that is likely to be developer-specific. Maybe a link to repoview for the sources. Or the cvs checkout command foolish, maybe number of bugs in the listview, more details in the per-package details screen? Not sure if results (srpms/rpms) are as important, but the logs are handy ivazquez, what do u mean by distro? Ask 5 devs and you'll get 10 opinions of what should be there. F8, F9, EPEL4, etc. abadger1999, how would u use the latest binary rpms? would it be something you might commonly want to do, log in here to grab them, as a maintainer? ivazquez, this is a gui aimed at the package maints, sometimes they are the devels too tho mizmo: Yeah. Say you built a new spacewalk but I comaintain. ricky, totally we have a plan for letting u look at the koji logs for failedbuilds Cool mizmo: I see the new build on my MyFedora page. If I want source, I'm going to go to cvs, not the SRPM. But if I want to try it out, I need the binary rpms Something that I'd like would be the ability to see a package-build's lifecycle when it's incomplete. abadger1999, would it be helpful for this to have some kind of linkage to cvs too? mizmo: Yeah. That could also be useful. abadger1999, i was thinking srpm would be useful in case u want to build locally to test before pushing to koji but i dont know how common that would be Either viewcvs abadger1999, by package build lifecycle, u mean the steps the packages went through from start to failure, and the logs organized by which build stage they were generated during? or the cvs checkout command (although, if we're showing source rpm name already, that doesn't provide much) mizmo: yeah... and where it is. Example: bug report opened. changes checked into cvs changes tagged in cvs tag built in koji build pushed in bodhi build pushed to stable in bodhi End of lifecycle But we don't have an easy way to associate a CVS checkin with a bugzilla ticket, do we? tibbs: We don't... unless we've gotten to the bodhi stage. tibbs, i check things in in !fedora projects, and we always put 'bugzilla: 123456' or whatever as the first line of the check-in tibbs, but i dont know how it works in fedora mizmo: This is an ideal... implementation might chop off some of the beginning steps (bugzilla, cvs) I don't know if we have anything like that. I know there's some fancy processing, to get things to the docs folks for release notes. abadger1999, are there other steps in there? like, before the build gets pushed in bodhi, maybe it reaches a threshold of karma? mizmo: Yes and no... currently I haven't had any of my packages reach the karma threshold before I've decided to push it to stable. Actually, yeah, any way we can indicate to people that they have unpushed updates sitting in bodhi is good. We still have too many folks who push to testing and think they're done. So I'd be using this to check that I don't have builds that I forgot to push in bodhi or builds that I forgot to promote from testing to stable. myFedora might make adding karma easier,though. Actually, I wonder if I can bribe anyone to consider putting "random package review ticket" or "most recent new package review tickets" somewhere. tibbs, so how do the updates waiting to be pushed in bodhi get there? tibbs, is it that every successful koji build is then treated as an unpushed update? No, you need to go in and actually create an update. What's the best shell way to create a temporary filename? mktemp? tibbs, no need for bribery :) i think its a good idea I'm creating /var/run/ldm-xauth-randomstring files tibbs, so you fill out the form for the update in bodhi is the first part, but to actually have the update pushed u have to submit the associated package to be pushed out to whatever versions of fedora it needs to be? is there any difference in how u push packages to get into a final fedora release vs pushing packages that are one-off updates to a fedora final release that's already out? Well, after you've built something for, say, F8 in koji, then you go and create an update for it. Then it goes to stable and sits around. I do not remember whether we have any kind of automatic push to stable after a timeout yet.  mizmo: coming in now mizmo: so, successful builds in koji (for released branches) get tagged as being an 'update candidate'.  To get it into bodhi from there, you can use the web form, type 'make update' in the branch, or use the bodhi command-line tool to get it in there... by default it will get pushed to updates-testing j-rod J5 jankratochvil jaswinder jbarnes jbowes jcda jcollie jds2001_ Jeff_S jeremy jgranados jgranados_ jima jlaska jlb|away jmatthews jnettlet joe JohnMahowald jonmasters jrb jwb Ugh, sorry, "it goes to testing and sits around". Doh. J5, okie doke lmacken, so without any user input it gets pushed to updates-testing from koji if it was successfully built? mizmo: nope... user input is required to get it into bodhi oh okay but once it is in bodhi, it defaults to pushing right to updates-testing so when i do make update or bodhi command line or the bodhi webui, im filling out details like what bug # it fixed and what type of update it is (bug, enhancement, security, etc) mizmo: exactly Now, being able to click somewhere on a list of my recent koji builds and be taken to a page for generating an update might be useful. so it sounds like there is a problem to be addressed in that people fill out the details for the update, it goes to updates-testing, but doesn't go to an actual release? is that right? mizmo: Yes, that's been a problem. tibbs: +1 do people have issues figuring out which packages they need to fill out the form for? I do. yeah, there is an issue of people forgetting about updates in testing I tend to take a few days and do packaging work. okay so both are issues So I have a lot of builds to push then and might leave one out. with adequate community feedback (karma), updates can automatically hit stable.. but right now there is no automatic timeout in which an update will go from testing->stable Part of the problem is that there are just so many steps in the process, and some of them you have to wait for. tibbs, so if theres a list of your recent successful builds in koji, if they haven't been pushed to bodhi yet, there should be a button next to them saying 'create bodhi update now' or something where it takes them to the correct bodhi form mizmo: that would be ideal tibbs, if they have been pushed to bodhi but not beyond testing-updates, then there should be another button maybe 'push to final release' or something? mizmo: Yes. And ideally, prepopulates some of the bodhi fields too. (im not real sure about the terminology i think. if it's not testing updates, what is it called?) final updates? distro updates? bodhi refers to them as "testing" and "stable" It would be awesomely cool if I could have a list of open bugs against a package when creating a bodhi update. yep ah okay stable is the word i was grasping for cool tibbs, so when it asks u which bugzilla(s) its associated with it'll ajaxy auto fill for u? Yes, since bodhi can take care of closing bugs out when the update actually gets pushed to stable. mizmo: Screenshot of the bodhi new update form: v http://toshio.fedorapeople.org/bodhi.png I wonder if there's a way to sneak "currently open bugs" into that packager view It would save a step. And since we have so many steps, streamlining would be so awesome. http://fpaste.org/paste/4448 -- this is what the `make update` template will look like in the near future ricky, what if u start typing into the 'Bugs' field and you get an ajax drop down to show currently-open bugs? http://bugz.fedoraproject.org/yum it wouldnt take up any more screen realestate ahh thats a long list I guess to be useful it would have to show more than the bug number, but yeah. Also, it needs to take more than one bug. To be honest, I think bugs are more important than FAS stauts **status but maybe it doesnt make sense to show new, only assigned maybe? kernel is bigger :-) rpm too tibbs, oh yeh def there would be a summary maybe a checkbox widget would be more scalable It'd be cool if new vs. assigned were configurable, or could be changed with a click :-) a dropdown filter on bug status show: [ all | assigned | reopened | blah blah ] Of course, all of this bugzilla querying, given bugzilla's current status, is not going to be terribly fast. stop triggering my highlight, durn it also you'd only want to show bugs against the Fedora version that you're making an update for ajax, we're chatty! ajax: :-) wwoods, is the version its filed against usually accurate? bugz.fp.o shows all open bugs against all Fedora versions mizmo: usually, yes wwoods, (i know for satellite stuff its usually not, we use a diff field for that) hey, I need to make an rpm but only have the binaries, any guide you know of (many are very 'build from source' centric) there's really no X in ajax wrt bodhi... more like 'AJ' this gets shaky in the case where you have a bug that turns out to affect multiple Fedora versions wwoods, what is bugz.fpo? (i tried it and it just redirected to rh bz) mizmo: it redirects to pkgdb for the individual package names. mizmo: bugz.fedoraproject.org/$PACKAGE is, AFAIK, just a redirect to https://admin.fedoraproject.org/pkgdb/packages/bugs/$PACKAGE  (at admin.fedoraproject.org) convenient shorthand and to bugzilla.redhat.com for the front page. wwoods, ohhh okay cool wwoods, that is really nice wwoods: A lot of the bugs I see against non-Core packages are that way. okay this is good stuff hopefully i can mock up some cool shiz for u to see based on it ie the bug affects all non-EOL Fedora releases. mizmo: rock lmacken: ajaj perhaps. Excellent! abadger1999: right. the maintainer can either: a) have the F8 update close the bug, and leave it out of the F9 update (boo) or b) clone the bug so there's one per release (boo) (also boo)
 * 1) fedora-devel 7 Aug 2008
 * mizmo pets zodbot
 * kushal has quit (Read error: 104 (Connection reset by peer))
 * lxo has quit (Read error: 104 (Connection reset by peer))
 * Sonar_Guy is now known as sonargal
 * dmalcolm__ (n=david@c-24-218-127-207.hsd1.nh.comcast.net) has joined #fedora-devel
 * behdad (n=behdad@nat/redhat/x-8e2405cc02a1e991) has joined #fedora-devel
 * jgranados_ (n=jgranado@234.94.broadband4.iol.cz) has joined #fedora-devel
 * stickster is now known as stickster_mtg
 * J5 has quit ("Ex-Chat")
 * lxo (n=aoliva@201.82.112.27) has joined #fedora-devel
 * ethospir (i=ethospir@unaffiliated/ethospir) has joined #fedora-devel
 * kushal (n=kdas@122.169.93.120) has joined #fedora-devel
 * kushal has quit (Read error: 104 (Connection reset by peer))
 * kushal (n=kdas@122.169.93.120) has joined #fedora-devel
 * mccann has quit (Read error: 110 (Connection timed out))
 * _numbers_ (n=_numbers@unaffiliated/numbers/x-50182) has joined #fedora-devel
 * specing (n=specing@89-212-30-95.dynamic.dsl.t-2.net) has joined #fedora-devel
 * kushal has quit (Read error: 104 (Connection reset by peer))
 * kristopol (n=chris@76.234.18.138) has joined #fedora-devel
 * kushal (n=kdas@122.169.93.120) has joined #fedora-devel
 * dmalcolm_ has quit (Read error: 113 (No route to host))
 * kushal has quit (Read error: 104 (Connection reset by peer))
 * kushal (n=kdas@122.169.93.120) has joined #fedora-devel
 * rnorwood has quit (Read error: 110 (Connection timed out))
 * petercccc has quit ("Leaving")
 * thm has quit (Remote closed the connection)
 * sonargal is now known as Sonar_Guy
 * rsquared_ (n=rsquared@nat/redhat/x-06edba826e075e03) has joined #fedora-devel
 * Subhodip has quit (Read error: 110 (Connection timed out))
 * scfe (n=scfe@f053002082.adsl.alicedsl.de) has joined #fedora-devel

Full Log (for pkgdb)
ge maintainer question: do you care who can watch bugzillas on your package? (eg the pkgdb watchbugzilla acl) not really mizmo: only in really rare cases so why is there an explicit approve process for it? ajax, which cases? mizmo: AIUI people worried about security bugs good question ie, if someone's actively trolling me geppetto, what is AIUI? "as i understand it" mizmo: As I Understand It ah okay so, it's for stalkers and security bugs the security bug thing is bogus though because if an embargoed security issue comes thru watchers will see it? ajax, how is it bogus? i was under the impression that security bugs were restricted to assignee only or at least, created with nobody on the cc list. I think the complaint was that "sometimes" security BZs are created without the security flag ah okay that makes sense ajax geppetto: that's not really a strong excuse okay how about watching commits? do you care who watches the commits for a package you own? but, sure. mizmo: not even a little. i'd prefer if more people watched my commits, in fact.
 * nirik notes that it's really hard to have embargoed security bugs in fedora...

okay i got a pkgdb question now - what is approve acls? if you have approval acl does that mean you can approve people to have the other acls available?

mizmo: it means you can approve other people whom have requested some sort of ACL for that package. thanks f13 f13, do you know if the 'group members can also commit' is on a package across releases level, or is that per release? abadger1999: ping sadmac2: pong f13, i can't imagine there is a group per release? (eg there would be a gdm-f7 gdm-f8 gdm-f9 groups??) mizmo: I thikn that's a check box per-release f13, ohhh okay f13, one gdm group and u check it off per release mizmo: the 'group' is 'uberpackager' EDIT: The group is now 'provenpackager' abadger1999: is there anything left on the wiki to do? mizmo: Yes, per release. thanks :) mizmo: there isn't a group per package, there is one "overseeing" group, called uberpackager. ohh okay mizmo: At some indefinite time in the future the groups interface will change mizmo: you ahve the option of allowing this overseeing group access to your packager. sadmac2: I saw something the other day with csextras... trying to remember what... so the commit acl is a way to give someone commit access to say gdm if they are not in the uberpackager group I think it was Cvsextras instead of cvsextras... I wonder if the search was case sensitive. mizmo: Yep cool
 * metavoid (n=nnd@natpool1-1.progtech.ru) has joined #fedora-devel
 * steved is now known as steved_away