[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Jesse Keating wrote:

2008/7/12 Doug Ledford <dledford redhat com <mailto:dledford 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.


Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]