2008/7/12 Doug Ledford <dledford@xxxxxxxxxx>:
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
On Fri, 2008-07-11 at 22:41 -0400, Jesse Keating wrote:And this is at least partially our own fault. For instance, the fact
> Unfortunatly I live in reality where many upstreams post process the
> scm checkout so reliance on the scm alone is not possible.
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
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
