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
