7 ms·

Sorry, why do maintainers owe us anything? They’re typically unpaid or poorly paid and are doing everyone a favour. The code is open source and anyone who doesn

Sorry, why do maintainers owe us anything? They’re typically unpaid or poorly paid and are doing everyone a favour. The code is open source and anyone who doesn’t like their work can easily fork the project. They don’t need to justify anything to us

Kwpolska 2y ago
This isn’t the project maintainer we’re talking about, it’s the Debian package maintainer. Their job is building a working .deb with working software, not randomly messing with it. Users have the right to demand their packages to be trustworthy.
- g1sm 2y ago
  He wasn’t randomly messing with it, there was a bug report about this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
  - Kwpolska 2y ago
    Doing it in response to a single user’s bug report from 2020 that does not provide any rationale other than “network access bad” constitutes randomly messing with packages.
    - WorldMaker 2y ago
      You doubt that bug poster's "belief" that "most people want" that change?
    - whoopdedo 2y ago
      The feature flag is put there by upstream. If they don't want to support non-network installs then why do they even have that lever? That said it probably makes more sense for Debian to package a `keepassxc-nonet` alongside the default `keepassxc` so end users can choose the variant.
      - Kwpolska 2y ago
        If a user wants to build a hardened copy, they are free to do that. Distros should provide a version with standard features that are expected by end users.
        int_19h 2y ago
        This kind of thing is one of the reasons why we have different distros. For Debian, it's actually common to provide a "minimal" package plus one or more versions built with different feature flags.
        netsharc 2y ago
        I agree, it's also supremely obnoxious that upgrading a piece of software means losing a lot of functionality - unless the user knows s/he needs to replace the package with the -full version.. Wahey, isn't that what MS does with e.g. Outlook. Congrats Debian, you're reaching Microsoft's level!
        kiwijamo 2y ago
        I agree that is unfortunate however I would argue the package should have been built that way in the first place. It's not the best thing to do now but better late than never. I wonder if the Debian maintainer would consider some sort of transactional package which brings in the new package if you had the original one installed. However, as someone who has used Keepass and did not realise it had all these extra functionalities, I think the assessment that most users will see no difference is ultimately closer to the truth than many people realise. I migrated away from Keepass specifically because I thought it had no network functions which makes all this drama especially ironic for a software that was marketed (at the time) as a password manager to keep on your own device and not someone else's machine.
        kiwijamo 2y ago
        As a Debian user I like how Debian just includes the basics in the main package and provides optional extras if you want them. I'm not sure how other distros handle it the other way around -- if the main package includes everything the risk is naive users install packages that include functions they don't need that end up exposing security issues. The Debian approach provides a reduced attack surface out of the box and if I happen to need something more its easy to just apt search ${package_name} and see what other extensions are available and install these. I do this regularly for PHP modules for instance if some PHP code complains a certain module is not available. It may not be your cup of tea but this is the Debian approach, and it makes sense from the perspective of a defensive user like me to keep things simple.
- sangnoir 2y ago
  > Their job is building a working .deb with working software If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file. However, it's not unheard of for package managers to maintain an evolving patchset that changes the default behavior and better integrates the upstream project to the rest of the distribution and its philosophy.
  - WorldMaker 2y ago
    > If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file. That's what some users seem to want today. It's why both Flatpak and Snap exist with the goals of letting upstream developers just CI/CD spit out a "universal" package for Linux and getting a more "Mac-like" (or "Windows-like" if you prefer) install experience with less waiting for package maintainers to get around to publishing upstream changes. Admittedly, Flatpak and Snap aren't universally beloved either, yet, but the balance of what the job for a distro's package maintainers should be is definitely in shift.
  - Kwpolska 2y ago
    Upstream developers don’t have the time and bandwidth to set up packaging for all distros and versions. Improving defaults may be fine according to some. Removing major features advertised by the software due to political reasons is not fine. My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version). How is this “better integration with the philosophy”?
    - ranger_danger 2y ago
      I think one of the potentially bigger things that doesn't yet exist is an easy way for non-developers to build their own packages with whatever options they want. By easy I mean a GUI tool that works across the majority of projects out there, and on any distro.
- Am4TIfIsER0ppos 2y ago
  Randomly messing with the code they package is the primary job of a debian packager. Which is how we get such great contributions from debian maintainers like the weak keys fiasco.
  - kiwijamo 2y ago
    It can also work the other way around. When I install Apache on other distros I end up having to disable so many modules -- whereas the default Apache config in Debian is pretty watertight I never really have to mess around with modules. Likewise installing PHP only installs the core PHP module, you have to specifically install the extras. Other distros install everything including the kitchen sink. Needless to say, I'll take the Debian approach, warts and all.
- Daviey 2y ago
  demand? Perhaps if you are unhappy you should ask for a refund. I just can't get my head around this sort of entitlement.
  - Kwpolska 2y ago
    What do you propose instead? Why should users always accept and agree with the Debian maintainers' choices, even if they're dumb and produce insecure software? Why should being a volunteer give you a get out of jail free card?
    - Daviey 2y ago
      I propose request, rather than demand. If you don't agree with the maintainers choice and it is a legitimate issue, you could raise the issue with the Debian community and try to get some more support. Alternatively, suggest a fix that meets both requirements (such as a -full package). There is no get out jail card here... just people volunteering their time, and a subset of users that feel they have some sort of entitlement. If I volunteer to pick up trash at my local park, would you demand that I pick up your garbage? No.. that would make you a jerk. I'm an inactive Debian Maintainer and retired Ubuntu core dev, so perhaps my views are biased.. but I really think people should show these volunteers more respect.
lannisterstark 2y ago
>Sorry, why do maintainers owe us anything? "they're doing it for free, no one owes you anything" is always the argument people make when someone does something reasonably dumb and they need to defend the maintainers/devs. They don't owe anyone anything, but people DO HAVE _REASONABLE_ expectations of them.
fullspectrumdev 2y ago
Package maintainer != Project maintainer. In this instance the maintainer of the Debian package for KeePassXC has unilaterally made a choice.
- kiwijamo 2y ago
  Which is pretty much what all other Debian package maintainers do. For Debian users it's expected they ensure the software they are packaging fits in with the Debian way of doing things. This is what Debian users want -- if they wanted all packages 'nude' with no changes applied there are other distros e.g. Arch that are much better suited. I personally tried other distros which tries to package as close to upstream as possible, and I was pretty surprised by the poor upstream defaults of many packages and lack of useful utilities. E.g. Apache is so much better packaged by Debian -- it wasn't until I installed Apache in Arch that I realised many of the useful stuff I used in Debian was actually Debian-specific. Most packages in Debian come with very good defaults that my "setup" script (i.e. install/configure packages) for my Debian machine is literally <50 lines whereas for Arch it was something like 200 lines including due to having to reconfigure a lot of not-very-well-thought-out upstream defaults that Arch kept in place.
  - fullspectrumdev 2y ago
    With Debian I expect sensible default configs, but not “we deleted a load of actual features”. In this case it’s features that were patched out - not plugins or a mere config change.
    - m-p-3 2y ago
      KeepassXC consider these options as "plugins", it's right there in their official documentation for the build options. The Debian package wasn't shipping the correct default configuration in the first place, it's unfortunate but better late than never, and it's not like you can't switch to the keepassxc-full package.
      - Dylan16807 2y ago
thaumaturgy 2y ago
I anticipated this reply, either here or elsewhere, and was really hoping it wouldn't arrive. I do a lot of volunteer work too. Guess what? My decisions in those roles are not unimpeachable. Being a volunteer also does not mean you are owed anything, even gratitude. It's a thing you choose to do, and if you don't like doing it anymore, then you should stop doing it. Package maintainers aren't self-sacrificial saints or all that unique as volunteers go. This is a bad decision. It deserves criticism and discussion. The volunteer status of package maintainership is irrelevant.
- CooCooCaCha 2y ago
  I share your frustration because comments like that show up in every thread about open source. By putting something out into the world you're creating connections with others. If people like what you've built and start to rely on it then that puts power into your hands, and any time you have power over others it should be wielded responsibly. Volunteering doesn't give people a pass to screw over others.
  - otherme123 2y ago
    And who decides "responsible"? The mantainer made the decision of defaulting to no-network for safety reasons, that users can reverse with a flag. This sounds responsible enough for me. I bet that if a bug is found in the connection API and passwords leak, we would impale the head of the mantainer in a pike for not defaulting to safe mode, or to have connection at all.
    - nrabulinski 2y ago
      And the software authors made it clear that those features, even if compiled in, are disabled by default and the code never executes.
- roenxi 2y ago
  Connecting the internet and a password database together is one of those fundamentally bad ideas. This might well be an excellent technical decision. Although I agree with the thread root that this is a level of intervention that might justify some rebranding. > Package maintainers aren't self-sacrificial saints or all that unique as volunteers go. If you want keepassx, you can go install it. If you want the Debian archive's version, install that. All the options are open to critique, but the average Debian maintainer is doing so much more good than the occasional bad decision that they get a lot of benefit-of-doubt on this sort of choice. And some reasonable expectations of respect.
deleted 2y ago
[deleted]
mardifoufs 2y ago
They don't owe us anything, but that's completely unrelated to the current discussion. They can be completely free to do whatever they want, and users can also disagree with that and voice said disagreement. It's a two way street. Especially in a situation where there's only "one" maintainer per package per distro, meaning that users of the distro (who can be other maintainers too) can disagree with it and openly so. There's a reason why Debian doesn't allow a maintainer to say, gut systemd or switch to another init system unilaterally just because they are volunteering to maintain the package
cqqxo4zV46cp 2y ago
This line is always ludicrous because it doesn’t play in literally any other volunteering scenario. In a previous life I coordinated volunteers. You better believe that I still held them to a standard and told them their time was better spent elsewhere if they didn’t want to play by the rules. “But they’re volunteering!” Is a uniquely open source contributor mindset that only seeks to perpetuate some nerd’s weird fiefdom. The reality is that for some people, they’re just…fine not getting paid with money, because what they’re really after is something to control.
- kiwijamo 2y ago
  At the end of the day the volunteer is a volunteer for the Debian project (not KeepassXC or others) and doing what is deemed right for the Debian project. I agree volunteers should be held to a high standard, although I suspect in this case the volunteer is maintaining Debian's high standards. As a Debian user the volunteer's decision seems in line with Debian's ethos.
valicord 2y ago
If you claim to distribute application FooBar, you owe it to the authors of said application to actually distribute FooBar and not something else that was modified against their wishes. If you want to distribute a modified version, you should call it something other than FooBar. You also owe it to your users to not mislead them by claiming that your modified version is actually the real FooBar.
- kiwijamo 2y ago
  I note elsewhere in this thread that all they did was disable an option from the upstream build script -- suggesting this is an acceptable option provided by upstream themselves? I think suggesting a rename is a bridge too far given even upstream provides a way to build the software without the extra functionality behind what sounds like a simple build option flag.
- deleted 2y ago
  [deleted]

Kwpolska 2y ago

This isn’t the project maintainer we’re talking about, it’s the Debian package maintainer. Their job is building a working .deb with working software, not randomly messing with it. Users have the right to demand their packages to be trustworthy.

g1sm 2y ago
He wasn’t randomly messing with it, there was a bug report about this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953529
- Kwpolska 2y ago
  Doing it in response to a single user’s bug report from 2020 that does not provide any rationale other than “network access bad” constitutes randomly messing with packages.
  - WorldMaker 2y ago
    You doubt that bug poster's "belief" that "most people want" that change?
  - whoopdedo 2y ago
    The feature flag is put there by upstream. If they don't want to support non-network installs then why do they even have that lever? That said it probably makes more sense for Debian to package a `keepassxc-nonet` alongside the default `keepassxc` so end users can choose the variant.
    - Kwpolska 2y ago
      If a user wants to build a hardened copy, they are free to do that. Distros should provide a version with standard features that are expected by end users.
      - int_19h 2y ago
        This kind of thing is one of the reasons why we have different distros. For Debian, it's actually common to provide a "minimal" package plus one or more versions built with different feature flags.
      - netsharc 2y ago
        I agree, it's also supremely obnoxious that upgrading a piece of software means losing a lot of functionality - unless the user knows s/he needs to replace the package with the -full version.. Wahey, isn't that what MS does with e.g. Outlook. Congrats Debian, you're reaching Microsoft's level!
        kiwijamo 2y ago
        I agree that is unfortunate however I would argue the package should have been built that way in the first place. It's not the best thing to do now but better late than never. I wonder if the Debian maintainer would consider some sort of transactional package which brings in the new package if you had the original one installed. However, as someone who has used Keepass and did not realise it had all these extra functionalities, I think the assessment that most users will see no difference is ultimately closer to the truth than many people realise. I migrated away from Keepass specifically because I thought it had no network functions which makes all this drama especially ironic for a software that was marketed (at the time) as a password manager to keep on your own device and not someone else's machine.
      - kiwijamo 2y ago
        As a Debian user I like how Debian just includes the basics in the main package and provides optional extras if you want them. I'm not sure how other distros handle it the other way around -- if the main package includes everything the risk is naive users install packages that include functions they don't need that end up exposing security issues. The Debian approach provides a reduced attack surface out of the box and if I happen to need something more its easy to just apt search ${package_name} and see what other extensions are available and install these. I do this regularly for PHP modules for instance if some PHP code complains a certain module is not available. It may not be your cup of tea but this is the Debian approach, and it makes sense from the perspective of a defensive user like me to keep things simple.
sangnoir 2y ago
> Their job is building a working .deb with working software If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file. However, it's not unheard of for package managers to maintain an evolving patchset that changes the default behavior and better integrates the upstream project to the rest of the distribution and its philosophy.
- WorldMaker 2y ago
  > If that were was all there is to packaging - upstream developers could do the same job & have their CI/CD pipeline shoot out a .deb file. That's what some users seem to want today. It's why both Flatpak and Snap exist with the goals of letting upstream developers just CI/CD spit out a "universal" package for Linux and getting a more "Mac-like" (or "Windows-like" if you prefer) install experience with less waiting for package maintainers to get around to publishing upstream changes. Admittedly, Flatpak and Snap aren't universally beloved either, yet, but the balance of what the job for a distro's package maintainers should be is definitely in shift.
- Kwpolska 2y ago
  Upstream developers don’t have the time and bandwidth to set up packaging for all distros and versions. Improving defaults may be fine according to some. Removing major features advertised by the software due to political reasons is not fine. My software is a victim of Debian maintainers as well: they chose to remove the default theme from our static site generator, because it was built on top of Bootstrap 3, but Debian only shipped Bootstrap 2 at the time in a global package (they also changed the bootstrap 2 theme to use symlinks to the global version). How is this “better integration with the philosophy”?
  - ranger_danger 2y ago
    I think one of the potentially bigger things that doesn't yet exist is an easy way for non-developers to build their own packages with whatever options they want. By easy I mean a GUI tool that works across the majority of projects out there, and on any distro.
Am4TIfIsER0ppos 2y ago
Randomly messing with the code they package is the primary job of a debian packager. Which is how we get such great contributions from debian maintainers like the weak keys fiasco.
- kiwijamo 2y ago
  It can also work the other way around. When I install Apache on other distros I end up having to disable so many modules -- whereas the default Apache config in Debian is pretty watertight I never really have to mess around with modules. Likewise installing PHP only installs the core PHP module, you have to specifically install the extras. Other distros install everything including the kitchen sink. Needless to say, I'll take the Debian approach, warts and all.
Daviey 2y ago
demand? Perhaps if you are unhappy you should ask for a refund. I just can't get my head around this sort of entitlement.
- Kwpolska 2y ago
  What do you propose instead? Why should users always accept and agree with the Debian maintainers' choices, even if they're dumb and produce insecure software? Why should being a volunteer give you a get out of jail free card?
  - Daviey 2y ago
    I propose request, rather than demand. If you don't agree with the maintainers choice and it is a legitimate issue, you could raise the issue with the Debian community and try to get some more support. Alternatively, suggest a fix that meets both requirements (such as a -full package). There is no get out jail card here... just people volunteering their time, and a subset of users that feel they have some sort of entitlement. If I volunteer to pick up trash at my local park, would you demand that I pick up your garbage? No.. that would make you a jerk. I'm an inactive Debian Maintainer and retired Ubuntu core dev, so perhaps my views are biased.. but I really think people should show these volunteers more respect.

lannisterstark 2y ago

>Sorry, why do maintainers owe us anything? "they're doing it for free, no one owes you anything" is always the argument people make when someone does something reasonably dumb and they need to defend the maintainers/devs. They don't owe anyone anything, but people DO HAVE _REASONABLE_ expectations of them.

fullspectrumdev 2y ago

Package maintainer != Project maintainer. In this instance the maintainer of the Debian package for KeePassXC has unilaterally made a choice.

kiwijamo 2y ago
Which is pretty much what all other Debian package maintainers do. For Debian users it's expected they ensure the software they are packaging fits in with the Debian way of doing things. This is what Debian users want -- if they wanted all packages 'nude' with no changes applied there are other distros e.g. Arch that are much better suited. I personally tried other distros which tries to package as close to upstream as possible, and I was pretty surprised by the poor upstream defaults of many packages and lack of useful utilities. E.g. Apache is so much better packaged by Debian -- it wasn't until I installed Apache in Arch that I realised many of the useful stuff I used in Debian was actually Debian-specific. Most packages in Debian come with very good defaults that my "setup" script (i.e. install/configure packages) for my Debian machine is literally <50 lines whereas for Arch it was something like 200 lines including due to having to reconfigure a lot of not-very-well-thought-out upstream defaults that Arch kept in place.
- fullspectrumdev 2y ago
  With Debian I expect sensible default configs, but not “we deleted a load of actual features”. In this case it’s features that were patched out - not plugins or a mere config change.
  - m-p-3 2y ago
    KeepassXC consider these options as "plugins", it's right there in their official documentation for the build options. The Debian package wasn't shipping the correct default configuration in the first place, it's unfortunate but better late than never, and it's not like you can't switch to the keepassxc-full package.
    - Dylan16807 2y ago

thaumaturgy 2y ago

I anticipated this reply, either here or elsewhere, and was really hoping it wouldn't arrive. I do a lot of volunteer work too. Guess what? My decisions in those roles are not unimpeachable. Being a volunteer also does not mean you are owed anything, even gratitude. It's a thing you choose to do, and if you don't like doing it anymore, then you should stop doing it. Package maintainers aren't self-sacrificial saints or all that unique as volunteers go. This is a bad decision. It deserves criticism and discussion. The volunteer status of package maintainership is irrelevant.

CooCooCaCha 2y ago
I share your frustration because comments like that show up in every thread about open source. By putting something out into the world you're creating connections with others. If people like what you've built and start to rely on it then that puts power into your hands, and any time you have power over others it should be wielded responsibly. Volunteering doesn't give people a pass to screw over others.
- otherme123 2y ago
  And who decides "responsible"? The mantainer made the decision of defaulting to no-network for safety reasons, that users can reverse with a flag. This sounds responsible enough for me. I bet that if a bug is found in the connection API and passwords leak, we would impale the head of the mantainer in a pike for not defaulting to safe mode, or to have connection at all.
  - nrabulinski 2y ago
    And the software authors made it clear that those features, even if compiled in, are disabled by default and the code never executes.
roenxi 2y ago
Connecting the internet and a password database together is one of those fundamentally bad ideas. This might well be an excellent technical decision. Although I agree with the thread root that this is a level of intervention that might justify some rebranding. > Package maintainers aren't self-sacrificial saints or all that unique as volunteers go. If you want keepassx, you can go install it. If you want the Debian archive's version, install that. All the options are open to critique, but the average Debian maintainer is doing so much more good than the occasional bad decision that they get a lot of benefit-of-doubt on this sort of choice. And some reasonable expectations of respect.

deleted 2y ago

[deleted]

mardifoufs 2y ago

They don't owe us anything, but that's completely unrelated to the current discussion. They can be completely free to do whatever they want, and users can also disagree with that and voice said disagreement. It's a two way street. Especially in a situation where there's only "one" maintainer per package per distro, meaning that users of the distro (who can be other maintainers too) can disagree with it and openly so. There's a reason why Debian doesn't allow a maintainer to say, gut systemd or switch to another init system unilaterally just because they are volunteering to maintain the package

cqqxo4zV46cp 2y ago

This line is always ludicrous because it doesn’t play in literally any other volunteering scenario. In a previous life I coordinated volunteers. You better believe that I still held them to a standard and told them their time was better spent elsewhere if they didn’t want to play by the rules. “But they’re volunteering!” Is a uniquely open source contributor mindset that only seeks to perpetuate some nerd’s weird fiefdom. The reality is that for some people, they’re just…fine not getting paid with money, because what they’re really after is something to control.

kiwijamo 2y ago
At the end of the day the volunteer is a volunteer for the Debian project (not KeepassXC or others) and doing what is deemed right for the Debian project. I agree volunteers should be held to a high standard, although I suspect in this case the volunteer is maintaining Debian's high standards. As a Debian user the volunteer's decision seems in line with Debian's ethos.

valicord 2y ago

If you claim to distribute application FooBar, you owe it to the authors of said application to actually distribute FooBar and not something else that was modified against their wishes. If you want to distribute a modified version, you should call it something other than FooBar. You also owe it to your users to not mislead them by claiming that your modified version is actually the real FooBar.

kiwijamo 2y ago
I note elsewhere in this thread that all they did was disable an option from the upstream build script -- suggesting this is an acceptable option provided by upstream themselves? I think suggesting a rename is a bridge too far given even upstream provides a way to build the software without the extra functionality behind what sounds like a simple build option flag.
deleted 2y ago
[deleted]