12:09 p.m.
On 7/16/20 2:24 PM, Aleksei Bavshin wrote:
Hi Till,
On 7/16/20 1:37 PM, Till Hofmann wrote:
> I think sending the patch is a good idea! In addition to that, we should
> follow the process (e.g., announce update 7 days in advance):
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide_devel...
>
> I would suggest the following:
> 1. Create PRs on dependent packages
> 2. At the same time, announce on devel and to all maintainers of the
> dependencies
> 3. 7 days later, build wlroots + sway. Some dependent packages may go
> FTBFS, but with PRs fixing those, so I don't see a problem.
Then I'll proceed with that in a few hours, once my working day ends.
> We may also think about retiring the module. The primary purpose of the
> module (from my perspective) was to get sway 1.0 on stable releases (I
> think it was F30). I don't use the module anymore, and modularity in
> general is not very popular.
>
> I don't actually know how to retire a module, but if everyone agrees, I
> can start the process. If you think the module is still useful, I'd
> welcome any help :)
> IMO F32 should not be updated. ABI changes are strongly discouraged in
> stable releases:
> https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#philosophy
I'd argue that we need to have at least one supported way of getting sway 1.5
in the stable Fedora.
With the amount of crash fixes (dear old C, safe and reliable) and bugfixes,
the fact that wayvnc only becomes usable in 1.5 and addition of IME support,
it's a very nice to have release.
I guess that means I should look further into the modularity documentation.
Would be happy to help with that.
We could start by removing things from sway module that no longer have to be there
(most of utilities, wayland-protocols, ...) and figuring out what happens if
the installed package is removed from module. With my experience with modules I
expect nothing good :)
As my thread on devel@ has shown, we don't have a lot of options
regarding the module.
It stays until the way to get rid of it is implemented :)
As for current situation, I believe we should do a 2 step update for the
module.
1. Push all accumulated updates to all branches including f31 (and make
sure that `mako` is built from the right branch. rolling is no longer up
to date with master).
2. Submit my PRs, disable f31 in the module and publish another update
for f32+.
Since it's not required to have a rawhide build for the module build, 2
is not limited by the dates in wlroots update announcement and could be
done as soon as today.
--
With best regards,
Aleksei Bavshin