GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Jonathan Corbet (corbet@social.kernel.org)'s status on Sunday, 22-Oct-2023 12:20:56 JST Jonathan Corbet Jonathan Corbet
    • bars
    @marcan @bars One of the worst things about working in the kernel — one of the most toxic parts — is the constant stream of nastiness toward our community that comes from outside.

    The kernel community is far from perfect; we have a lot of problems and we have been actively working for years (decades) to improve on them.

    We are, nonetheless, a project that manages to incorporate nearly 100,000 commits per year, from over 5,000 developers, into a single code base while maintaining a level of quality that — while also certainly in need of improvement — is good enough for deployment into billions of devices.

    As for the use of email...email is painful and broken, but we have found nothing better that will work at the scale we need. See https://lwn.net/Articles/702177/ from a few years back. For all its faults, email is distributed, non-proprietary, scriptable, and gives everybody the freedom to choose their tools; it is a highly inclusive solution in a way that proprietary web forges (for example) are not. Someday we'll find something better and move on with a cry of joy, but that day has not come.

    Rather than crapping on the kernel community from afar, why not work with us to try to make things better?
    In conversation Sunday, 22-Oct-2023 12:20:56 JST from social.kernel.org permalink

    Attachments

    1. Domain not in remote thumbnail source whitelist: static.lwn.net
      Why kernel development still uses email
      In a world full of fancy development tools and sites, the kernel project's dependence on email and mailing lists can seem quaintly dated, if not positively prehistoric. But, as Greg Kroah-Hartman pointed out in a Kernel Recipes talk titled "Patches carved into stone tablets", there are some good reasons for the kernel community's choices. Rather than being a holdover from an older era, email remains the best way to manage a project as large as the kernel.
    • Embed this notice
      Vegard Nossum 🥑 (vegard@mastodon.social)'s status on Sunday, 22-Oct-2023 12:21:06 JST Vegard Nossum 🥑 Vegard Nossum 🥑
      in reply to

      @corbet "Of the 5,000 developers who work on the kernel each year, not a single one of them is tasked with documentation"

      Do you mean full time? All Oracle Linux kernel devs have an explicit mandate to work on upstream docs. I'm by no means a frequent contributor, but I've submitted a few patches; most of them got rather lukewarm responses at best. I think this actually ties in with what @marcan says: it's draining and not very rewarding when you have to fight for every attempted change.

      In conversation Sunday, 22-Oct-2023 12:21:06 JST permalink
      clacke likes this.
    • Embed this notice
      Jonathan Corbet (corbet@social.kernel.org)'s status on Sunday, 22-Oct-2023 12:21:07 JST Jonathan Corbet Jonathan Corbet
      in reply to
      • Adam Williamson :fedora:
      • bars
      @adamw @bars @marcan Bug tracking is clearly a place where the kernel project falls down badly, agreed. We finally got regression tracking funded, but that's just barely the beginning of the problem.

      For bug tracking, one aspect of the problem is a simple unwillingness on the part of many maintainers to bother with a bug tracker. That does not help at all.

      The other part is something I'm going to poke people at the LF shindig about next week. Almost everybody who works on the kernel is paid to do it, but there are many areas that no company thinks it needs to worry about funding. Of the 5,000 developers who work on the kernel each year, not a single one of them is tasked with documentation — my own pet peeve. But (almost) nobody is paid to work on tools, and it hurts us in all kinds of ways, including bug tracking.
      In conversation Sunday, 22-Oct-2023 12:21:07 JST permalink
      clacke repeated this.
    • Embed this notice
      Adam Williamson :fedora: (adamw@fosstodon.org)'s status on Sunday, 22-Oct-2023 12:21:08 JST Adam Williamson :fedora: Adam Williamson :fedora:
      in reply to
      • bars

      @corbet @bars @marcan I think Hector can be a bit strident in his messaging, but I don't think he's *wrong*. From my perspective (Fedora QA) the kernel is one of the things that makes me sigh the most. Just about every other project I deal with - which is, like, nearly all of them - makes it easier to file and find bug reports, follow the progress of debugging and fixing them, and submit and follow pull requests (or whatever the system they use call it).

      In conversation Sunday, 22-Oct-2023 12:21:08 JST permalink
    • Embed this notice
      Martin Owens :inkscape: (doctormo@floss.social)'s status on Sunday, 22-Oct-2023 12:21:17 JST Martin Owens :inkscape: Martin Owens :inkscape:
      in reply to
      • Adam Williamson :fedora:
      • bars

      @corbet @adamw @bars @marcan

      Compiling without assistance from bug wranglers, doc writers and designers is like trying to do a DnD campaign called "woops all rouges"

      The impact of Nathan Lee, Suv and now Krlr on inkscape's development has been monumental. None are developers, all kept the issues tracker producing actionable and detailed reports. But all were volunteers.

      The ecological failure in foss can be solved, but not with dichotomised economics. Who pays matters. Who says matters.

      In conversation Sunday, 22-Oct-2023 12:21:17 JST permalink
      clacke likes this.
    • Embed this notice
      Adam Williamson :fedora: (adamw@fosstodon.org)'s status on Sunday, 22-Oct-2023 12:21:20 JST Adam Williamson :fedora: Adam Williamson :fedora:
      in reply to
      • Martin Owens :inkscape:
      • bars

      @doctormo @corbet @bars @marcan true, but it's not just that. my job is QA but I spend a lot of time coding. I've written fixes for GNOME, KDE, and hundreds of other projects. it is *much* easier to do drive-bys for projects with decent issue tracking and an understandable pull request system with CI hooked up to it (so I know my fix isn't totally busted). the kernel is extremely resistant to drive-by contributions. obviously this is partly due to its nature, but only *partly*.

      In conversation Sunday, 22-Oct-2023 12:21:20 JST permalink
      clacke likes this.
    • Embed this notice
      jade (leftpaddotpy@hachyderm.io)'s status on Sunday, 22-Oct-2023 12:21:29 JST jade jade
      in reply to

      @corbet @marcan

      I think it is reasonable to object to "from outside". marcan is literally a seasoned kernel maintainer. I don't think he needs to be explained what the scale of kernel dev is.

      This is a meaningless non-defense of the status quo.

      For example, what if there was a forge using open software for each subsystem? You could then integrate whatever tooling you'd like with it.

      Bram (rip) made an email based workflow on top of GitHub for vim e.g.. It can be done.

      In conversation Sunday, 22-Oct-2023 12:21:29 JST permalink
      clacke likes this.

Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.