I created the PR https://github.com/apache/couchdb/pull/3503
The first set of commits remove and cleanup applications, settings and url handlers. Then, the rest of the commits focus on fixing the functionality to adjust for the removal: updating include paths, switching to use the newer couch_views utility modules, and making sure couch unit tests run. For couch_server, I had started to replace it but, since it's called in quite a few places and the PR was getting quite large, I stopped with just pairing it down to the minimal functionality. I tried to add descriptive commit messages for some issues encountered. The tricker one is probably where couch_views is updated with utility functions from the old couch_mrview and couch_index applications. Thanks, -Nick On Tue, Apr 13, 2021 at 11:03 AM Paul Davis <paul.joseph.da...@gmail.com> wrote: > > Another +1 to removing as much as possible and building back anything > that we feel is appropriate for main. > > On Mon, Apr 12, 2021 at 1:31 PM Robert Newson <rnew...@apache.org> wrote: > > > > +1 to all the proposed cuts. > > > > I’m keen to see couch_server.erl itself go, so its remaining uses need new > > homes (couch_passwords an obvious choice for the hashing referred to, etc). > > > > I’m inferring that neither purge and global_changes work on main anyway, > > but they can still be called and will route to 3.x code. Agree that it’s > > better to stub those out (send a 503 I guess?) in the short term and either > > re-implement on FDB or (as Joan said) vote on their permanent removal. > > (Noting that a much better implementation of purge and global_changes seems > > possible with FDB though less clear if the effort is justified). > > > > So, in brief, remove absolutely all the obsoleted, unreachable code as soon > > as possible, then once the dust has settled we can see if there are obvious > > gaps we should fill in before the 4.0 release. > > > > B. > > > > > On 12 Apr 2021, at 18:51, Nick Vatamaniuc <vatam...@gmail.com> wrote: > > > > > > The current versions of those apps rely on mem3, clustering, adding > > > nodes, etc and they will trail behind the 3.x versions since > > > developers wouldn't think to port those updates to main since they are > > > simply non-functional there. Most of those apps have to be re-written > > > from scratch and it would be better to start from the recent working > > > versions on 3.x. The tests for those apps don't really fail as we get > > > green builds on PR branches to main. We simply don't run them at all > > > and only run a subset of applications (fabric, couch_jobs, couch_views > > > and a few others). > > > > > > Don't think this is about a 4.x release per-se. This is mainly about > > > cleaning up, reducing the cognitive load of anyone jumping in trying > > > to work on main and seeing applications and endpoints calling into > > > non-existing applications. > > > > > > -Nick > > > > > > > > > -Nick > > > > > > On Mon, Apr 12, 2021 at 1:13 PM Joan Touzet <woh...@apache.org> wrote: > > >> > > >> 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 > > >>> better to remove them from main as we'll have them on the 3.x branch > > >>> they'll be recent (working) there. When we're ready to fix them up, we > > >>> can copy that code from there to the main branch. > > >> > > >> If the intent is to release 4.0 with them, then I would suggest keeping > > >> them there and allowing their tests to fail so we know that a "failing > > >> main" means that the product isn't ready to release yet. > > >> > > >> If we are pushing these out past a 4.0 release, then that decision needs > > >> to be made formally. > > >> > > >> Parenthetically, we try to avoid "code owners" here, but usually fixes > > >> to couch_peruser and setup fall to Jan, while purge and global_changes I > > >> *believe* have generally been made by IBM/Cloudant. > > >> > > >> -Joan "not sure main is ready to be called 4.0 yet anyway" Touzet > >
