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

[Jesse Keating]

2008/7/12 Doug Ledford <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.
>
> If I were the kind of person looking for reasons to shut this idea down,
> I would jump on the subversion thing.  On the other hand, if I'm someone
> were looking to make this work, they would accept that as a hurdle we
> can tackle on a case by case basis and that we could make it work at
> least some of the time.  I've simply got the impression that a lot of
> the people jumping into this discussion are in the first group of
> people.  I'm in the second.
>

I'm not necessarily trying to shut it down, but I need something that works
with the lowest common demoninator, without causing a lot of confusion and
complication when trying to do something across a number of packages.  I
don't want maintainers to "guess" at how to do things, and I certainly don't
want doing package updates to be bandwidth prohibitive to people.  The fact
that our package scm right now consists of a spec file, maybe a patch or
two, and a file that references the actual source means it's an extremely
small checkout to deal with when needing to update.  If we were making
people clone the entire source, including all the history from upstreams,
that's going to be pretty prohibitive.  Tried cloning the anaconda git repo
lately?

I'm really happy to see thought in this area, and I certainly need to drop
the requirements/wishes/hates of the current/ list that I got from FUDCon
into the wiki somewhere, so that when people are having these thoughts they
can have a set of constraints to deal with.

--
Jes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080712/481658f5/attachment.htm>