On Tue, Aug 08, 2006 at 03:59:13AM -0400, Andres Salomon wrote: > On Sat, Aug 05, 2006 at 06:12:19PM +0000, David Nusinow wrote: > > Hi everyone, > [...] > > he's got a lot of experience. Either way, I'm 100% unwilling to do any sort > > of switch until after we're frozen for etch, and even then there are issues > > like where to host it that need to be solved. > > > > I've complained a lot about SVN in the past; however, a lot of my complaints > have to do more with the way we're using it. The SVN repo is hosted on a dsl > connection, which makes it quite slow to do a check-out; on top of that, we > need to deal w/ 3 separate branches (trunk, 7.1, and vendor) in order to work > with it. And finally, we're tracking upstream's source as well, which makes > for a whole lot of unnecessary stuff that must go across the network (and > sit on my hard drive). Working with SVN would be a lot less of a hassle if > the repository was a fraction of the size that it is now.
Right, I'm currently thinking that the vendor branch can and will go. I'll give a few more days with it to see if anyone else speaks up in favor of it, but currently it's slated for death. As for the 7.1 versus trunk, I don't have a good way around that. It's just a limitation of svn to need full checkouts for branches. > > 1) Do we keep using the vendor branches? Are they worthwhile given that we > > keep all important patches in quilt? My sense is no, they're not, > > provided that we continue to use quilt this way. > > > > Is there a point to keeping a vendor branch? Upstream provides tarballs, > upstream provides a git repository that's far more useful than our per-release > vendor commits, and we have orig.tar.gz files on debian mirrors all over the > world.. What does a vendor branch buy us? Relatively little. If you want to easily diff the auto* stuff, it gives you that. Other than that, not much. The auto* stuff didn't come in handy so much as I'd hoped, so yeah... vendor can probably just go defunct unless we have some real reason to keep it. > > 2) Do we keep putting the upstream tree in our svn repo? My sense is that > > we should continue to do so. The reason being that we regularly are > > patching the auto* build system from upstream. Keeping those generated > > files in-tree ensures that we have the same build system from machine to > > machine. This is a hideously fragile system as it is, and keeping things > > in-tree seems to provide some resiliancy. If someone has a good > > mechanism to get around this, I'm all ears, because it is a pain to keep > > it all in-tree. > > > > The only good reason I'm aware of for keeping the upstream tree in our SVN > repo is for the auto* stuff; and there is no guarantee that what's in > the debian archive is actually what's in the SVN repo. Have you ever > autoreconf'd out of habit w/ updated auto*, without thinking twice about it? > I have. Committing those changes to a repository is an extra step, and > doesn't seem overly worth it. > > Instead, let's enforce certain things. If we desire having a certain version > of autoconf, automake, and libtool used for our packages, let's have checks > in the actual code to ensure certain versions are used. AC_PREREQ() in > configure.ac comes to mind, for example. Ensuring that a certain version > of xutils-dev is used to rebuild could be done (looking closer, it appears > someone's already implemented the framework for this: > XORG_MACROS_VERSION(x.y)). And so on.. I'd also like to shrink the repo. We'll need something concrete. We need to know if we can use or adapt svn-buildpackage so that the build process is automated. Also, would you mind producing a patch for some package to use as a testbed for this? We'd need a way to easily enforce this across the whole package set too. The patch mechanism we currently have isn't up to snuff for that obviously, demanding a lot of manual labor. I don't know how to fix that though. > > 3) Do we need to keep using quilt? Branden's original plan was to keep the > > upstream source in-tree and not use dpatch or quilt or anything like it. > > This is an option, but if we go this route we need to keep using the > > vendor branch. I'm inclined towards quilt myself, as its proven and it > > works. On the other hand, we're carrying around quite a bit of code to > > make sure quilt works for us. My plan is to switch our system over to > > what's built-in to the quilt package to make the less of our problem, > > but some people still prefer to keep it all in the repository. > > > > I like the patching system that's currently in place. Me too. I think the consensus is to keep it, although I think pushing the logic in to the quilt package is wise. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
