4 ms·

One thing is clear - most developers are really bad at structuring their patches. I think it makes sense. We spend a lot of time trying to make the code work,

by lijok 3y ago

One thing is clear - most developers are really bad at structuring their patches. I think it makes sense. We spend a lot of time trying to make the code work, and then we're faced with having to spend just as much time submitting the code in a digestible format - most people will get lazy.

bhouston 3y ago
I honestly would have to research how to do a patch and I've been a professional dev since the mid-1990s. I guess I would ask ChatGPT? I've got 100s of my Github pull requests merged into successful OSS projects though. It is just weird and I guess quaint/old fashioned that Linux requires patches to be sent to an email list.
- nolist_policy 3y ago
  And yet Linux is the biggest open-source project in existence. And Git was developed - by Linus Torvalds himself - with email based development in mind from the go.
  - r053bud 3y ago
    Yeah, the development workflow is not broken at all. It’s been working great as a means to collaborate on very high quality software. I’m sure a lot of people would prefer it to take place in some Discord group or something. Fml
- bonzini 3y ago
  Emailed patches are not a huge deal for you after submission, and theoretically the first submission should be the same for both (apart from the tool you use to make it). Maintainers reply to emails with comments and you reply to them. The maintainers need to have or setup some specialized tooling to replace GitHub's CI and automation, but you don't care about that[1]. The main difference is that GitHub projects often do squash-on-merge, therefore you add fixes on top and also the commit messages don't mean much. Linux instead keeps the individual pieces so they want you to pay huge attention to the individual commit messages, the buildability and functionality at each step, and squashing each fix in the right patch. This means that reacting to the reviews, and sending subsequent versions of the changeset, is actually harder than sending the first submission! The reason however is unrelated to the use of an email workflow. [1] For the specific case of Linux, testing is way out of scope of GitHub/Gitlab's CI; for other projects using email workflow, you can usually push to a branch to have CI run and only submit when it's green.
- hashtag-til 3y ago
  Many developers these days don’t even know the difference between git and github, which is sad. There is no denying that linux kernel is a successful project, with serious development, a high quality bar and accountability. I wish my current project followed that approach. Sadly, it is a bunch of inexperienced developers that think they know it all.
  - tester756 3y ago
    >Many developers these days don’t even know the difference between git and github, which is sad. This is not sad in my opinion. GitHub is a whole project management tool and git is just letters management tool. And what developers need? a project management tool (which includes letters management tool). GitHub is where the real value is, the git itself is just like 30% of it. Using Git without e.g GH or other "wrapper" kinda sucks. Wikis, pull requests, code review, issues, roadmaps, CI/CD, community, etc, etc. All of this comes from GH. _____________ You know what is actually sad? that GitHub doesn't allow to change backend (that letters management engine), so we can switch from e.g Git to other VCS this makes hard to compete with Git because GitHub only uses Git (afaik)
    - dartos 3y ago
      I think they meant that many newer devs don’t really understand much about the giants whose shoulders they stand on. But I think that’s always the case with new devs anyway. Takes time to really learn any tool on a deep level
    - semiquaver 3y ago
      > doesn't allow to change backend they’ve supported subversion since 2010! https://github.blog/2010-04-01-announcing-svn-support/ https://github.blog/2010-04-01-announcing-svn-support/ The problem with abstraction layers is you are stuck with the worst common denominator of all supported backends. Presumably if you wanted to use a better version control system it would be for its advanced features git lacks. But a system that supported both would have a hard time taking advantage of any feature that was unique to one system.
- yjftsjthsd-h 3y ago
  > I honestly would have to research how to do a patch and I've been a professional dev since the mid-1990s. I guess I would ask ChatGPT? Because it's hard or because you've never done it?
  - bhouston 3y ago
    Because I have never had to do it. All projects I’ve worked on the last decade were on github or gitlab. And prior to that on subversion and mercurial we just would merge branches locally. Back in the 1990s I used sourcesafe which had file locking checkouts and when I used sccs I was the only contributor.

by lijok 3y ago

bhouston 3y ago

I honestly would have to research how to do a patch and I've been a professional dev since the mid-1990s. I guess I would ask ChatGPT? I've got 100s of my Github pull requests merged into successful OSS projects though. It is just weird and I guess quaint/old fashioned that Linux requires patches to be sent to an email list.

nolist_policy 3y ago
And yet Linux is the biggest open-source project in existence. And Git was developed - by Linus Torvalds himself - with email based development in mind from the go.
- r053bud 3y ago
  Yeah, the development workflow is not broken at all. It’s been working great as a means to collaborate on very high quality software. I’m sure a lot of people would prefer it to take place in some Discord group or something. Fml
bonzini 3y ago
Emailed patches are not a huge deal for you after submission, and theoretically the first submission should be the same for both (apart from the tool you use to make it). Maintainers reply to emails with comments and you reply to them. The maintainers need to have or setup some specialized tooling to replace GitHub's CI and automation, but you don't care about that[1]. The main difference is that GitHub projects often do squash-on-merge, therefore you add fixes on top and also the commit messages don't mean much. Linux instead keeps the individual pieces so they want you to pay huge attention to the individual commit messages, the buildability and functionality at each step, and squashing each fix in the right patch. This means that reacting to the reviews, and sending subsequent versions of the changeset, is actually harder than sending the first submission! The reason however is unrelated to the use of an email workflow. [1] For the specific case of Linux, testing is way out of scope of GitHub/Gitlab's CI; for other projects using email workflow, you can usually push to a branch to have CI run and only submit when it's green.
hashtag-til 3y ago
Many developers these days don’t even know the difference between git and github, which is sad. There is no denying that linux kernel is a successful project, with serious development, a high quality bar and accountability. I wish my current project followed that approach. Sadly, it is a bunch of inexperienced developers that think they know it all.
- tester756 3y ago
  >Many developers these days don’t even know the difference between git and github, which is sad. This is not sad in my opinion. GitHub is a whole project management tool and git is just letters management tool. And what developers need? a project management tool (which includes letters management tool). GitHub is where the real value is, the git itself is just like 30% of it. Using Git without e.g GH or other "wrapper" kinda sucks. Wikis, pull requests, code review, issues, roadmaps, CI/CD, community, etc, etc. All of this comes from GH. _____________ You know what is actually sad? that GitHub doesn't allow to change backend (that letters management engine), so we can switch from e.g Git to other VCS this makes hard to compete with Git because GitHub only uses Git (afaik)
  - dartos 3y ago
    I think they meant that many newer devs don’t really understand much about the giants whose shoulders they stand on. But I think that’s always the case with new devs anyway. Takes time to really learn any tool on a deep level
  - semiquaver 3y ago
    > doesn't allow to change backend they’ve supported subversion since 2010! https://github.blog/2010-04-01-announcing-svn-support/ https://github.blog/2010-04-01-announcing-svn-support/ The problem with abstraction layers is you are stuck with the worst common denominator of all supported backends. Presumably if you wanted to use a better version control system it would be for its advanced features git lacks. But a system that supported both would have a hard time taking advantage of any feature that was unique to one system.
yjftsjthsd-h 3y ago
> I honestly would have to research how to do a patch and I've been a professional dev since the mid-1990s. I guess I would ask ChatGPT? Because it's hard or because you've never done it?
- bhouston 3y ago
  Because I have never had to do it. All projects I’ve worked on the last decade were on github or gitlab. And prior to that on subversion and mercurial we just would merge branches locally. Back in the 1990s I used sourcesafe which had file locking checkouts and when I used sccs I was the only contributor.