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

[Ryo ONODERA <ryo%tetera.org@localhost>]

Hi,

I am sorry to my late reply.

Greg Troxel <gdt%lexort.com@localhost> writes:

> 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?

As far as I understand correctly, only one release has the problem
in upgrade vis web UI.
It was serious. however I could recover with command line.

>
>   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.

I have production deployment under NetBSD/amd64 9.
It has daily uses.
However the users do not use webdav-related services.

>   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.

It is good idea, however I will not find a time before branching...

> 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.

I will stay www/php-nextcloud as 29.


> 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.

It may be a good idea to have pho-nextcloudNN as upgrade path.

Thank you.

> Greg

-- 
Ryo ONODERA // ryo%tetera.org@localhost
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3