Roger that,
over and out.
Johs
> On 8 Jul 2018, at 17:58, Jan Lehnardt <j...@apache.org> wrote:
>
> There might be a misunderstanding of what is required to keep 1.x from being
> deprecated.
>
> It is not a detailed plan, lengthy discussion, or request for features or
> extended support.
>
> It is people spending the time in the code and issues to prepare branches
> that they then produce release candidates of. The changes and issues triaged
> can be bugfixes and security fixes.
>
> Until the people who end up doing this, do not materialise, there is little
> sense in further discussions, as merely making requests for work and not
> putting in the work are a decent waste of everybody’s time.
>
> Note how number of users/downloads/etc doesn’t factor into the above.
>
> But while we are at it, from 75 responses to the CouchDB survey so far, we
> have about 30% 1.x users. That’s down from ~70% in the 2017 survey (of 130
> people). Note that multiple answers were possible, so the 1.x operators might
> also run 2.x.
>
> Those numbers and the trend along with everything else, I’m confident in
> deprecating 1.x. 1.x is a fine piece of software and existing installations
> of it will continue to run just fine, but this project is moving on.
>
> Best
> Jan
> —
>
>> On 8. Jul 2018, at 14:59, Johs Ensby <j...@b2w.com> wrote:
>>
>> 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
>>
>
