I'm definitely a fan of modules and streams!
I'm also a fan of not having to package v11 and v12 ;)
Recently, I've made some non-code PRs to NextCloud in order to streamline their dependency declarations & mgmt in general (see https://github.com/nextcloud/server/issues/8555 & ref'd PRs). It used to be a bit messy, but with the proposed dependency info file, there should be an easy-to-grasp overview of all deps. I hope (and personally think) this will lift the burden on packagers a bit.
As I am still new to the packagers' group, I would appreciate any advice/help/mentoring on this topic!
Also, if I were appointed to reach out to FESCo and DO all of this, I would still have to defer this task a bit, due to other time-consuming commitments atm.
I would really love to see current maintainers James and/or Shawn comment on this, and work together with them!
Randy Barlow <bowlofeggs@xxxxxxxxxxxxxxxxx> schrieb am Di., 3. Apr. 2018 um 21:25 Uhr:
On 04/03/2018 03:11 PM, Stephen Gallagher wrote:
> Given the current status, I suggest you just ask FESCo to give you
> permission to release 13.x without supporting upgrades from 10.x and
> then submit a Magazine article explaining the situation once 13.x is
> landing.
I would support this option. It sounds very difficult to me to offer a
way for users to hit all the versions along the way (we'd have to
package all of them in parallel, the user would have to manually switch
to each along the way and $do_stuff to upgrade to each point, the user
would have to *know* they need to do that*, etc.). So out of a list of
not-great options (burdensome upgrades, just skip to 13, or retire it) I
think it's reasonable enough to just declare bankruptcy.
One question comes to mind though - won't this be a problem in the
future too? How can we guarantee that users can keep upgrading to 14,
15, 16, etc. since Fedora doesn't keep in-between updates in the repos?
I.e., say Fedora 29 ships with nextcloud 14, and before Fedora 30 comes
out say 15 and 16 are released. If we update F29 to 16, 15 will be lost
with no upgrade path for the users. Perhaps this is why Stephen
suggested using modules, so we could continue to offer the various
streams. But there's still a communication problem - the user will have
to know they need to do $special_things. Maybe that's just an upstream
concern?
* As an OwnCloud user I did not know I needed to upgrade incrementally
and avoid skipping releases. If I didn't know that, it's probably safe
to assume others don't know.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
