+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
