If that helps, in gunicorn we used to have all the packaging in the repo, then the debian upstram packager asked to us to remove it if we can. (we removed it).
So I guess it's probably better to keep the packaging outside the main repo. - benoit On Wed, Jun 26, 2013 at 3:41 PM, Robert Newson <robert.new...@gmail.com> wrote: > +1 to keeping it separate, isn't that what Debian recommend anyway? > Fairly sure those git tools are about the debian folder with branches > to track pristine upstream. That just happens to also be us. > > On 26 June 2013 14:23, Noah Slater <nsla...@apache.org> wrote: >> My preference is that we keep packaging out of couchdb.git. I have seen on >> other projects that source releases have to be cancelled mid-vote because >> of some bug in the Debian packaging. Our releases are painful enough, so >> I'd rather avoid this. >> >> What I'd suggest is that you request a new Git repos and put in there. We >> could have couchdb-deb.git, couchdb-rpm.git, couchdb-win.git, >> couchdb-mac.git. Whatever really. Git repos are cheep! >> >> If you want to request one, just send an email to the list with a >> [PROPOSAL] tag (i.e. "This is a concrete proposal with consensus in effect >> and a 72 hour time limit") wait 72 hours, and then open an Infra JIRA >> ticket. >> >> (Good to have you on the list, Laszlo. Are you also subscribed to >> annou...@couchdb.apache.org? We will only use that for release >> announcements and security disclosures.) >> >> >> On 22 June 2013 00:45, Laszlo Boszormenyi (GCS) <g...@debian.hu> wrote: >> >>> On Thu, 2013-06-20 at 10:53 -0700, Randall Leeds wrote: >>> > I saw that my packaging efforts came up in the IRC meeting yesterday >>> > and I wasn't there to report. >>> > >>> > Here's what's done: >>> > - Split the packaging into couchdb and couchdb-bin as Ubuntu did >>> downstream >>> Will check why it makes sense. >>> >>> > You can try it by installing git-buildpackage, cloning the pkg-couchdb >>> > repository, using git-dch to create a new debian/changelog entry for >>> > 1.3.1, and running git-buildpackage. >>> Please note that previously I couldn't build couchdb 1.3.0 . The Erlang >>> version in the Debian archives is (was?) too new for it. Hope it's >>> solved with 1.3.1 then. Even if I was forcing it to build, Futon was >>> failing due to some incompatibility between Erlang versions. Is it still >>> supported? >>> >>> > Here's what remaining to be done, based on my notes from previous >>> > conversations with Laszlo and others: >>> > - Use system libyajl-dev >>> > - Use system libspeedy-dev >>> > - Use system libjs-json >>> > - Use system libjs-coffeescript >>> > - Publish to dist.apache.org >>> > >>> > The first 4 are Debian policy issues. >>> Sure, it should be a policy for everyone. Meaning don't do code >>> duplication but use the ones from the system. If one has a security fix, >>> then it's fixed for all dependent applications. But if someone embeds >>> them and those don't get the security fix, you will remain affected. >>> Sometimes blindly, as you may not realize that the application contains >>> other libraries. >>> >>> > Laszlo: If you already have a repo for this work anywhere that you >>> > would prefer I use I would be glad to collaborate there. >>> Not yet, but we can discuss it in private. >>> >>> On Thu, 2013-06-20 at 14:33 -0700, Randall Leeds wrote: >>> > In the case of the Debian packaging, I'd like to not have it in the >>> > main source tree, since that creates pain if downstream packagers >>> > decide to diverge from our way of doing it. >>> It's not a problem for me. The 'new' source package format (3.0 ie >>> quilt) works this around. Easily as it gets the upstream tarball, >>> unpacks it and deletes debian/ from the tree and applies my debian/ >>> subdir. Thus I don't even see if upstream has debian/ or not. >>> >>> Laszlo/GCS >>> >>> >> >> >> -- >> NS
