Thanks Joan,
Your take on the data is
> To me the data is more proof that asking to keep 1.x on a lifeline is
> serving a vanishingly small amount of users.
I see no proof in the data and I disagree with respect how to best go about
"serving a vanishingly small amount of users."
My take on the data is guesswork, but I would love to see someone tare it down
with data:
1) Millions have played with CouchDB (we are now left with a vanishingly small
amount of these)
2) Tens of thousands of servers are running with CouchDB today
(20 000+ downloads of 2.x for Debian/Ubuntu/CebtOs/RHEL over a year
indicate intention to upgrade, however, not actual upgrade)
3) Average 100+/day downloads of 2.1.1 is another indicator of upgrade activity
being strong.
4) Thousands of sysops/sysdevs have CouchDB 1.x as part of their stack, they
have not been heard in this discussion yet
5) Regarding developer activity and experimentation, the spikes connected to
releases are interesting:
-- 2,237 downloads of 1.7.1 for Windows on the same day early January is a
significant spike that I don't know the background for.
-- Spikes for 2.x on Mac indicate 600-900 active Mac-using developers, but we
don't know much about the sysops' plans to upgrade
Regarding my offer to write a paper to make a case for keeping 1.x open you said
>>> Thanks for the offer. Before writing up a full paper, what would
>>> your first 3 acts be?
I thought you wanted me to hold my horses and do this step by step
It would be a bit akward to start discussing the point 2-3 until having feeback
on my intentions.
Should I proceed to point 1?
I still think your proposal, as it was "tabled" had been better without the
first what-it-means-point, which is a far-reaching decision with unclear
benefit.
Also, I think the result of the recent user survey should be published to
support the decision making.
Johs
> On 7 Jul 2018, at 19:18, Joan Touzet <woh...@apache.org> wrote:
>
> Johs Ensby wrote:
>> Thanks for this, Joan
>>
>> You must have put a lot time and effort into this and it is _highly
>> appreciated_.
>
> You're welcome.
>
>> The "official" https://www-us.apache.org/dyn/stats/couchdb.log seems
>> like a
>> nice place to follow the trend.
>
> For a limited amount of data, compared to how popular the binary
> distributions from bintray.com are, yes.
>
> If Infra is able to give us access to the archived closer.lua data,
> we should be able to get a better picture of relative popularity,
> at least for people who click through https://couchdb.apache.org/ to
> download the tarball.
>
>> What is in second column, download
>> time?
>
> The script that generates the file is at:
>
> https://svn.apache.org/viewvc/infrastructure/site/trunk/content/dyn/closer.lua?view=markup
>
> That field is generated on line 464, which is grabbing the final octet
> of the IP address for uniqueness. This can help de-duplicate data, or
> look for "ballot-stuffing" by someone trying to make one download or the
> other look more popular. ;)
>
>> Although it is hard to compile totals out of this, the fact that the
>> numbers are
>> small is a fact.
>
> Again, compared to the binary downloads. Including the Docker downloads
> (which do not separate by version #, which is why I haven't included them
> in my email) there are 30+ million downloads of CouchDB in the wild.
>
> To me the data is more proof that asking to keep 1.x on a lifeline is
> serving a vanishingly small amount of users.
>
>> Lost of upside and few people to deal with as the
>> base,
>> which means that anyone who value CouchDB today can make a huge
>> impact, relatively speeking.
>
> In terms of people making a large impact, it's more about the total
> number of contributors and committers to the project. As a PMC member,
> I want to see more contributors and committers who are interested in
> making CouchDB better, not in publicity hounds who just want to pad
> their resume by working on a high-profile OSS project. (Not pointing
> fingers at you, just thinking out loud.)
>
>> Thanks also for this response:
>>> Thanks for the offer. Before writing up a full paper, what would
>>> your
>>> first 3 acts be?
>> 1) State my intentions, for feedback
>> 2) Table my case for a 1.x branch with limit scope, again for feeback
>> 3) Table an outline
>
> In terms of 1.x scope, my first choice is to end support for it.
> Every single committer has voted +1 on this proposal so far; only you
> and one other dev have cast non-binding votes against it.
>
> If there is sufficient interest to continue with 1.x, the primary
> need is for someone to maintain it for security patches only. This
> would need to be established committer(s) on the project who would
> be available rapidly to patch and spin new releases if and when any
> security issues are raised by external reporters confidentially.
>
> If there's even more interest beyond that, then the only scope
> I can see is for bug fixes based on GitHub issue tracker posts, or
> at the very most, back ports of any 2.x features or changes that
> will make the migration to 2.x easier. This might include many
> deprecation warnings we talked about at one point.
>
> I don't want to see branched development on 1.x that adds new
> 1.x-only features, or back ports of major new 2.x functionality
> like Mango or clustering.
>
> I don't speak for the rest of the PMC on this.
>
> -Joan
