Hello,
As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team.
While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining.
Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd
Regards
On Thu, Jun 29, 2023 at 10:48 AM Bastien Nocera bnocera@redhat.com wrote:
Hello,
As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team.
While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining.
Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd
I've picked up libimobiledevice as I need it for Fedora Asahi work.
I've picked up low-memory-monitor
On 6/29/23 08:46, Neal Gompa wrote:
On Thu, Jun 29, 2023 at 10:48 AM Bastien Nocera bnocera@redhat.com wrote:
Hello,
As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team.
While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining.
Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd
I've picked up libimobiledevice as I need it for Fedora Asahi work.
Do you want to pick up the rest of the libimobiledevice stack as well? That's ifuse, libplist, libusbmuxd and usbmuxd.
On 2023-06-29 18:09, Bastien Nocera wrote:
Do you want to pick up the rest of the libimobiledevice stack as well? That's ifuse, libplist, libusbmuxd and usbmuxd.
I've just picked these up, thanks! Will work together with Neal on this stack as part of the Fedora Asahi SIG.
Cheers Davide
On Thu, 29 Jun 2023 at 10:48, Bastien Nocera bnocera@redhat.com wrote:
Hello,
As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team.
1. Thank you for all the work you have done on these and other packages in Fedora. The Bluetooth stack is not easy. 2. Thank you for announcing this early and allowing a quick transfer. 3. Good luck with the new team, they are lucky to have you.
Bastien Nocera wrote:
As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team.
So Red Hat is essentially killing all work on desktop packages, not just on LibreOffice? Also considering that several of those packages are libraries that cannot just be put on Flathub as LibreOffice can (which was their excuse for terminating all work on LibreOffice packaging).
With the layoff and the destruction of the position of the Fedora Program Manager, the termination of public RHEL source releases, and this move, Red Hat is really turning into an unfriendly company, and I really have to wonder whether Fedora is going to be of any use to me in the long run.
Kevin Kofler
On Fri, Jun 30, 2023 at 4:41 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Bastien Nocera wrote:
As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team.
So Red Hat is essentially killing all work on desktop packages, not just on LibreOffice? Also considering that several of those packages are libraries that cannot just be put on Flathub as LibreOffice can (which was their excuse for terminating all work on LibreOffice packaging).
I would hardly say Libreoffice, bluetooth on the desktop and certain iDevice pieces is "killing all work on the desktop" it's more focusing on things that are important to their customers in those contexts.
Peter Robinson wrote:
I would hardly say Libreoffice, bluetooth on the desktop and certain iDevice pieces is "killing all work on the desktop" it's more focusing on things that are important to their customers in those contexts.
What corporate desktop customers do not use LibreOffice? If RH considers LibreOffice unimportant to their customers, it is obvious that they only care about server customers.
Kevin Kofler
On Sat, Jul 1, 2023 at 1:00 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
What corporate desktop customers do not use LibreOffice?
I know two big-name scientific instrument manufacturers that offer RHEL workstations on which to run the control software. I suspect there are other domains with similar use cases, i.e. dedicated computers that only run a certain piece of software or software suite.
On Sat, Jul 1, 2023 at 12:00 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Peter Robinson wrote:
I would hardly say Libreoffice, bluetooth on the desktop and certain iDevice pieces is "killing all work on the desktop" it's more focusing on things that are important to their customers in those contexts.
What corporate desktop customers do not use LibreOffice? If RH considers LibreOffice unimportant to their customers, it is obvious that they only care about server customers.
Well if the customer gets it via Flatpak they still have it, it also means it doesn't need to be upgraded in lockstep with the OS so they can go to newer versions while keeping the same rev of the desktop or vica versa.
But then there's also "desktop usecases like retail point of sale and a whole lot of other single use UX graphical like display boards, ticket machines, places where they're technical workstations and the user has a separate windows device for email/office etc. There's a vast array.
On Sat, Jul 1, 2023 at 12:30 PM Peter Robinson pbrobinson@gmail.com wrote:
On Sat, Jul 1, 2023 at 12:00 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Peter Robinson wrote:
I would hardly say Libreoffice, bluetooth on the desktop and certain iDevice pieces is "killing all work on the desktop" it's more focusing on things that are important to their customers in those contexts.
What corporate desktop customers do not use LibreOffice? If RH considers LibreOffice unimportant to their customers, it is obvious that they only care about server customers.
Well if the customer gets it via Flatpak they still have it, it also means it doesn't need to be upgraded in lockstep with the OS so they can go to newer versions while keeping the same rev of the desktop or vica versa.
But then there's also "desktop usecases like retail point of sale and a whole lot of other single use UX graphical like display boards, ticket machines, places where they're technical workstations and the user has a separate windows device for email/office etc. There's a vast array.
Also a lot use online docs like Office365 or Google docs. I personally used to use Libreoffice a lot but now I mostly use gDocs.
Once upon a time, Kevin Kofler kevin.kofler@chello.at said:
Peter Robinson wrote:
I would hardly say Libreoffice, bluetooth on the desktop and certain iDevice pieces is "killing all work on the desktop" it's more focusing on things that are important to their customers in those contexts.
What corporate desktop customers do not use LibreOffice? If RH considers LibreOffice unimportant to their customers, it is obvious that they only care about server customers.
A lot of the corporate world has gone to the "cloud" (Google Docs or O365) for their office needs, enough that even where Windows is the predominant desktop OS, they don't get MS Office licenses either. They don't have to worry about local backups of important documents and spreadsheets, they get sharing with minimal effort, they can access things from their mobile devices, etc.
On 01/07/2023 13:36, Chris Adams wrote:
A lot of the corporate world has gone to the "cloud"
don't have to worry about local backups of important documents and spreadsheets, they get sharing with minimal effort, they can access things from their mobile devices, etc.
And voluntarily hand over all the corporate secrets to Google and Microsoft. Brilliant idea.
On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 01/07/2023 13:36, Chris Adams wrote:
A lot of the corporate world has gone to the "cloud"
don't have to worry about local backups of important documents and spreadsheets, they get sharing with minimal effort, they can access things from their mobile devices, etc.
And voluntarily hand over all the corporate secrets to Google and Microsoft. Brilliant idea.
This sort of comment is off topic, various companies are free to do with their data as they wish, just as you are free to do with it as you please. Frankly it's often more secure with cloud providers than on corporate networks. Either way that comment doesn't provide useful discourse in this discussion.
Am 01.07.23 um 14:28 schrieb Peter Robinson:
On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 01/07/2023 13:36, Chris Adams wrote:
A lot of the corporate world has gone to the "cloud"
don't have to worry about local backups of important documents and spreadsheets, they get sharing with minimal effort, they can access things from their mobile devices, etc.
And voluntarily hand over all the corporate secrets to Google and Microsoft. Brilliant idea.
This sort of comment is off topic, various companies are free to do with their data as they wish, just as you are free to do with it as you please. Frankly it's often more secure with cloud providers than on corporate networks. Either way that comment doesn't provide useful discourse in this discussion.
No really, it defines requirements that a non-cloud solution addresses. Just to rephrase it; "it's often more secure (confidential) on corporate networks than with cloud providers". So a legitimately contribution to the discourse in having a functional desktop (office) environment. Whether its being flatpaked, rpmish, immutable packaged or what ever the future brings ...
-- Leon
On 01/07/2023 14:28, Peter Robinson wrote:
This sort of comment is off topic, various companies are free to do with their data as they wish, just as you are free to do with it as you please.
This is not offtopic. What I mean is that a distribution targeted at enterprise use should have a standalone office suite in their repositories, because most enterprise users will won't use Flathub or any other third party repositories due to their internal security policy. They will simply migrate from RHEL to Ubuntu LTS or another enterprise distribution with LO.
Frankly it's often more secure with cloud providers than on corporate networks.
And they can easily dump you and all your data. Russian Federation is a good example. Both Microsoft and Google have disabled all paid accounts for users and organizations from this country.
On 7/2/23 08:56, Vitaly Zaitsev via devel wrote:
On 01/07/2023 14:28, Peter Robinson wrote:
This sort of comment is off topic, various companies are free to do with their data as they wish, just as you are free to do with it as you please.
This is not offtopic. What I mean is that a distribution targeted at enterprise use should have a standalone office suite in their repositories, because most enterprise users will won't use Flathub or any other third party repositories due to their internal security policy. They will simply migrate from RHEL to Ubuntu LTS or another enterprise distribution with LO.
These two situations can co-exist. Some companies will use cloud-based solutions because of the benefits they offer and some companies prefer to keep everything close to their chest.
Frankly it's often more secure with cloud providers than on corporate networks.
And they can easily dump you and all your data. Russian Federation is a good example. Both Microsoft and Google have disabled all paid accounts for users and organizations from this country.
The suppliers for these enterprise distributions and the support they offer also abide by political lines. While your data won't be gone in an instant you still end up in the same situation with using an unsupported office suite.
On 02/07/2023 10:51, Simon de Vlieger wrote:
The suppliers for these enterprise distributions and the support they offer also abide by political lines.
Indeed. That's why having RHEL repacks (Alma, Rocky, Oracle Linux) is good.
While your data won't be gone in an instant you still end up in the same situation with using an unsupported office suite.
You can simply switch to one of these RHEL binary compatible distributions.
On Sun, Jul 2, 2023 at 11:01 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 02/07/2023 10:51, Simon de Vlieger wrote:
The suppliers for these enterprise distributions and the support they offer also abide by political lines.
Indeed. That's why having RHEL repacks (Alma, Rocky, Oracle Linux) is good.
While your data won't be gone in an instant you still end up in the same situation with using an unsupported office suite.
You can simply switch to one of these RHEL binary compatible distributions.
Assuming those "binary compatible distributions" choose to add LibreOffice back in and support it, given what they actually do in terms of actual development it's actually pretty unlikely they're going to do all the extra work to add back an office suite and all the dependencies it requires.
Peter Robinson wrote:
Assuming those "binary compatible distributions" choose to add LibreOffice back in and support it, given what they actually do in terms of actual development it's actually pretty unlikely they're going to do all the extra work to add back an office suite and all the dependencies it requires.
If LibreOffice remains maintained in Fedora (and I sure hope so, because otherwise that would definitely make Fedora useless for me), there is a good chance that somebody will request and maintain EPEL branches for it, as has already been done for the KDE Plasma and KDE Gear applications stack.
Kevin Kofler
On Sun, Jul 2, 2023 at 10:27 PM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Peter Robinson wrote:
Assuming those "binary compatible distributions" choose to add LibreOffice back in and support it, given what they actually do in terms of actual development it's actually pretty unlikely they're going to do all the extra work to add back an office suite and all the dependencies it requires.
If LibreOffice remains maintained in Fedora (and I sure hope so, because otherwise that would definitely make Fedora useless for me), there is a good chance that somebody will request and maintain EPEL branches for it, as has already been done for the KDE Plasma and KDE Gear applications stack.
Someone doing work in EPEL is quite a bit different to my point of a corporate organisation downstream of RHEL adding value and differentiation that Red Hat doesn't provide as part of RHEL.
Peter Robinson wrote:
Someone doing work in EPEL is quite a bit different to my point of a corporate organisation downstream of RHEL adding value and differentiation that Red Hat doesn't provide as part of RHEL.
The discussion was about people being able or unable to obtain the LibreOffice packages in some parts of the world. Since EPEL is widely mirrored, and mirrors (especially non-US ones) tend to not enforce US export control, people should be able to get the EPEL packages, along with some RHEL rebuild on which to install them, basically everywhere on the world. Whether the packaging work is done in EPEL or specifically in one of the rebuilds does not really matter for that purpose.
And I do not really see a good reason why a rebuild should be doing that packaging on their own in their own repositories when it can be done within the EPEL infrastructure that benefits everyone. It is the same as for KDE Plasma&Gear really. What the rebuilds can do though is, e.g., to include the LibreOffice EPEL packages on their live images, as they are already doing with the KDE EPEL packages.
Kevin Kofler
Am 01.07.23 um 14:28 schrieb Peter Robinson:
On Sat, Jul 1, 2023 at 12:50 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 01/07/2023 13:36, Chris Adams wrote:
A lot of the corporate world has gone to the "cloud"
don't have to worry about local backups of important documents and spreadsheets, they get sharing with minimal effort, they can access things from their mobile devices, etc.
And voluntarily hand over all the corporate secrets to Google and Microsoft. Brilliant idea.
This sort of comment is off topic,
It definitely is not off-topic.
It is the core of the problem esp. big US companies tend to ignore.
May-be you guys are not aware of there are tendencies to legally prohibit such "cloud solutions" in many countries?
Ralf
On 7/3/23 13:46, Ralf Corsépius wrote:
It is the core of the problem esp. big US companies tend to ignore.
May-be you guys are not aware of there are tendencies to legally prohibit such "cloud solutions" in many countries?
It's generally not so much 'legally prohibit' as 'data has to be kept within $jurisdiction and is not to be shared outside of it'. If $jurisdiction is large enough cloud operators tend to offer that solution.
Am 03.07.23 um 18:07 schrieb Simon de Vlieger:
On 7/3/23 13:46, Ralf Corsépius wrote:
It is the core of the problem esp. big US companies tend to ignore.
May-be you guys are not aware of there are tendencies to legally prohibit such "cloud solutions" in many countries?
It's generally not so much 'legally prohibit' as 'data has to be kept within $jurisdiction and is not to be shared outside of it'. If $jurisdiction is large enough cloud operators tend to offer that solution.
Its not a cloud provider its a software vendor. Further more a couple of authoritative entities have proven that such solutions do not comply with data protection requirements. Its of value having a standalone package (to getting back to the topic). If not now, for sure in the near future.
On Fri, Jun 30 2023 at 05:40:33 AM +0200, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
So Red Hat is essentially killing all work on desktop packages, not just on LibreOffice?
No. Losing Bastien is extremely unfortunate and demoralizing, but we are not killing all work on desktop packages.
Michael
On 29/06/2023 16:47, Bastien Nocera wrote:
Hello,
As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team.
While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining.
Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd
I've picked up power-profiles-daemon
On 6/29/23 16:47, Bastien Nocera wrote:
Hello,
As part of the same process outlined in Matthias Clasen's "LibreOffice packages" email, my upstream and downstream work on desktop Bluetooth, multimedia applications (namely totem, rhythmbox and sound-juicer) and libfprint/fprintd is being stopped, and all the rest of my upstream and downstream work will be reassigned depending on Red Hat's own priorities, as I am transferred to another team.
While it's possible that some of the maintenance will stay with me in the new team, I've not yet been told which team I would be joining.
Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore: apfs-fuse bluez codespell eosrei-emojione-fonts geocode-glib gnome-bluetooth gnome-epub-thumbnailer gnome-kra-ora-thumbnailer gnome-user-share gom grilo grilo-plugins ifuse iio-sensor-proxy libfprint libglib-testing libimobiledevice libpeas libplist libportal libusbmuxd low-memory-monitor malcontent power-profiles-daemon sloccount switcheroo-control totem totem-pl-parser umockdev usbmuxd
I went ahead and picked up some of the GNOME packages from the list:
gnome-bluetooth gnome-user-share gom libglib-testing libpeas libportal totem totem-pl-parser
Victor (CC'd), do you want to pick up grilo and grilo-plugins?
On Jun 29, 2023, at 7:47 AM, Bastien Nocera bnocera@redhat.com wrote:
Here is a list of Fedora packages which I maintained or co-maintained which I won't be able to contribute to anymore:
sloccount
I grabbed sloccount as I’ve found it useful over the years.
It looks the right level of incredibly low maintenance to add to the pile.