Comments on: Understanding Open Source http://wagenknecht.org/blog/archives/2009/05/understanding-open-source.html Me, my family, whatever I like, whatever I want to write about! Wed, 25 Jan 2012 06:51:36 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Doug Schaefer http://wagenknecht.org/blog/archives/2009/05/understanding-open-source.html/comment-page-1#comment-13467 Doug Schaefer Sun, 17 May 2009 20:55:39 +0000 http://wagenknecht.org/blog/?p=228#comment-13467 Exactly. And that's why git is so important. It lets you manage your modified version and sync it with the upstream until you're modifications get there. Exactly. And that’s why git is so important. It lets you manage your modified version and sync it with the upstream until you’re modifications get there.

]]> By: frlan http://wagenknecht.org/blog/archives/2009/05/understanding-open-source.html/comment-page-1#comment-13466 frlan Sun, 17 May 2009 20:18:21 +0000 http://wagenknecht.org/blog/?p=228#comment-13466 100% correct. It just doesn't matter if it is bug or feature request. Also it doesn't matter whether its a library or a end-user tool -- FOSS projects needs input from users. And with feedback I don't think of "All the crap is not working" at regulars' table. 100% correct. It just doesn’t matter if it is bug or feature request. Also it doesn’t matter whether its a library or a end-user tool — FOSS projects needs input from users. And with feedback I don’t think of “All the crap is not working” at regulars’ table.

]]> By: Alex Blewitt http://wagenknecht.org/blog/archives/2009/05/understanding-open-source.html/comment-page-1#comment-13464 Alex Blewitt Sun, 17 May 2009 10:23:28 +0000 http://wagenknecht.org/blog/?p=228#comment-13464 The problem with this is the associated cost of keeping up to date with other fixes versus the cost of your change. For example, I filed a bug against EFS/Path back against the 3.3 days: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160809 I've had to build that internally and re-patch each major version of Eclipse that comes out because it's not been integrated into the upstream system. One of the reasons why people pay support contracts is as an option to buy such fixes and ensure that they get fed back in. Distributed version control systems (like git) will make this much less painful. You'll still be able to update to the latest and build the system whilst letting the DVCS do the work for you (instead of you having to maintain a CVS branch and do the merges yourself). I wonder whether that will help increase the back-flow of patches upstream or inhibit it? Alex The problem with this is the associated cost of keeping up to date with other fixes versus the cost of your change. For example, I filed a bug against EFS/Path back against the 3.3 days:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=160809

I’ve had to build that internally and re-patch each major version of Eclipse that comes out because it’s not been integrated into the upstream system. One of the reasons why people pay support contracts is as an option to buy such fixes and ensure that they get fed back in.

Distributed version control systems (like git) will make this much less painful. You’ll still be able to update to the latest and build the system whilst letting the DVCS do the work for you (instead of you having to maintain a CVS branch and do the merges yourself). I wonder whether that will help increase the back-flow of patches upstream or inhibit it?

Alex

]]>