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

• 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. <mizmo> 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 <lmacken> mizmo: that would be ideal
• I'd also like to find builds that I forgot to promote from testing to stable. <mizmo> 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?

<abadger1999> mizmo: Yes. And ideally, prepopulates some of the bodhi fields too.

• 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.
• <tibbs> 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.
• <lmacken> 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
• <tibbs> 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

<lmacken> 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 <mizmo> lmacken, so without any user input it gets pushed to updates-testing from koji if it was successfully built? <lmacken> mizmo: nope... user input is required to get it into bodhi <lmacken> but once it is in bodhi, it defaults to pushing right to updates-testing <mizmo> 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) <lmacken> mizmo: exactly

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

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

<tibbs> 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.

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

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

Full Log (package lifecycle)

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

Full Log (for pkgdb)

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

<mizmo> 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?

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