Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/approved fedora rpm updates #434

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

imcleod
Copy link
Contributor

@imcleod imcleod commented Jul 31, 2014

This bundles the changes I needed to make to get pyrax approved as a Fedora package. Most are RPM specific changes. The code changes are:

  1. Remove #! headers from scripts that are not meant to be executable - This is a check done by rpmlint. We must pass rpmlint testing as part of the package approval process.

  2. Add the license for slugify() inline - This code is 3-clause BSD and originally came from django, by way of an Activestate recipe. Adding explicit attribution and a copy of the license removes any uncertainty about compliance, which is good (and a requirement for Fedora).

The final commit sets up the RPM scripts and version/release details for ongoing development and explains how to change the values in preparation for the next release.

imcleod added 8 commits July 28, 2014 13:33
This finalizes changes required to meet Fedora package requirements and
tags the resulting RPM as 1.9.0-2, including a meaningful changelog entry.

When merging this upstream please preserve the changelog.
…opment

This represents the suggested RPM approach for post-release development.
We increment the version but set the RPM release tag to "0" which activates
generation of time and git-based RPM release strings.  I am assuming a next
version of 1.9.1

When 1.9.1 is ready for release, increment the RPM release string to "1"
as part of the commit forming the official release.  Then, as the first
post-release commit, repeat the changes seen in this commit for 1.9.2
(or whatever the appropriate next version will be).
@imcleod
Copy link
Contributor Author

imcleod commented Jul 31, 2014

The package review bugzilla entry provides some details about the changes represented in this pull request:

https://bugzilla.redhat.com/show_bug.cgi?id=1123044

@briancurtin
Copy link
Contributor

My apologies for the delay in getting back to you. Per our HACKING guidelines, would you be able to create this pull request against the working branch instead?

@sivel
Copy link
Contributor

sivel commented Nov 4, 2014

There are a few things now out of date with this PR. A few things that I know are affecting this:

  1. We no longer have the copied slugify function with BSD license
  2. The COPYING file no longer exists
  3. shebang lines have been removed

Additionally, there are a few things that would need to change before this would be accepted:

  1. Remove the notes referencing https://bugzilla.redhat.com/show_bug.cgi?id=1123044, pyrax packages included in an OS software repo should use the upstream code, and not come from 3rd party locations
  2. Your source0 line in the spec file needs to reference upstream
  3. the version should not be bumped by a PR from a non core commuter
  4. I'd like to not see snapshot stuff added to setup.py, if we accept this, then it should be needed as your source should be upstream anyway
  5. There are dependency changes that would need to be reflected in the spec file, such as python-swiftclient and httplib2 not being required.
  6. All commits squashed per the instructions in HACKING.rst

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants