Bodhi documentation for new packages

Luke Macken lmacken at redhat.com
Sat May 17 14:42:16 UTC 2008


On Fri, May 16, 2008 at 10:24:05AM -0400, Aaron S. Hawley wrote:
> [Please, Cc me replies, thanks.]
>
> Luke Macken wrote:
>> On Mon, May 05, 2008 at 03:27:01PM -0400, Aaron S. Hawley wrote:
>>>
>>>
>>> The directions for joining Fedora as a package maintainer[1] are really 
>>> great. Unfortunately, they trail off at the end when it comes to 
>>> important tasks of making the package live using the Bodhi system, 
>>> section "Request updates to released Fedoras for your new package".  I 
>>> ran into this roadblock last month, and it hasn't improved since.
>>>
>>> As a new maintainer, I know very little about the updates infrastructure 
>>> of Fedora, which I predict is assumed knowledge about using Bodhi.  This 
>>> is probably unfair to new maintainers.  Here's my proposal for what this 
>>> section should say.  It is also what I did, so I'm sure it needs 
>>> correction, and let me know so I can get my new package (gnue-common) 
>>> live.  Thanks for Fedora, /a
>>
>> Thanks for taking the time to give feedback and help improve our documentation.
>> I completely agree that the updates/bodhi docs need some work.  Come F9,
>> I hope to have a lot of new bodhi features and changes to existing
>> workflow deployed, so I'll be tweaking the documentation a lot then.
>>
>>> -- BEGIN --
>>>
>>> The first field asks for the name of the "Package".  This will feature a 
>>> name completion system, but is currently broken.  It uses the tag used in 
>>> Fedora CVS and the Koji build system, e.g. 
>>> <package-name>-<version>-<release>.fc9.
>>
>> The build completion is no longer broken.  It doesn't not query by tag
>> (yet, at least), it simply offers all builds for the given package.
>>
>>> For new packages, choose "enhancement" as the "type" of update.
>>
>> Correct, for now.  Spot and I discussed this yesterday and we thought it
>> would probably be a good idea to add another type of update specifically
>> for new packages.  This would allow tools like PackageKit to say "Hey,
>> check out the newest packages in Fedora that you could possibly install!"
>>
>>> Keep the "Request" as "testing".
>>
>> It's probably best to leave this up to the developer pushing the update.
>> I originally made bodhi force packages to go through testing first, but
>> many people complained and had their reasons for wanting pushing directly
>> to stable.
>>
>>> There are no bugs that are related to any new package, so leave the 
>>> "Bugs" field blank.
>>
>> New packages could possibly add their Review Request bug to the update,
>> which will have bodhi automatically close it when it gets pushed.
>>
>>> For new packages, add a copy of the package's description in the "Notes" 
>>> section so end users will know what it is.[2]
>>
>> This sounds fine.
>>
>> Cheers,
>> luke
>
> Luke, I had a chance to rewrite the instructions for adding new packages 
> with Bodhi using your response.  I can throw them on the Wiki if you like.
>
> --BEGIN--
>
> The first field asks for the name of the "Package".  This field will 
> auto-complete the package name found in the Koji build system, e.g. 
> <package-name>-<version>-<release>.fc9.  If completion doesn't work, just 
> enter the package build name yourself.
>
> For new packages, choose "enhancement" as the "type" of update.
>
> Put the "Request" as "testing" if you want to put the package through 
> testing first, see [:QA: Fedora Quality Assurance].  Put "stable" if you 
> want to push the package directly to stable.
>
> There are no bugs that are related to any new package, so leave the "Bugs" 
> field blank.  In the future, the bug number for the Review Request bug 
> might be entered here for Bodhi to automatically close when it gets pushed 
> to the request update status.

There's nothing stopping people from entering the review bug in now, and
it's actually done quite frequently.  I don't see any reason to not
recommend doing this.

> For new packages, add a copy of the package's description in the "Notes"
> section so end users will know what the package is.

Other than what I mentioned above, this looks fine.  Feel free to update
the wiki once you change that.

Thanks!

luke




More information about the devel mailing list