[Backport release-24.05] open-webui: init at 0.2.4

[github-actions]

Bot-based backport to release-24.05, triggered by a label in #316248.

• Before merging, ensure that this backport is acceptable for the release.
  • Even as a non-commiter, if you find that it is not acceptable, leave a comment.

[shivaraj-bh]

Result of nixpkgs-review pr 332412 run on x86_64-linux 1

2 packages blacklisted:

• nixos-install-tools
• tests.nixos-functions.nixos-test

2 packages built:

• open-webui
• open-webui.dist

[shivaraj-bh]

Result of nixpkgs-review pr 332412 run on aarch64-darwin 1

2 packages built:

• open-webui
• open-webui.dist

[Kreyren]

Current master is broken for open-webui (see #331504 (comment)). However, I don’t think that should be a problem while backporting open-webui to 24.05, as asgiref is still on 3.7.2 there. -- @shivaraj-bh (#332260 (comment))

Add a comment to the asgiref package about this?

[shivaraj-bh]

Current master is broken for open-webui (see #331504 (comment)). However, I don’t think that should be a problem while backporting open-webui to 24.05, as asgiref is still on 3.7.2 there. -- @shivaraj-bh (#332260 (comment))

Add a comment to the asgiref package about this?

I don’t think I am allowed to do that on backport PR’s unless it already exists on master. See:

nixpkgs/CONTRIBUTING.md

Line 295 in 23b5d25

> Ensure the commits exists on the master branch.

[drupol]

If you really want to backport this, I would suggest to backport version 0.3.10 immediately. Make sure this PR contains all the cherry-picked commits required to have 0.3.10 and I'll review it.

[Kreyren]

If you really want to backport this, I would suggest to backport version 0.3.10 immediately. Make sure this PR contains all the cherry-picked commits required to have 0.3.10 and I'll review it. -- @drupol (#332412 (comment))

I oppose this, reading the changelog the version 0.3.10 seems to introduced a bunch of new features and significant refactoring which cause known issues that appear to be addressed in 0.3.11 which released 4 days ago and that is not enough time in the wild (at least to me) to be considered reliable and stable.

Proposing to skip 0.3.10 and bump on 0.3.11 in ~3 weeks instead and in the meantime merge the 0.2.4.

EDIT: Judging by the current state of development in upstream i would suggest more than 3 weeks (1.5 months?) as they seem to be doing a lot of refactoring which has an increased risk of major issues.

[drupol]

No.

At the time of writing my initial comment, version 0.3.11 had not yet been merged. Had it been available, I would have recommended using it immediately.

However, the primary point I want to emphasize is that evaluating software stability is not within our mandate as contributors. Our responsibility here is to facilitate the backporting process, not to judge the stability or features of the software.

The task of assessing stability can be subjective and is often an ongoing, never-ending process. Different contributors might have varying opinions on what constitutes 'stable' software, leading to potential delays and indecision. Our focus should remain on the technical aspects of backporting the required changes.

By continuously debating the stability of each new version, we risk creating a cycle where no version is ever deemed 'stable enough', thus stalling progress. It's essential to adhere to the defined objectives of our contribution, which in this case, is to backport the specified version.

Therefore, I stand by my recommendation to proceed with backporting the very latest version available and ensuring that all necessary cherry-picked commits are backported.

[drupol]

@shivaraj-bh can you make sure to backport the remaining PRs until the very latest version of open-webui ?

[shivaraj-bh]

@shivaraj-bh can you make sure to backport the remaining PRs until the very latest version of open-webui ?

I have a branch with all the changes upto 0.3.11, only hurdle was that it involved cherry-picking about 40 commits. You can find the draft here: #332915. I am running nixpkgs-review on it for both x86_64-linux and aarch64-darwin to verify all the packages build as expected.

[shivaraj-bh]

If it #332915 involves rebuilding a lot of packages, we can consider diverting the PR to staging-24.05.

[drupol]

If it #332915 involves rebuilding a lot of packages, we can consider diverting the PR to staging-24.05.

Good idea.

[Kreyren]

At the time of writing my initial comment, version 0.3.11 had not yet been merged. Had it been available, I would have recommended using it immediately. -- @drupol (#332412 (comment))

It was released 5 days ago: https://github.com/open-webui/open-webui/releases/tag/v0.3.11

However, the primary point I want to emphasize is that evaluating software stability is not within our mandate as contributors. Our responsibility here is to facilitate the backporting process, not to judge the stability or features of the software. -- @drupol (#332412 (comment))

Bad mandate then

By continuously debating the stability of each new version, we risk creating a cycle where no version is ever deemed 'stable enough', thus stalling progress. It's essential to adhere to the defined objectives of our contribution, which in this case, is to backport the specified version. -- @drupol (#332412 (comment))

Seems like fearmongering to excuse laziness, it's resource efficient to review the commits and make a judgement call, especially when stable is used in production 😮‍💨

[drupol]

Lol, funny user :)

We can agree to disagree, I don't mind at all !

Now I have other business to do, cheers!