4 ms·

I find the idea that a technology should be replaced simply because it is old to be very irksome. Those developers out there blindly contributing to the trend

• Klathmon 10y ago
  While I agree, the opposite is also an issue. Developers which either look down upon anything new as "pointless" or in some cases actively try to stop improvements. Looking at the kernel dev system, it works great, but it has its share of problems. I've never even thought about contributing to the kernel because of the work involved to just submit a patch, that process can be improved. Making it easier for newcomers, and updating some of the workflow to be more aligned with current tools could really help.
  • taeric 10y ago
    I didn't realize the kernel had a large process to submit. Any particular part scare you off?
  • userbinator 10y ago
    I think it's a deliberate barrier to entry: they're basically saying "if you can't be bothered to learn how to do it, we don't want your contributions." Linus occasionally rants about some of the crap that gets in, and I have a feeling he certainly doesn't want more, which would happen if the barrier was lowered. Here's a somewhat recent example: http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html
    • digi_owl 10y ago
      I really do wonder what it is with Sievers. The handing of udev went into a nosedive after GregKH handed him the maintainership. Yet GregKH seems to trust him completely and Torvalds for some reason trust GregKH. It really makes me worry about the future of the kernel once Torvalds decides that he has had enough.
    • qb45 10y ago
      Probably you are right, though in the case you linked the barrier was clearly insufficient. And OTOH, I have seen many cases where actually sane one-time contributors had to spend unreasonable time changing trivial patches to match the guidelines. [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline It has come to our attention that a system running a specific user space init program will not boot if you add "debug" to the kernel command line. Lol. I sometimes get disgusted by the kind of crap people merge, but it's nice that at least this one got the ridicule it deserved.
  • Manishearth 10y ago
    I will note that contributing to GitHub is pretty much just as complicated, and requires just as many steps and git commands. The difference is that folks are used to contributing to GitHub. And that's an important difference. I feel that projects should allow newcomers to contribute through multiple channels. For tiny patches from newcomers, it doesn't really hurt to let them make patches on github, go through review (without annoying other folks with nitfix review emails), and mail the final patch to the list for them. Of course, as they start to contribute more, nudge them towards the "real" patch process. This moves them towards contributing the regular way without the process being one more barrier in the way of entry. I've mentioned this in http://manishearth.github.io/blog/2016/01/03/making-your-open-source-project-newcomer-friendly/ http://manishearth.github.io/blog/2016/01/03/making-your-ope... -- you can tailor your process for newcomers. Your current process is probably great for power users but might be complicated for newcomers, but at the same time a lot of what makes the process great really isn't necessary for the patches that most newcomers contribute. Of course, all this works when the project actually cares about helping newcomers. As mentioned in the other comments, it seems like Linux doesn't care about this; it prefers to restrict itself to contributors who can (and want to) figure it out on their own. This could end up filtering out smart people who could have figured it out (but found better uses of their time), but that's their choice. Not to say that projects which don't do this don't care about this. GDB has a pretty complicated process, but they're also very helpful to newcomers. I might work on providing an alternate workflow or a mentoring process at some point. Firefox is similar; the bugzilla-based workflow can be new and tricky, but there's mentorship. (Another thing I may work on improving at some point)
    • justincormack 10y ago
      FreeBSD maintains a github workflow as well as their more traditional svn workflow to make the project more accessible.
      • adrianratnapala 10y ago
        But if their traditional method is SVN, then there is a bigger reason to have some git element available. Linux already uses git, and has less incentive to add in a "git, the hard way" option.
  • xkcd-sucks 10y ago
    In most professions, quality is enforced by some sort of autocratic or bureaucratic process. Software seems to tend more to the autocratic, au least outside of enterprise emvironments
  • Aldo_MX 10y ago
    Why is people always concerned about lowering the barrier to entry just because they felt dismotivated by it? Reviewer's time is a commodity, especially in a project like the kernel, accepting new patches is not a process that scales well when you receive thousands of potentially low-quality patches. It's a tradeoff, you get less patches but the reviewers can actually focus their efforts in accepting them.
• deckard1 10y ago
  Web development is the absolute worst at this. None of the technology is new, whatsoever (mostly stealing from Lisp, rebranding it, and doing it wrong or calling MVC by yet-another name). It's impossible to quantitatively state that the new tools we use today are any better than the tools we just tossed out yesterday. Because no one became a master at the tools of yesterday. There is no basis for comparison. No expertise. Just the eternal trend following.
  • madshiva 10y ago
    So damn true!