Package policy discussion

[liushuyu]

It seems that some software have bad habits of tagging versions, their tagged versions often contain even more bugs than the master branch (for Git), tip (hg), or latest revision on VCS codebase. In addition, some special software, like youtube-dl, you-get, don't have stable functionality (cough seriously)

And it has been a long argued topic that whether this kind of policy should be applied, the common pros and cons are:

Pros

• Faster update cycle brings more fresh product to users' dinning table
• Bugs are got fixed quickly and quick CVE response

  Cons

• Need to observe and pick the best commits which are exhausting and required a good knowledge of the upstream project
• More new bugs are introduced

Last words: Let's open our mind (brain hole), and ... (ominous smile)

[MingcongBai]

It seems that some softwares have bad habbit of tagging versions, their tagged versions often contains even more bugs than than the master beanch (for Git), tip (hg), or latest revision on VCS codebase.

True. But here's the thing, some exceptions have already been made in the repo as we speak: tlp as you have mentioned, is chosen to use a Git snapshot to add configuration support to its systemd unit. And lmms as really, the stable version is unusable.

youtube-dl, you-get, don't have stable functionality (cough seriously)

They do have frequent tags like vim does though so that's great.

Faster update cycle, brings more fresh product to users' dinning table

While I do accept the idea of having exceptions to using non-stable tags/versions of software, our intention should not be to provide basically -git packages as default, this is dangerous and as far as I am concerned, unpractical in most cases.

Bugs are got fixed quicker and quick CVE response

True, but backports usually works. (However, librsvg brought brief grief on my part as their CVE fixes cannot be easily merged, and given its low severity, I ignored the CVE till the next patch release as recorded in #242).

Need to observe and pick the best commits which is exhausting and required good knowledge of the upstream project

On that note, thank you for your help on keeping me updated on lmms updates that concerns Qt 5 support and Wine VST functionalities, kudos to you.

More new bugs are introduced

That's why I do believe that there should be "exceptions" instead of "common practice".

[MingcongBai]

This discussion is still open though so if you happen to come around this issue, speak out!

[liushuyu]

Tagging our greatly honored experienced member @Arthur2e5

[liushuyu]

True. But here's the thing, some exceptions have already been made in the repo as we speak: tlp as you have mentioned, is chosen to use a Git snapshot to add configuration support to its systemd unit. And lmms as really, the stable version is unusable.

... and you didn't mention the HOLY Intel video drivers ... (ominous smile)

[MingcongBai]

... and you didn't mention the HOLY Intel video drivers ... (ominous smile)

Glorious. But I do feel slightly sorry for them. But this is really a classic example of an exception.

[misaka4e21]

Let us see it from a higher view.

Is it the biggest problem that many programs depend on a special version of another program/library?

As the central team(committee) of the AOSC(ACDP) decided(appointed) in AOSCC 2015, the core system should keep stable during the lifecycle of a major version. Other parts of the system, however, are rolling updated and hard to get along well with the core.

There are atleast three ways found to solve the problem.

1. Backport features to packages in or out of core. It will be a great project.
2. Make the core system rolling-updated. Guinea pig as Archlinux was, it didn't update linux to 4.6 instantly. If we use a developer's version, all packages are going to be in [libre-testing].
3. Provide many versions in the repo at the same time.
   • Only one version of a package can be installed at one time. update-alternatives?
   • Many versions can coexist. Wow such auch, so NTed mfc42.

I found it hard to have an old base system and new applications, for the system is not loosely coupled with applications on GNU/Linux/systemd/Xorg Operating System. APIs are often changed. And the old interfaces are not only deprecated but also removed from the library when the API changed.

I could not provide any pieces of advice since it is a problem of all free software communities. They aren't dirty enough to force all down-streams to use their new API. They're not Apple/Microsoft. They're not Tencent.

And, Misakanetarmycommandertwentythousandandfirst is very sorry for her bad grammar and extremely sorry for her off-topic post.

[LionNatsu]

Interesting discussion. So it seems we need some classification for packages (actually, upstream). Good news: we will make an application to classify them and put them into database.

[MingcongBai]

We currently have a new system update model pending for post-Core 5 packaging.

[liushuyu]

Okay, I think for this topic, we have already come up with branching and update exceptions. I guess this issue could be marked as resolved now.

We currently have a new system update model pending for post-Core 5 packaging.

In the light of new policies introduced in Core 5 and upcoming Core 6, I think this issue has sufficiently completed the mission of a reminder.

[MingcongBai]

@liushuyu I’d second that.

[liushuyu]

Marking as resolved