couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Kowalski <>
Subject Re: Let's cut a Nano release
Date Tue, 11 Aug 2015 10:21:07 GMT
Hey Jason,

thanks for bringing this up again! Really appreciated!

1. cool!

2. For Fauxton we just use the "Component" field in Jira. Do you mean
setting up a whole new Jira (e.g. CouchDB, Cassandra) or setting up a
subcomponent. The latter is easy, just type in the new component name when
creating a ticket.

3. Can you chime in at [1] ? Can you open the link? I basically asked infra
if we can have Github issues enabled in all our subprojects and if they can
migrate nano for us together with issues, wiki, closed/open/prs etc. If you
can not open the link, please ping me!

5. Yes I think we still need votes for an official apache release. Yes, I


On Tue, Aug 11, 2015 at 8:13 AM, Jason Smith <>

> Hi, dev@. And hi, Johannes (hope you see this).
> Last month, you asked what to do about releasing Apache Nano (or Apache
> CouchDB Nano, or whatever its name is).
> I would like to get involved in that effort, and to help push it forward.
> Nuno and the team graciously donated the project to the ASF. I know that
> much. Here are some open questions I feel remain.
> 1. There are still commits going into although only
> Johannes so-far. I will submit a pull request to dscape to update the
> README to point to the ASF project.
> 2. We have no JIRA project for it. May I get involved in creating that? Any
> tips?
> 3. We have no issue tracker in GitHub either. For me, I would personally do
> what I once learned from Jan ("collect feedback from customers where they
> are"). So I would like to have github issues if possible? Any way I can
> help?
> 4. What about publishing to npm? IMO, le mieux, c'est l'ennemi du bien, I
> am happy asking Johannes to prepare a Git tag, then ask Johannes to `git
> pull; git checkout; npm publish`. And then we can sort out the "real" fix
> later, yeah?
> 5. What about publishing outside of npm? Must we still cut the release
> artifacts, and have the VOTEs? My feeling is, the vote is proper and
> useful, but the release artifacts are largely useless, given the ubiquity
> of npm in the Node.js community.
> Thanks, all!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message