Re: Couchdb package

[Raphael Hertzog <hertzog@debian.org>]

Hi,

On Mon, 18 Jan 2010, Sam Bisbee wrote:
> stuff (some of which I simply "saw the light" on). I'm going to take out the
> weight of text from this thread and put together what I'm planning on doing
> based on this thread and my discussion with Paul. 
> 
> The changes:
>   - Split the existing package into three packages:

Thanks!

> However, addressing the piuparts init script issues and getting stable upgraded
> is still my first (read: huge) priority. I'm hoping to have a patch this week
> and will work on this splitting after that.

Fine for me. The work is already done anyway, it's mostly a matter of
merging it and Elliot has proposed to do it for you.

I'll still comment on your last mail.

On Mon, 18 Jan 2010, Sam Bisbee wrote:
> > Even if I accepted your premise that Debian maintainers must not diverge
> > from upstream behavior in the process of integrating the software into
> > Debian (which I do not), 
> 
> That's very interesting to me. I base my premise on the idea that we should be
> providing packages that act like they do upstream. It also has the benefit of
> making it easier to work with upstream on issues, instead of beating around the
> differences between upstream's and our releases. No, splitting the packages
> as proposed isn't a "big" fork, but the per-user configuration would still be a
> fork.

Using a software in a different configuration is not a fork even if that
configuration is not the default one.

> Side note: I'm all for developing new features under our roof, but I think they
> should be sent upstream instead of auto-included (vs. bug fixes). I'm supposed

The new feature is called "desktopcouch" and not "couchdb". It's not a
fork it's a external companion project.

> to be packaging/maintaining the software that upstream builds, and not adding
> features for the fun of it (especially when we have a very active upstream that
> welcomes contributions, as opposed to a dead project or closed off dev team).
> Please let me know if I'm off in this view.

My 10 years of Debian experience as DD still tell me that you're mostly off in this
view. Right, we're not adding features for the fun of it, but we
regularly do when we have good reasons:
- for example, we change the default upstream layout for python modules
  for various reasons
- we split packages so that they can be used in contexts that are not
  necessarily envisioned by the upstream developers
- we allow combinations of software that are not necessarily
  endorsed by upstream, simply because some users are requesting it

Of course, depending on the package maintainer, those changes are not
coordinated the same way:
- some will prefer discussing the change with upstream first (you're
  likely in that category)
- some will do the change first and then submit it (they prefer having a
  working patch to show)
- some will do change and never submit it (for good or bad reasons, it
  depends: some upstreams do not understand the needs of distributions and
  will not be cooperative, some are but the DD has no time/interest)

But in general, we rarely block reasonable requests coming from other
package maintainers that need a small change. The difficulty lies in the
evaluation of what's reasonable and what's not, but here it seems pretty
obvious that the split was reasonable.

> I'm not debating that distros should modify the package to best fit in their
> distro (ie., Debian-ization). However, I don't see any technical reason to do
> so that would make the program run more naturally with Debian (a Debian-ization
> unrelated feature request is being made that doesn't fix anything). 

Given that desktopcouch will be part of Debian, debianization includes
better integration with desktopcouch.

> I'm also not keen on officially supporting a change that IMHO isn't well
> thought out and that upstream doesn't support. If people want per-user
> instances, then it's going to require more than just splitting out files into
> different packages. 

That's wrong obviously, desktopcouch exists and provides that. Nothing
more required currently.

> I also believe that having one instance of CouchDB that can handle database
> permissions based on system accounts is a better solution to providing per-user
> functionality via per-user instances due to its ease of administration, which
> is why I proposed attacking this with an auth module.

That solution is certainly nicer in a server context. Feel free to work in
that direction. However desktopcouch has a valid use case for the
"desktop" and with a per-user configuration, we might end up with 2-3
instances running on the machine if several sessions are opened in
parallel. Nothing to worry about.

> 
> > You may decide that the policy Elliot et al. have proposed is or isn't the
> > correct one for Debian to adopt, but if you're unwilling to even *consider*
> > the question because "it's not upstream", I don't think you're fulfilling
> > your responsibilities as a Debian package maintainer.
> 
> I think my reply rate and types of replies show that I continue to consider the
> question. Please let me know if you don't think that's the case, as I would be
> interested to see where I sniped, didn't consider technical details (different
> than disagreeing with technical points), or whatnot as I don't think I did any
> of those things and have been open through this whole discussion.

You were keen on imposing a new technical design that shall replace an
existing working solution when the only thing that was asked is: "do you
have a good technical reason to object to the split".

And the answer should have been "No the split is sane: it's
backwards-compatible, people who have couchdb keep the system-wide
service".

Cheers,
-- 
Raphaël Hertzog