4 ms·

I am actually going to attempt to get them merged in, that's what I am saying on linked wiki page. I am just saying it might be not easy to push them there.

• jerf 17y ago
  Are you just keeping this patches in a public tree so others can get to them, with every intention of handing them to the Erlang project, but keeping them separate and available should the Erlang project not choose to use them (and of course they can't release a patch "tomorrow")? I ask because if that's the case and you say so, it should clear up the criticism seen in this discussion. I'm not sure the community at large has internalized what github means for that sort of thing; the days where you had to take your patch to the project and that was both your first and essentially last resort are gone. There's nothing wrong with the workflow I outlined above.
  • yrashk 17y ago
    Yes, there is an intention to push these patches to Erlang project, I was just saying that it might be hard.
  • davidw 17y ago
    > the days where you had to take your patch to the project and that was both your first and essentially last resort are gone. They were never here. It's always been easy to fork a project, or put patches up on a web page or whatever. git makes it a little bit easier, but it doesn't change the dynamic of participating in a community much: you have to send in a patch, explain what it does, why it does it, what problems it fixes, what it improves, what costs or side effects it may have, and so on. If you send in something big (either in terms of code or effects), and care about getting it included, you may have to modify it or be prepared to defend it or otherwise work on it. git/github are not a magic replacement for this communication. Sure, you can just put stuff up on github and call it good, not caring what happens to it, but that doesn't really drive things forward as much as interacting with other people to reason about what's going on.
    • jerf 17y ago
      "They were never here. It's always been easy to fork a project, or put patches up on a web page or whatever." Yes, but simply making it easier does change the dynamics. Putting up patches that way invokes a completely different dynamic than just lobbing onto a webpage somewhere as a .patch, to wither and die when you couldn't keep them up-to-date, which what usually happened to unfavored patches. Forking a project is possible but a lot larger task than a git fork. I fully recognize that there isn't any bright line between what you could do in 1999 and what you can do now, but the enough quantitative change becomes a qualitative change. It's easier to maintain the patches, easier to publish them, easier to audit them, easier to grab them and still have source control over the newly-forked copy, and all these "easier"s add up.
      • davidw 17y ago
        Sure, it's easier and nicer and whatnot, but the way I look at it is that git is a nice patch management system, but you still have to do the 'community stuff'. You still have to decide whether you actually want to fork the project, or not. Forking a project is different from simply creating a version control 'fork' - it means you're actively taking the project in a new and different direction than the current maintainers.