Re: Approval request for updating www/php-nextcloud to 29.0.2

[Greg Troxel <gdt%lexort.com@localhost>]

Ryo ONODERA <ryo%tetera.org@localhost> writes:

> For next and next after next branches, I want to update
> www/php-nextcloud to 29.0.2.
> Nextcloud supports update from previous major release only.
> And Nextcloud 30 is expected to be released in a next quarter.
>
> Can I update www/php-nextcloud to 29.0.2 during freeze?

In general I lean to stable vs fresh, and part of the point of freeze is
to allow people time to test what is there and fix bugs; updates in
freeze risk new problems that others won't have time to fix.  (We assume
micros are ok, putting upstreams in timeout when they have a history of
not being ok :-) But in general I see the freeze as not the time to do
updates.

I am blurring my own status as a nextcloud user with the pmc role, but
OTOH considering a random user is really the question.

Nextcloud has 3 releases a year and we have 4.  (They really should fix
their upgrade process to be able to just run two database upgrade
cycles, like most other programs that have database schema changes,
e.g. synapse, but that's out of scope for how we cope!)

https://download.nextcloud.com/server/releases/

28.0.0	December 11, 2023
28.0.1	December 21
28.0.2	February 1
28.0.3	February 29
28.0.4	March 28
28.0.5	April 25
28.0.6	May 23

29.0.0	April 23
29.0.1	May 23
29.0.2	June 6

I have a few questions:

  What is nextcloud's track record of the .0.0 and 0.0.1 releases being
  ok (no bugs bad enough to cause data loss or serious non-operability)?

  I am assuming that by .0.2 things are almost always stable.  Do you
  see it that way?

  What platforms have you tested on?  Are you now running it in
  production?  How many days of operation do you have?  caldav and
  carddav servers?  I really don't know where users run nextcloud, but
  personally I have it on 9/amd64.  pkgsrc developers tend to run 10 or
  even worse (for users on 9) current (I myself run 10 on my main box).
  I don't know if people are using it on aarch64.  I kind of doubt i386
  and earvm7hf-el are significant, because nextcloud is piggy enough
  that I suspect it wouldn't work well anyway.

  Not that we have a requirement, but it's not in wip so it's hard for
  others to test what you want to commit before it lands.

I see your point that 30.0.0 should arrive in mid August and have 30.0.1
in September.  I see landing .0.1 for Q3 (freeze expected September 20)
as too aggressive, and updating to 30.0.2 in mid October seems like an
entirely reasonable plan.  Even if we do 29.0.2 now, landing 30.0.1 for
next branch seems too aggressive.

All of this makes me view updating to 29.0.x immediately post freeze and
then to 30.0.x just after the Q3 freeze seem like a reasonable plan.
Basically update when a .0.2 or .0.3 is released, unless in freeze, or
an update is blocked by a previous update that quarter -- but then do it
right away when the freeze is over.

If I personally cared about running 29 vs 28, I could certainly wait
(given that I didn't do anything about it the last 2 months!) another 10
days for you to commit the update post freeze and then install it.  So I
don't see delaying 29 and 30 across a branch as having serious
consequences for the (few?) people that care which branch they run.  I
think most people that run nextcloud don't need bleeding edge features
and want it to be quietly 100% reliable.  That argues for being slower
to jump nextcloud releases in pkgsrc stable branches.

I know we've talked about the problem caused by upstream's deficient
update process before.  Plus, some users may want to avoid updates.
This is making me think that we should perhaps consider having nextcloud
be always versioned, so renaming nextcloud to nextcloud28 and adding
nextcloud29.  Then the new version doesn't hurt the old users and we
don't need to be so careful.

However, we didn't end up doing that, and just added nextcloud26, and I
think that is because usually nextcloud is updated every quarter (when
there's a stable release with a few micros before it's too late) and
this doesn't lead to stacked up once/quarter updates being persistently
behind.  It does lead to tending to lag by 1.5 months, but I think
that's completely ok.

Bottom line:

  1) I think we need testing on 9/amd64 as a requirement before an
  in-freeze update.

  2) Needing to consider this question makes me think we should either:

    - A) agree that we will be ok with behind 1-2 months behind and not do
      updates right up against the branch

    - B) decide that some users really need freshness and version
      nextcloud entirely, so there is no 'nextcloud', but instead
      nextcoudNN, were they are added as soon as anybody wants (but not
      in freeze ;_) and users choose to jump branches, like pgsql.  And,
      we regularly drop old branches; I'd see more then 3 as a bug.  (We
      still have 26, and that seems wrong already.)  This is a lot of
      work, and I'd rather us not start down that path unless someone
      volunteers to keep after it.  Just keeping nextcloud updated is
      hard enough.

Right now I am at 2A, but I would like to hear your comments on all
this.

I also welcome comments from pkgsrc users who are running nextcloud, as
to how they see it.  And of course from anybody else.

Greg