Using as redhat-rpm-config "upstream" repo

We (the current redhat-rpm-config maintainers) would like to move the
"upstream" SCM repository for redhat-rpm-config to be the regular dist-git repository. Rationale:

- There is no real release process, all changes made to redhat-rpm-config
are immediately destined to rawhide and this works just fine.
- It's no more than 30ish files and even less in the future, trivially
manageable in a specfile.
- There's no need for a separate dist tarball. And a tarball it's available
from dist-git cgit anyway should someone need it.
- redhat-rpm-config has many contributors.

The summary of the above is that the separate fedorahosted git repository,
access permissions and tarballs make no real sense. Development already
happens in dist-git anyway. Thus keeping a separate repository is make-work
which as history has shown doesn't get actually done [0], and using the
dist-git repository for development over a tarball that once existed,
patches patching each other etc, is very messy and hard to track. Much more
so than if we'd just store the files as is in dist-git.

It is not a usual practice for things for which Fedora is upstream, but I
think admitting the facts and using dist-git as the development repository
instead of pretending it isn't and jumping through extra hoops is the right
thing to do for redhat-rpm-config which is in many respects quite special.
Are there any MUST policies against doing so?

[0] Until recently, fedorahosted git lagged far behind dist-git. I brought
it up to date, but doing it properly is not a fun experience at all, and
not doing it properly is not worth doing it. And after doing it it is my
firm opinion that this repository shouldn't really exist in the first
place, there aren't any real benefits.


Re: Using as redhat-rpm-config "upstream"

By Kevin Fenzi at 03/10/2014 - 11:16

Having touched the redhat-rpm-config package, I agree with you. ;)

Maintaining it in pkgs seems quite sensible.