As an alternative, Bob Supnik's "classic" version continues to release -
version 2.12-2 just released 25 April 2022 - and would be an excellent
replacement. http://simh.trailing-edge.com/
Unfortunately, that version still must overcome the licensing issues
outlined in Debian bug #824883.
As an alternative, Bob Supnik's "classic" version continues to release -
version 2.12-2 just released 25 April 2022 - and would be an excellent
replacement. http://simh.trailing-edge.com/
Unfortunately, that version still must overcome the licensing issues
outlined in Debian bug #824883.
Package: simh
Version: 3.8.1-6.1
Severity: serious
Tags: upstream
Justification: Policy 2.1
Dear Maintainer,
Upstream has added licensing information that is both inaccurate as well as now
violates the terms of the DFSG.
Specifically:
Package: simh
Version: 3.8.1-6.1
Severity: serious
Tags: upstream
Justification: Policy 2.1
Dear Maintainer,
Upstream has added licensing information that is both inaccurate as well as now
violates the terms of the DFSG.
Specifically:
their example not work?
On 10/03/2022 04:38, Gavin McDonald wrote:
Hi Joan.
On Thu, Mar 10, 2022 at 10:01 AM Joan Touzet wrote:
Try something like:
https://gist.github.com/mak3r/3f05c9d4f6f46d24d99bcfa4ac33
I think you need vagrant.
yeah I have that.
What I am doing is creating an AMI
Try something like:
https://gist.github.com/mak3r/3f05c9d4f6f46d24d99bcfa4ac33
I think you need vagrant.
On 2022-03-10 3:40 a.m., Gavin McDonald wrote:
> Hi All,
>
> docs are failing me.
>
> I have packer currently outputting an aws type .box file
>
> I would like to have that opened in
://lists.apache.org/thread/66hhhn2t3mx7mg2j9ls4656ngl7j3n0h
HTH,
Joan
On 17/11/2021 08:31, Adam Kocoloski wrote:
On Nov 17, 2021, at 12:22 AM, Joan Touzet wrote:
Do we really think these apps are going to have a lot of churn and need a lot
of releases?
I could see `erlfdb` needing a regular release
>> Do we really think these apps are going to have a lot of churn and need a
>> lot of releases?
>
> I could see `erlfdb` needing a regular release cadence, but I’m willing to
> see what can be done to comply with the ASF regulations in a semi-automated
> way. The other repos we’ve been
On 16/11/2021 17:53, Joan Touzet wrote:
On 16/11/2021 16:08, Nick Vatamaniuc wrote:
As for voting for making these proper releases, I am not really
looking forward to the SVN pushes, signing, checksumming, and
collecting votes for these deps.
Scriptable, shouldn't be hard if someone has time
On 16/11/2021 16:08, Nick Vatamaniuc wrote:
As for voting for making these proper releases, I am not really
looking forward to the SVN pushes, signing, checksumming, and
collecting votes for these deps.
Scriptable, shouldn't be hard if someone has time.
Especially for a NIF with just 2
On 12/11/2021 08:40, Jan Lehnardt wrote:
My post is from just going through the README. Since then I found the separate
SM60 README, but haven’t acted on it just yet.
I see no notes for esr68, if you have anything, even temp commits, I’d take
them :)
Sorry, I must have aborted trying esr68,
Onto SpiderMonkey, any ideas for this:
DEBUG: configure: error: Library requirements (icu-i18n >= 59.1) not met;
consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are
in a nonstandard prefix so pkg-config can find them.
Setting PKG_CONFIG_PATH to
On 3. Nov 2021, at 08:07, Joan Touzet wrote:
Hello there,
Sorry, I'm unavailable to help test and vote on releases.
I took notes during the 3.2.0 release as to what was needed to do the binary
releases without me. Someone from the PMC, specifically, should pick this up
for now.
https://gist.g
Hello there,
Sorry, I'm unavailable to help test and vote on releases.
I took notes during the 3.2.0 release as to what was needed to do the
binary releases without me. Someone from the PMC, specifically, should
pick this up for now.
On 29/10/2021 09:52, Adam Kocoloski wrote:
Ah! That .asf.yaml configuration is neat, thanks for pointing it out.
Good point on the source releases — do you have anything in particular in mind
when you talk about making it simpler for the community at large?
Sorry, that . should be a , :
On 28/10/2021 16:44, Adam Kocoloski wrote:
I think we could benefit from making these projects more visible. Paul’s jiffy library for JSON processing is a nice counterexample where he's gotten non-trivial contributions from the broader Erlang community by putting a little distance between it and
Tested on Windows 10. Checksums match. Signature OK but still needs
web-of-trust:
-
gpg: assuming signed data in 'apache-couchdb-3.2.0-RC2.tar.gz'
gpg: Signature made 05/10/2021 15:21:31 Eastern Summer Time
gpg:using RSA key 0BD7A98499C4AB41C910EE65FC04DFBC9657A78E
gpg: Good
e build yet. So this is going to take more doing than I can do
quickly.
Will look at more after I get some sleep.
>
> -Nick
>
>
> On Tue, Sep 28, 2021 at 8:02 PM Joan Touzet wrote:
>>
>> Unfortunately, I must vote -1 for 3.2.0. On Windows, I cannot compile
>&
Unfortunately, I must vote -1 for 3.2.0. On Windows, I cannot compile
the Jiffy we are including in 3.2 anymore due to a linking error:
> LINK : fatal error LNK1181: cannot open input file 'erl_interface.lib'
This is the same system that just finished compiling and testing 3.1.2,
no other
;,"pluggable-storage-engines","reshard","scheduler"],"vendor":{"name":"The
Apache Software Foundation"}}
+1
>
> Regards,
> -Nick
>
> On Mon, Sep 27, 2021 at 8:36 PM Joan Touzet wrote:
>>
>> Nick, that diff sh
Nick, that diff shows documentation only. Something seems wrong with
this release.
Recommend we hold the vote until this can be cleared up?
-Joan
On 27/09/2021 08:53, Nick Vatamaniuc wrote:
> Dear community,
>
> I would like to propose that we release Apache CouchDB 3.1.2
>
> Changes since
I have seen it work this way myself with these two applications. Whoever
starts first starts epmd, and the second sees epmd running on startup
and simply connects to that.
-Joan
On 15/07/2021 10:10, Adam Kocoloski wrote:
> That’s typically how it works for a well-behaved Erlang application, yes.
In general I am +0.5 on the entire thing, but would like to see Bob
Newson or Paul Davis speak up. In the past they've been the most vocal
about code formatting standards, and I'd at least like to see a +0 from
both of them.
-Joan
On 20/05/2021 11:53, Ilya Khlopotov wrote:
> Good idea Donat!!!
be such an
ass." It is entirely possible for you to seek the help you need
regarding httpd, but everything you have shown to date suggests you are
the problem here, not the members of the users@httpd.apache.org mailing
list.
Best regards,
Joan Touzet
[1]: https://github.com/wpeterson/emoji/iss
Hello everyone,
As announced on Twitter this morning[1], our Linux binary repositories
have moved over to JFrog Artifactory. The raw URLs for the repos are now:
https://apache.jfrog.io/artifactory/couchdb-deb/
https://apache.jfrog.io/artifactory/couchdb-rpm/
All binaries at the old
Hello everyone,
As announced on Twitter this morning[1], our Linux binary repositories
have moved over to JFrog Artifactory. The raw URLs for the repos are now:
https://apache.jfrog.io/artifactory/couchdb-deb/
https://apache.jfrog.io/artifactory/couchdb-rpm/
All binaries at the old
When Tony's PR to 3.x is working, we'll merge it. Should be in time.
https://github.com/apache/couchdb/pull/3506
On 17/04/2021 16:42, yhilem wrote:
> Hi,
>
> If possible add Prometheus (https://github.com/apache/couchdb/pull/3416).
>
> Thanks
> Youcef HILEM
>
>
>
> --
> Sent from:
On 14/04/2021 13:05, Mick Semb Wever wrote:
>> Then it is easy to use our own Jenkins-stored creds
>>
push downstream
* Update all of the documentation to indicate the new URLs
* Announce the change on user@, twitter, etc.
This needs to happen in the next two weeks, and ideally before April
26th (the next "brown-out" day).
-Joan
On 12/04/2021 12:54, Joan Touzet wrote:
> Hello again,
Hey, thanks for your patience on this topic.
About 7 months ago, ASF Infra told us that we were allowed to put our
containers inside of the "apache" Docker Hub organization. We just got
permission for that a few days ago. There's two main reasons this is
good: first, ASF Infra can manage write
On 07/04/2021 07:43, Mick Semb Wever wrote:
>>
>> My understanding is that pulls of all images from the apache/* namespace
>> are not subject to rate limiting. Thus, the recommendation to move
>> everything you need inside of it.
>>
> As >95% of our CI docker commands are pulls from apache/
Generally +1 with one major reservation:
On 12/04/2021 12:25, Nick Vatamaniuc wrote:
> * Some applications we want to have in main, but the way they are
> implemented currently rely completely or mostly on 3.x code: purge
> logic, couch_peruser, global_changes, setup. I am thinking it may be
>
nstall our packages today between 6AM
and 2PM Pacific Daylight Time.
I'm accelerating efforts to move to the new system with Infra's help,
and will be focused on this work this week.
-Joan
On 28/03/2021 13:00, Joan Touzet wrote:
> Hello everyone,
>
> ASF Infra has once again come th
nstall our packages today between 6AM
and 2PM Pacific Daylight Time.
I'm accelerating efforts to move to the new system with Infra's help,
and will be focused on this work this week.
-Joan
On 28/03/2021 13:00, Joan Touzet wrote:
> Hello everyone,
>
> ASF Infra has once again come th
Hi Gavin, any updates? We need to do a release and get our
documentation/external references updated. I tried pinging you on IRC
twice, but no response.
-Joan
On 28/03/2021 12:49, Joan Touzet wrote:
> Thanks Gavin. I know this couldn't have been an easy task. Looking
> forward to th
On 06/04/2021 18:09, Mick Semb Wever wrote:
>>
>>> Has anyone experience with such issues before?
>>
>> Yes. See https://issues.apache.org/jira/browse/INFRA-20795 for detail.
>>
>> In short, once Infra agrees to create the images for us, we'll move all
>> our CI dependencies into those containers,
Hi Mick,
On 06/04/2021 06:34, Mick Semb Wever wrote:
> tl;dr
> Can and should all jenkins agents be (automatically) docker authenticated,
> for improved stability around docker commands?
>
>
> This past week the ci-cassandra.apache.org CI fell over because a fair
> percentage of docker pulls
hard time, and start making concrete plans (and
dedication of people) to avoid a similar trajectory.
-Joan
>
> [1]: https://www.jetbrains.com/lp/python-developers-survey-2020/
> [2]: https://www.tiobe.com/tiobe-index//
>
> On Tue, Mar 30, 2021 at 7:20 PM Joan Touzet wrote:
>>
>&g
> updating for such a change and when do we get to drop previous
> versions of the API?
I'd like to see this too.
> Thank you,
> Donat
>
> On Mon, Mar 29, 2021 at 6:28 PM Joan Touzet wrote:
>>
>> On 22/02/2021 20:48, Adam Kocoloski wrote:
>>> Hi al
elease notes: I'm really _not_ good with docs, so I'm happy there's
>> someone who's doing that.
>>
>>
>> Donat
>>
>> On Sun, Mar 28, 2021 at 9:20 PM Joan Touzet wrote:
>>>
>>> Great! Excited to get help.
>>>
>>> Here's the release p
On 22/02/2021 20:48, Adam Kocoloski wrote:
> Hi all,
>
> Several times in recent months we’ve had discussions on this list about
> behavior changes in CouchDB 4.0 that boil down to tradeoffs between
>
> a) maintaining compatibility with current CouchDB APIs, and
> b) capitalizing on the
I did look at "Prospective ASF mentors: read this" of [1], but I don't
> see what it looks like for a project. Do we need a vote here?
>
>
> Donat
>
> [1]: https://community.apache.org/gsoc.html
>
> On Sun, Mar 28, 2021 at 11:52 PM Joan Touzet wrote:
>
The ASF often ends up doing GSoC. I don't think we've ever had the
sponsor within the project for it (or for Outreachy, for that matter).
The most critical part is being available on a regular basis for proper
mentoring. If you don't think you can get that into your schedule, don't
volunteer.
Hey everyone, I'm overdue to post these:
https://gist.github.com/wohali/78c14c9afa317bf665854d55ad1e70ed
In short, our Docker downloads went up by ~20 million, and everything
else held steady or decreased slightly. The biggest decline in downloads
was our source tarball, down almost 70%.
One
+1
>
> Let me know how I can help.
>
>
> Donat
>
> On Sun, Mar 28, 2021 at 7:03 PM Joan Touzet wrote:
>>
>> Hi everyone,
>>
>> We have a number of high profile improvements to 3.x since 3.1.1 came
>> out. I think it's about time for 3.2. Doe
Hi everyone,
We have a number of high profile improvements to 3.x since 3.1.1 came
out. I think it's about time for 3.2. Does everyone agree?
If so, we should start a clock for ~2 weeks to finish closing out any
last minute improvements, fixes, tweaks, etc. anyone wants to get in.
-Joan "we did
again when all of this is taken care of.
Cheers,
Joan
On 01/03/2021 11:09, Joan Touzet wrote:
> Hello everyone,
>
> One month ago, we were informed that JFrog are shutting down Bintray - a
> service we currently use to host our .deb and .rpm packages for Debian
> and Ubuntu, &a
Thanks Gavin. I know this couldn't have been an easy task. Looking
forward to the info.
On 28/03/2021 11:00, Gavin McDonald wrote:
> Hi All,
>
> As advertised in [1] Bintray is closing down.
>
> We have secured a replacement for bintray, which is JFrogs more extensive
> software offering
. This will also directly affect our downstream "top-level"
couchdb Docker container.
If anyone has objections, or has alternate proposals, please speak now.
-Joan "doing the best I can" Touzet
On 14/09/2020 22:09, Joan Touzet wrote:
> Paul informs me that IBM have discontinued all
Hello everyone,
One month ago, we were informed that JFrog are shutting down Bintray - a
service we currently use to host our .deb and .rpm packages for Debian
and Ubuntu, & CentOS and RHEL respectively. (Win/Mac downloads are now
provided by Neighbourhoodie.)
New uploads to bintray will be
Hello everyone,
One month ago, we were informed that JFrog are shutting down Bintray - a
service we currently use to host our .deb and .rpm packages for Debian
and Ubuntu, & CentOS and RHEL respectively. (Win/Mac downloads are now
provided by Neighbourhoodie.)
New uploads to bintray will be
HI Donat,
Point of order - when we do 72-hour votes, it's best to not count
weekends in that 72-hours. So, since you started on the 28th at 05:00
UTC, I would have continued the vote until Feb 2 at 05:00 UTC.
That said I am +1 on this too, long overdue.
As to Eric's point, all we need to do is
e Joan. +1 to Donat’s suggestion to drop support
for 19 from me.
Adam
On Jan 22, 2021, at 4:49 PM, Joan Touzet wrote:
On 2021-01-22 4:37 p.m., Robert Newson wrote:
Iteresting. I’m actually surprised at the inversion here (that
CouchDB is dependent on IBM to confirm CouchDB’s stability). I
. I'm happy to make
the 3.3 release (or whatever is next) use the very latest version of 21
or 22 from GitHub, subject to community recommendations and
encouragement. 23 is still a WIP:
https://github.com/apache/couchdb/issues/3115
-Jon
B.
On 22 Jan 2021, at 21:19, Joan Touzet wrote
On 22/01/2021 15:48, Robert Newson wrote:
> I’m +1 on dropping Erlang 19 support. Erlang is now on major release 23.
No problem here.
> I’d further advocate a general policy of supporting only the most recent 2 or
> 3 major releases of Erlang/OTP.
>
> The main (I think only?) reason to keep
On 15/01/2021 17:51, Nick Vatamaniuc wrote:> You're absolutely right.
There are two places where job priority comes
> into play: one is when jobs are started, and then the other is when
> they are stopped. When starting jobs, both continuous and one-shot
> (normal) jobs are at the same priority.
Donat.
Donat
On Thu, Jan 14, 2021 at 10:09 PM Nick Vatamaniuc wrote:
Congrats Donat and welcome!
-Nick
On Thu, Jan 14, 2021 at 3:55 PM Joan Touzet wrote:
Congratulations Bessenyei! Do you have a nickname (other than bessbd)?
-Joan
On 2021-01-14 3:48 p.m., Robert Newson wrote:
Dear
On 2021-01-12 12:55 p.m., Nick Vatamaniuc wrote:
Hello everyone
Hi (Dr.) Nick! ;)
I wanted to see what we thought about adding a scheduling improvement
to the replicator. Specifically adding round-robin fairness amongst
different _replicator dbs
We've needed some sort of priority system
Congratulations Bessenyei! Do you have a nickname (other than bessbd)?
-Joan
On 2021-01-14 3:48 p.m., Robert Newson wrote:
Dear community,
I am pleased to announce that the CouchDB Project Management Committee has
elected Bessenyei Balázs Donát as a CouchDB committer.
Apache ID: bessbd
3.x) replicators won't be able
to replicate non-continuous (normal) changes from >= 4.x endpoints.
Regards,
-Nick
On Sat, Jan 9, 2021 at 1:26 AM Joan Touzet wrote:
Wait, what? I thought you agreed with this approach in that thread.
I withdraw my vote until I can get a clearer view. Nick wou
as well,
as described in the thread
Cheers,
-Nick
On Jan 8, 2021, at 17:12, Joan Touzet wrote:
Thanks, then it's a solid +1 from me.
-Joan
On 2021-01-08 4:13 p.m., Robert Newson wrote:
You are probably thinking of a possible “group commit”. That is anticipated and
not contradicted
for a single doc lookup, view query, etc.
On 8 Jan 2021, at 19:53, Joan Touzet wrote:
+1.
This is for now I presume, as I thought that there was feeling about
relaxing this restriction somewhat for the 5.0 timeframe? Memory's dim.
-Joan
On 07/01/2021 06:00, Robert Newson wrote:
Hi,
Following on from
+1.
This is for now I presume, as I thought that there was feeling about
relaxing this restriction somewhat for the 5.0 timeframe? Memory's dim.
-Joan
On 07/01/2021 06:00, Robert Newson wrote:
> Hi,
>
> Following on from the discussion at
>
cked. I'll look this
>> week.
>>
>> On Mon, 30 Nov 2020 at 19:01, Joan Touzet wrote:
>>
>>> Glynn, might you find time to work on this this week? I just noticed
>>> that `main` isn't protected on couchdb-documentation, which is a bad
>>> thing.
>
Glynn, might you find time to work on this this week? I just noticed
that `main` isn't protected on couchdb-documentation, which is a bad thing.
If not I'll try and do it myself.
-Joan
On 09/11/2020 12:23, Joan Touzet wrote:
> I think I just heard you volunteer to do the PRs on the repos
Hi Ilya,
I accidentally merged
https://github.com/apache/couchdb-documentation/pull/550
before realizing that it was 4.0 documentation. I'm going to revert that
now. You'll want to re-prep that PR for merging later; my suspicion is
that we will want a 3.2 or 3.1.2 release before 4.0 comes out
Hi Olaf, I don't have extensive experience with partitioned databases,
but I'm happy to provide some recommendations.
On 26/11/2020 01:48, Olaf Krueger wrote:
> Hi guys,
>
> I am in the process of preparing our docs for partitioning.
> I guess a lot of us are already using something like a
Hello yhilem,
CouchDB 4.0 isn't anywhere near a packaged release yet, or ready for
end-user testing. It is not at feature parity with previous CouchDBs.
This is why we haven't announced anything publicly.
If you're interested in helping develop along with us, you can check out
the code and run
Hi Gavin, thanks for doing this. Just yesterday these 3 URLs crossed my
desktop:
https://mailchi.mp/3d439eeb1098/travis-ciorg-is-moving-to-travis-cicom
https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
https://www.theregister.com/2020/11/02/travis_ci_pricng/
Guess I missed the
>>> https://github.com/apache/couchdb-helm - main not protected
>>> ...
>>>
>>> There are numerous others. I couldn't find an example where the main
>>> branch _was_ protected, but in most cases the old master branch was.
>>>
>>> Glyn
Yes, you'll have to file a ticket with Infra for this.
We probably need to do this on quite a few repos, which unfortunately
means that we may be forced to write a script to address it.
Would you be willing to volunteer to check and see which ones have
unprotected main branches - at least for
20 at 11:08 PM Gavin McDonald
wrote:
Hi ,
Just to note I have emailed DockerHub, asking for clarification on our
account and what our benefits are.
On Thu, Oct 29, 2020 at 6:34 PM Allen Wittenauer
wrote:
On Oct 29, 2020, at 9:21 AM, Joan Touzet wrote:
(Sidebar about the script's details)
, but it also appears to be about 1 minute
faster by skipping the download.
-Joan "time for taquitos" Touzet
On 29/10/2020 18:09, Joan Touzet wrote:
> Following up,
>
> I've implemented a new Jenkins job that re-pulls all current couchdbdev
> images on each docker node ever
r Jenkins and
click "Build Now" here:
https://ci-couchdb.apache.org/job/jenkins-cm1/job/Update%20Docker%20Containers/
which forces the image removal and re-pull.
I hope this is enough to avoid any rate limiting problems.
-Joan "Gir, stop singing this instant!" Touzet
On 2020
On 2020-10-29 11:37 a.m., Allen Wittenauer wrote:
On Oct 28, 2020, at 11:57 PM, Chris Lambertus wrote:
Infra would LOVE a smarter way to clean the cache. We have to use a heavy
hammer because there are 300+ projects that want a piece of it, and who don’t
clean up.. We are not build
fauxton and documentation as well, but will lay down a tag if
necessary to solve the problem there.
I've applied the tag as mentioned.
-Joan
On 2020/10/29 14:32:17, Joan Touzet wrote:
Hi Ilya,
Sorry about this trouble. Based on this feedback I will not pursue
removal of our release branches
Hi Ilya,
Sorry about this trouble. Based on this feedback I will not pursue
removal of our release branches.
On 2020-10-29 5:56 a.m., Ilya Khlopotov wrote:
❯ git describe --always --tags
archive/prototype/fdb-layer-get-doc-spans-580-gdfb27b48a
but:
$ git checkout 3.x
Branch '3.x' set up
I just posted about this on the ASF-wide bui...@apache.org list:
https://lists.apache.org/thread.html/r5ccf60da8072b3c2b587152256ebaf6a0e7b81182d5e240a2b2a0f02%40%3Cbuilds.apache.org%3E
TL;DR: We're not immune, even with our build machines, and the new
limits kick in Monday.
We can remove some
Got your attention?
Here's what arrived in my inbox around 4 hours ago:
> You are receiving this email because of a policy change to Docker products
> and services you use. On Monday, November 2, 2020 at 9am Pacific Standard
> Time, Docker will begin enforcing rate limits on container pulls
:59, Jan Lehnardt wrote:
> *makes chain saw noises*
>
> (trimming branches, get it?)
>
> Thanks Joan!
>
> Best
> Jan
> —
>
>> On 21. Oct 2020, at 20:23, Joan Touzet wrote:
>>
>> I am starting the work now. As there was no response, I'm going
have been re-targeted to main (except a couple clustering-specific ones
which were set to 3.x). Please check if this is correct for your PRs.
-Joan "clean all the things?" Touzet
On 14/10/2020 13:19, Joan Touzet wrote:
> A reminder about this: I intend to start this work tomorrow
Hi Jarek,
On 16/10/2020 05:45, Jarek Potiuk wrote:
> Joan - I hope you are back and we can continue the discussion.
Sorry, I just don't have the time or the energy to carry this further.
I only brought up OO because it was one of the outliers, and the first
"user application" that came to
A reminder about this: I intend to start this work tomorrow. If you have
any PRs or branches you want left alone, speak now.
Based on feedback I've received, it sounds like the prototype/fdb-*
branches are now done? If this is **NOT** the case, speak up.
-Joan
On 07/10/2020 18:10, Joan Touzet
By agreement of the PMC and a lazy majority of committers, the default
git branch is now `main` for all of our repositories.
If you have any pending PRs, please be sure to re-target them to this
branch. For any new PRs, be sure to branch off of main for 4.x work. The
3.x branch is unaffected.
On 13/10/2020 11:48, Robert Samuel Newson wrote:
Hi All,
As part of CouchDB 4.0, which moves the storage tier of CouchDB into
FoundationDB, we have struggled to reproduce the full map/reduce functionality.
Happily this has now happened, and that work is now merged to the couchdb main
branch.
Thanks to our CloudBees contact, we now have some new Jenkins functionality:
1. You can now retrigger a PR Jenkins build by posting the
comment "jenkins rebuild" to your PR. (This may or may not be a regex
match.) You can still retrigger a Jenkins build by updating your PR.
2. Full build
And to add to this, with the Blue Ocean UI for Multibranch Pipeline, it
is a single click to rebuild a build. It's not as friendly as
commenting, but it's a single button on the results view for your build,
which is linked right from the PR.
Of course, this is limited to only people who have
Hi Alex, nice to see you!
On 08/10/2020 04:57, Alexander Shorin wrote:
+1, but...
Old release branches could be just dropped without a worry. If something
there wasn't released since today - well, nobody actually has any need for
it. If someone does - make a release, tag it and drop the
Hi there,
I'd like to clean up our branches in git on the main couchdb repo. This
would involve deleting some of our obsolete branches, after tagging the
final revision on each branch. This way, we retain the history but the
branch no longer appears in the dropdown on GitHub, or in git branch
format for _metrics endpoint. In order to be compatible
with many monitoring tools, what about going with Prometheus standard format
first and we may add JSON format support later?
Best regards,
Peng Hui
On Sep 23, 2020, at 9:41 AM, Joan Touzet wrote:
I like this, but not at the expense
I like this, but not at the expense of JSON output. It would be the only
new API surface for CouchDB that isn't JSON-based, and there needs to be
excellent justification for such. Prometheus is well-known enough to be
supported, but we should continue to put out JSON stats for the
foreseeable
Dear community,
Apache CouchDB® 3.1.1 has been released and is available for download.
Apache CouchDB® lets you access your data where you need it. The Couch
Replication Protocol is implemented in a variety of projects and
products that span every imaginable computing environment from
Dear community,
Apache CouchDB® 3.1.1 has been released and is available for download.
Apache CouchDB® lets you access your data where you need it. The Couch
Replication Protocol is implemented in a variety of projects and
products that span every imaginable computing environment from
Dear community,
Apache CouchDB® 3.1.1 has been released and is available for download.
Apache CouchDB® lets you access your data where you need it. The Couch
Replication Protocol is implemented in a variety of projects and
products that span every imaginable computing environment from
Dear community,
Apache CouchDB® 3.1.1 has been released and is available for download.
Apache CouchDB® lets you access your data where you need it. The Couch
Replication Protocol is implemented in a variety of projects and
products that span every imaginable computing environment from
For those who want to get a jump on things, Linux binary packages and
the apache/couchdb docker image are now available, and this has been filed:
https://github.com/docker-library/official-images/pull/8745
-Joan "all on a Thursday" Touzet
On 17/09/2020 17:29, Joan Touzet wr
/3.1.html
You can track the status of the Apache mirror system here:
https://www.apache.org/mirrors/
Please make any necessary preparations.
Thanks,
Joan Touzet
P.S. I've lost access to the Symantec/Digicert code signing service for
Windows installers again, so the Windows installer
Dear community,
The vote has now closed.
Thank you to everyone who participated!
The results are:
+1 - 4 votes
+0 - 0 votes
-0 - 0 votes
-1 - 0 votes
The vote is PASSED.
Thanks,
Joan
On 11/09/2020 18:53, Joan Touzet wrote:
Dear community,
I would like to propose that we
env, but I’ll look for a repro then.
Best
Jan
—
On 12. Sep 2020, at 00:53, Joan Touzet wrote:
Dear community,
I would like to propose that we release Apache CouchDB 3.1.1.
Changes since the last round:
https://github.com/apache/couchdb/compare/3.1.1-RC1...3.1.1-RC2
Candidate release
On 16/09/2020 11:39, Paul Davis wrote:
On Wed, Sep 16, 2020 at 10:32 AM Joan Touzet wrote:
On 16/09/2020 10:57, Paul Davis wrote:
Hey all,
Here's a list of all CouchDB related repositories with a few quick
stats and my read on their status and requirements. Can I get some
eyeballs
1 - 100 of 1602 matches
Mail list logo
