Edit Info Other
Login

Diff for "Contributors"

Differences between revisions 4 and 6 (spanning 2 versions)
Revision 4 as of 2007-09-28 13:14:11
Size: 9875
Editor: anonymous
Comment: converted to 1.6 markup
Revision 6 as of 2007-10-12 14:21:31
Size: 5941
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
== Becoming a RPM Fusion contributer == == Becoming a RPM Fusion contributor ==
Line 9: Line 9:
Having packaging experience in Fedora is much preferred, but newcomers are welcome too. However if you are a newcomer you must first get sponsored, that is find someone to guide you while you learn the ropes. Having packaging experience in Fedora is much preferred, but newcomers are welcome too. However if you are a newcomer you must first get sponsored, which means find someone to guide you while you learn the procedures.
Line 13: Line 13:
In either scenario you should create your first RPM Fusion package and submit this for review as described below. The review process is handled through bugzilla as will any bugs reported against your packages. In either scenario you should create your first RPM Fusion package and submit it for review as described below. The review process is handled through Bugzilla, as will be any bugs reported against your packages.
Line 17: Line 17:
The email address that you use for your bugzilla account should be the same email address as you use for all things related to RPM Fusion. The email address that you use for your Bugzilla account should be the same email address as you use for all other things related to RPM Fusion.
Line 21: Line 21:
Once this is done join the [[http://lists.fedoraunity.org/mailman/listinfo/repo-merge-discussion|RPM Fusion mailing list]] (and, optionally, the [[http://livna.org/mailman/listinfo/freeworld-graphics|freeworld graphics mailing list]]) and introduce yourself there. Include a link to the review request for your first package in your introduction, and if you're a newcomer also mention that you need someone to sponsor you. Once this is done, join the [[http://lists.rpmfusion.org/|Develoers Mailing Lists]] and introduce yourself there. Include a link to the review request for your first package in your introduction, and if you're a newcomer also mention that you need someone to sponsor you.
Line 25: Line 25:
Also join the RPM Fusion subversion mailing list (missing link). The subversion mailing list is used for commit messages for our Subversion repository. You should subscribe to this list to track the changes to our packages. Also join the RPM Fusion CVS commits mailing list (missing link). The CVS commits mailing list is used for commit messages from the CVS repository. You should subscribe to this list to track the changes to all the packages.
Line 44: Line 44:
Before your package can become part of RPM Fusion it must first be reviewed, goto https://bugzilla.rpmfusion.org/ and create a new bug: Before your package can become part of RPM Fusion it must first be reviewed, [[https://bugzilla.rpmfusion.org/enter_bug.cgi?product=Package%20Reviews|create a new bug report as follows]] :
Line 46: Line 46:
    * choose "Infrastructure" as product
    * choose "Review Requests" as Component
    * set Summary to: "Review request: %{name} - %{summary} Where %{name} and %{summary} come from the specfile
    * Put the following in the description:
          * full URLs to the specfile and the SRPM for the new package
          * a short description for the package (hint use %description from the spec)
          * why this package is not eligible as a regular Fedora package
          * rpmlint output from running rpmlint on both the SRPM and RPM's built from it. Explain for each rpmlint message why you've chosen to ignore it.
          * mention if this is your first RPM Fusion package.
    * The request should also be set to block the tracker bug: RF_NEW (#2). Other contributers can easily check for packages that need reviewing. If you want to help others by doing reviews yourself go to: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2
    * Choose "Package Reviews" as Product.
    * Choose "Review Requests" as Component.
    * Set `Summary` to: "`Review request: %{name} - %{summary}`", with %{name} and %{summary} from the package.
    * Put the following in the Description:
          * Full URLs to the spec file and source rpm of the package.
          * A short description for the package (usually, the %description from the spec file).
          * Why this package is not eligible to be included in Fedora.
          * The output `rpmlint` gives on both the source and binary packages. Explain for each message why you've chosen to ignore it.
          * Mention if this is your first RPM Fusion package.
    * The request should also be set to block the tracker bug: `RF_NEW` (bug #2). This way, other contributers can easily check for packages that need reviewing. If you want to help others by doing reviews yourself go to [[https://bugzilla.rpmfusion.org/show_bug.cgi?id=2|bug #2]].
Line 61: Line 61:
When a real / full review gets done the reviewer will assign the bug to him, remove the blocker on RF_NEW (#2) and set it to block the tracker bug: RF_REVIEW (#3). This indicates that a review is in progress. A review request should only be accepted by a maintainer that has at least one package in the RPM Fusion repository.  When a proper review gets done the reviewer will assign the bug to him, remove the blocker on `RF_NEW` and set it to block the tracker bug `RF_REVIEW` (bug #3). This indicates that a review is in progress. A review request should only be accepted by a maintainer that has at least one package in the RPM Fusion repository.
Line 63: Line 63:
The reviewer should follow the [[http://fedoraproject.org/wiki/Packaging/ReviewGuidelines|Fedora Review Guidelines]] as close as possible, obviously taking into account any differences between Fedora and RPM Fusion. As RPM Fusion is more permissive with the content it allows, exceptions to these guidelines are allowed in some circumstances but care and common sense should prevail. The reviewer should ensure that any deviations from the [[http://fedoraproject.org/wiki/Packaging/Guidelines|Fedora Packaging Guidelines]] are sane and justified in the package they are reviewing. If in doubt, please ask on the RPM Fusion mailinglist. The reviewer should inform the contributor of any changes that need to be made to their package, if any. The contributor should update their package as necessary, including bumping the release version and submit the new SPEC file and SRPM URL. The reviewer should verify the changes. This is repeated as many times as necessary until the contributor and reviewer are happy with the final package. The reviewer should follow the [[http://fedoraproject.org/wiki/Packaging/ReviewGuidelines|Fedora Review Guidelines]] as close as possible, obviously taking into account any differences between Fedora and RPM Fusion. As RPM Fusion is more permissive with the content it allows, exceptions to these guidelines are allowed in some circumstances but care and common sense should prevail. The reviewer should ensure that any deviations from the [[http://fedoraproject.org/wiki/Packaging/Guidelines|Fedora Packaging Guidelines]] are sane and justified in the package they are reviewing. If in doubt, please ask on the RPM Fusion mailing list. The reviewer should inform the contributor of any changes that need to be made to their package, if any. The contributor should update their package as necessary, including bumping the release version and submit the new SPEC file and source rpm URL. The reviewer should verify the changes. This is repeated as many times as necessary until the contributor and reviewer are happy with the final package.
Line 67: Line 67:
If your improved version is okay the reviewer will approve it, by adding a comment that the package is approved, removing the blocker on RF_REVIEW (#3) and setting the review request to block the tracker bug RF_ACCEPT (#4). Once the reviewer approves the package, by adding a comment that the package has been approved, remove the blocker `RF_REVIEW` bug and set the review request to block the tracker bug `RF_ACCEPT` (bug #4).
Line 69: Line 69:
Ask for creation of a directory for your package in svn.

Once approved the submitter sends a private mail to Dams (anvil@rpmfusion.org)* to request the creation of a directory in svn for this package and the creation of an ACL so that he will be able to write to that dir. If this is your first package then Dams will also create an svn account for you.

* ATM, Dams is the only person with the necessary powers to create the needed ACL.
Ask for the creation of a directory for your package in the CVS repository.
Line 77: Line 73:
Once the dir has been created in svn, the package must be imported into svn. RPM Fusion recently has created an import script, but that's alpha, so you might want to do the manual import. Once the CVS directory has been created, the package must be imported.
Line 79: Line 75:
==== Configure SSH ====

The svn.rpmfusion.org Subversion sshd listens on a non-default port, 6868. To configure it, add something like this to your ~/.ssh/config:

{{{
Host svn.rpmfusion.org
     Port 6868
}}}

==== Import the manual way ====

Before you can begin the import you need to have a directory structure matching that in svn, or a complete checkout of svn. If you already have this you can skip the steps below:
{{{
   mkdir <some-convenient-path>/rpmfusion
   cd <some-convient-path>/rpmfusion
   svn co svn+ssh://<username>@svn.rpmfusion.org/rlo/plague-svn
   svn co svn+ssh://<username>@svn.rpmfusion.org/rlo/common
   mkdir packages
}}}

And then now the actual importing:
{{{
   cd <some-convenient-path>/rpmfusion/packages
   svn co svn+ssh://<username>@svn.rpmfusion.org/rlo/packages/<package-name>
   cd <package-name>
   svn mkdir devel
   svn copy ../../plague-svn/Makefile-in-package-dir ./Makefile
   svn copy ../../plague-svn/Makefile-in-branch-dir ./devel/Makefile
   <favorite editor> devel/Makefile -> change NAME to <package-name>
   cd devel
   cp <package-name>.spec <package-sources> <package-patches> .
   sha1sum <files-to-be-imported-in-lookaside-cache> > SHA1SUM
   svn add <package-name>.spec <package-patches> SHA1SUM
   cd ..
   svn commit -m "initial devel libmms import" Makefile devel
   svn copy devel F-<current>
   echo FC-<current> > F-<current>/branch; svn add F-<current>/branch
   svn commit -m "initial F-<current> libmms import" F-<current>
}}}

See other packages in svn for correct branch names (FC-6, F-7, devel, ...)

==== Automated import ====

If you already have a checkout of the common dir you can skip the steps below:
{{{
   mkdir <some-convenient-path>/rpmfusion
   cd <some-convient-path>/rpmfusion
   svn co svn+ssh://<username>@svn.rpmfusion.org/rlo/common
}}}
Next download the ALPHA svn-import.sh script and save it in the common dir, then do:
{{{
   chmod +x svn-import.sh
   ./svn-import.sh <path-to>/<package-name>-<version>-<release>.src.rpm
}}}
And sit back and relax while the script (hopefully) does the work for you.

=== Tag the imported sources ===

Now you should tag the just imported sources so that the plague buildsys can find them:
{{{
   cd <some-convenient-path>/rpmfusion/packages/<package-name>/devel
   make tag
   cd <some-convenient-path>/rpmfusion/packages/<package-name>/F-<current>
   make tag
}}}
If make tag fails on this line:
{{{
   test -z "$(LC_ALL=en_US.UTF-8 svn status $(dirname <package-name>.spec))"
}}}
Do a "svn status" in the dir. Any files which are printed with a "?" in front of them should be removed (unless they should be in svn in which case you should do a: "svn add <filename>"). If there are files with a letter in front of them, then the dir contains changes not yet committed to svn, commit them and try again.
/!\ To be detailed once the CVS repository is in place.
Line 153: Line 79:
Add a comment to the review that the import has been done, remove the blocker on RF_ACCEPT  (#4) and close the bug as RESOLVED FIXED. Add a comment to the review that the import has been done, remove the blocker on `RF_ACCEPT` and close the bug as `RESOLVED` `FIXED`.
Line 157: Line 83:
   1. Update your local copy and test it
   2. Remember to keep the SHA1SUM file up to date with sha1sums of all files in the look aside cache (or destined to it). Do this even if you don't have access to upload to the look aside cache, it is a prerequisite for updating it.
   3. Commit your changes to svn, with a _useful_ changelog message (same command line syntax as cvs, see svn docs)
   4. After committing your change run "make tag" to tag your files so that the plague buildsystem can find the correct version to build.
   5. The commit message from step 3 is sent to a mailing list which is being monitored by people who can update the look aside cache (if necessary) and give the build command to the plague buildsys.
   1. Update your local copy and test it.
   1. Commit your changes, with a '''useful''' changelog message.
   1. ... the next steps will depend on the infrastructure not yet in place at the time of writing.

1. Contributing to RPM Fusion

So, you've decided to become a contributor to RPM Fusion? This guide will lead you through your first package submission and teach you how to update your package(s) in the future.

2. Becoming a RPM Fusion contributor

Having packaging experience in Fedora is much preferred, but newcomers are welcome too. However if you are a newcomer you must first get sponsored, which means find someone to guide you while you learn the procedures.

2.1. Create a Bugzilla Account

In either scenario you should create your first RPM Fusion package and submit it for review as described below. The review process is handled through Bugzilla, as will be any bugs reported against your packages.

Make sure you have an account in Bugzilla.

The email address that you use for your Bugzilla account should be the same email address as you use for all other things related to RPM Fusion.

2.2. Join the Mailing List

Once this is done, join the Develoers Mailing Lists and introduce yourself there. Include a link to the review request for your first package in your introduction, and if you're a newcomer also mention that you need someone to sponsor you.

If you have questions about the packaging process, this is the place to ask.

Also join the RPM Fusion CVS commits mailing list (missing link). The CVS commits mailing list is used for commit messages from the CVS repository. You should subscribe to this list to track the changes to all the packages.

3. Submitting a new package

3.1. Read the packaging guidelines

RPM Fusion follows the Fedora packaging guidelines, make sure you've read and understood these:

It is also a good idea to read the items which will be checked during the review of your package and to verify yourself that these are all ok:

3.2. Create a package review request

Before posting a review request, you should upload your SRPM and SPEC file to any accessible location on the internet.

Before your package can become part of RPM Fusion it must first be reviewed, create a new bug report as follows :

  • Choose "Package Reviews" as Product.
  • Choose "Review Requests" as Component.
  • Set Summary to: "Review request: %{name} - %{summary}", with %{name} and %{summary} from the package.

  • Put the following in the Description:
    • Full URLs to the spec file and source rpm of the package.
    • A short description for the package (usually, the %description from the spec file).
    • Why this package is not eligible to be included in Fedora.
    • The output rpmlint gives on both the source and binary packages. Explain for each message why you've chosen to ignore it.

    • Mention if this is your first RPM Fusion package.
  • The request should also be set to block the tracker bug: RF_NEW (bug #2). This way, other contributers can easily check for packages that need reviewing. If you want to help others by doing reviews yourself go to bug #2.

3.3. Wait for your package to be reviewed

As time permits another RPM Fusion contributer will review your package, sometimes other people add a few comments, this does not constitute a review.

When a proper review gets done the reviewer will assign the bug to him, remove the blocker on RF_NEW and set it to block the tracker bug RF_REVIEW (bug #3). This indicates that a review is in progress. A review request should only be accepted by a maintainer that has at least one package in the RPM Fusion repository.

The reviewer should follow the Fedora Review Guidelines as close as possible, obviously taking into account any differences between Fedora and RPM Fusion. As RPM Fusion is more permissive with the content it allows, exceptions to these guidelines are allowed in some circumstances but care and common sense should prevail. The reviewer should ensure that any deviations from the Fedora Packaging Guidelines are sane and justified in the package they are reviewing. If in doubt, please ask on the RPM Fusion mailing list. The reviewer should inform the contributor of any changes that need to be made to their package, if any. The contributor should update their package as necessary, including bumping the release version and submit the new SPEC file and source rpm URL. The reviewer should verify the changes. This is repeated as many times as necessary until the contributor and reviewer are happy with the final package.

3.4. Your package gets approved

Once the reviewer approves the package, by adding a comment that the package has been approved, remove the blocker RF_REVIEW bug and set the review request to block the tracker bug RF_ACCEPT (bug #4).

Ask for the creation of a directory for your package in the CVS repository.

3.5. Import your package

Once the CVS directory has been created, the package must be imported.

/!\ To be detailed once the CVS repository is in place.

3.6. Request a build

Add a comment to the review that the import has been done, remove the blocker on RF_ACCEPT and close the bug as RESOLVED FIXED.

4. Updating an existing package

  1. Update your local copy and test it.
  2. Commit your changes, with a useful changelog message.

  3. ... the next steps will depend on the infrastructure not yet in place at the time of writing.

CategoryContributing

Contributors (last edited 2023-11-14 09:37:57 by anonymous)