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