Heads-up: brand new RPM version about to hit rawhide

Toshio Kuratomi a.badger at gmail.com
Sun Jul 13 22:24:11 UTC 2008


Jesse Keating wrote:
> 
> 
> 2008/7/12 Doug Ledford <dledford at redhat.com <mailto:dledford at redhat.com>>:
> 
>     On Fri, 2008-07-11 at 22:41 -0400, Jesse Keating wrote:
> 
>      > Unfortunatly I live in reality where many upstreams post process the
>      > scm checkout so reliance on the scm alone is not possible.
> 
>     And this is at least partially our own fault.  For instance, the fact
>     that upstream opensm, libibcommon, libibumad, libibmad, librdmacm,
>     libibcm, and a few others from the OFED package set run autogen.sh is
>     because someone in Fedora told me to tell them to.  I originally told
>     them not to and I was "corrected".  So it seems a bit fishy to me to use
>     that as a reason that we can't use an SCM checkout, we created our own
>     problem here, I would think we should be able to solve our own problem.
> 
>     And that gets to my next point, which really is that people are getting
>     caught up in how things are (like processing with autogen.sh), and
>     aren't considering if things *must* be that way.  For example, you can't
>     really clone a subversion repository.  You can check it out, but commits
>     have to go back to the central repo.  This means we would have a hard
>     time dealing with subversion upstream sources.  However, as a possible
>     policy implementation, we could contact upstream and request that the
>     fedora package maintainers be given their own branches in the upstream
>     repo, and that they have full write access on those branches, and the
>     package maintainer could then merge over specific updates from the
>     upstream primary branches into the fedora branches as we decided to
>     upgrade to a particular release.  We could then request the ability to
>     rsync the actual repo to our own servers so we would always have our own
>     copy should upstream decide to implode.  So, there are ways we could
>     *make* a subversion upstream work, but it's not pretty.
> 
I'd *much* rather see us decide to stick with tarballs if upstream is 
using an svn repository.  We'd need to support tarballs for cvs 
repositories, non-version controlled upstreams, and other random stuff 
so there's no need to build a Rube Goldberg machine simply for svn 
repositories.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080713/29df251e/attachment.sig>


More information about the fedora-devel-list mailing list