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
+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
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
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
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:
- Imported the most up-to-date .dsc from unstable using git-buildpackage tools
- Imported the rc.2 release tarball that passed vote
- Updated to use the virtual libcurl-dev,
On 20 June 2013 19:53, Randall Leeds randall.le...@gmail.com 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:
- Imported the most up-to-date .dsc from unstable using git-buildpackage
tools
- Imported the rc.2
On Thu, Jun 20, 2013 at 2:02 PM, Dave Cottlehuber d...@jsonified.com wrote:
I'd like to merge my windows build scripts into couchdb proper (I will
open a JIRA for that), and during the release process, we currently
stash binaries / packages into svn
