<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body >Well, well, /sak, hold on!
<br>We do have interest in the 4.2.x series. Have a heart sak, it is well enuf difficult to maintain 5.x ;-)!
<br>
<br>Richie<br><br><br><br><br>---- Sergio A. Kessler<sergiokessler@gmail.com> wrote ---- <br><br><blockquote style='border-left: 2px solid #0000FF; padding: 6px;'><html>
<xbody>
Mat,<br><br>v4.x would not be abandoned while there is people interested in<br>maintaining it, that's all needed in open source, interested and<br>executive people...<br>it can be mantained forever while this condition is met...<br><br>and I agree with you that there was (is ?) an utterly lack of<br>receptive response to community developers from the core team, and the<br>project was crying for a fork, but all those people creating private<br>forks also lacked the balls to create a serious *public* fork...<br><br>I mean, if you are going to fork, then fork in all it's glory...<br><br>those people that never submitted a patch, never figthed for more open<br>development, created their own private branch, and then came up here<br>whining, are ... well, whiners IMO<br><br>those who want to mantain v4.x just need to step up and do something about it...<br><br>cheers,<br>/sergio<br><br>On 7/11/06, Matthew Brichacek <mmbrich@fosslabs.com> wrote:<br>> > [snip]<br>> > ><br>> > > Our current installation is a heavily-modified (and I do mean HEAVILY)<br>> > > modified 4.3.2 installation. To be honest, I painted myself into a bit<br>> > > of a corner with the way I implemented our code changes, such that<br>> > > upgrading to newer versions is a formidable challenge.<br>> ><br>> > this is a mistake many people do.<br>> > you have choosed to fork the project instead of trying to work with<br>> > the community.<br>> ><br>> > and all this people end up in the same corner as you... :-)<br>> ><br>> While I would normally agree 100% with Sergio on this point, I think we<br>> need to take the history of this project into consideration and maybe<br>> look at the bigger picture.<br>><br>> There was a point in this project where you could come along, see a<br>> project with a fairly vibrant community forming, an interesting product<br>> being developed and a complete lack of direction and management. This<br>> type of environment is ripe for internal forks and the fact that the<br>> project didn't fork into a new OSS project is nothing short of a miracle<br>> (seriously!).<br>><br>> I think Dennis is just the first one to cry out for help publicly, there<br>> are probably many more out there like him (I know of 6). The system<br>> integrators had a choice to make... Stand behind the OSS project in all<br>> it's glory and be at the mercy of a project with no direction or<br>> leadership, or fork and be in charge of their own destiny. While in<br>> most cases I would say you're loony for privately forking a strong OSS<br>> project, in those cases I would say it was a justifiable move (i'm<br>> biased of course).<br>><br>> Ok, so there have to be a _ton_ of cool features and ideas floating<br>> around in all these private forks and I think the project managers<br>> should make a full effort to get these integrators back into the<br>> community and help them get their features in 5.x. Why not put them in<br>> 4.x? Here are the options as far as I see them for people who have<br>> forked from 4.x:<br>><br>> 1) Keep running with your own 4.x fork even after the community drops<br>> 4.x in favor of 5.x. Good luck, have fun, and let us know how that<br>> works out :).<br>><br>> 2) Submit patches for all your features into 4.x, get them integrated,<br>> then submit them for 5.x (or hope some wonderful soul did it for you).<br>> If you have to submit them yourself after you've done 4.x, chances are<br>> you will miss the final release of 5.x and will be in a stable period<br>> that may be harder to get your features into.<br>><br>> 3) If not already done, stabilize your 4.x fork and get busy forward<br>> porting everything to 5.x. You'll need to create your own upgrade path<br>> for your company/customers but IMHO you're chances of success are better<br>> in this case. Some of your features may not be accepted, but maybe the<br>> underlying framework that you need to enable those features can be, or<br>> if you're lucky, the API will do what you need (don't hold your breath).<br>><br>> It really comes down to options 2 and 3, and who wants to double all<br>> their work when you know damn well that 4.x is going to be abandoned now<br>> that 5.x shows the promise it does. And I mean that with absolutely no<br>> disrespect for the people working hard on maintaining 4.x for the<br>> community. Will 4.x be maintained forever? I highly doubt it, once 5.x<br>> stabilizes and upgrade paths are figured out we'll certainly want those<br>> developer resources moved to 5.x right?<br>><br>> About code comments:<br>> I'm in no position to preach about code comments, but I am getting<br>> better at it (code comments that is :). What I think we could use _way_<br>> more than code comments is a sane API with at least _some_<br>> standardization and logic to it. But I don't have the time to do it or<br>> fix the millions of things that will break, so I'll just shut up now.<br>><br>> Matt<br>><br>><br>><br>> _______________________________________________<br>> Get started with creating presentations online - <a href="http://zohoshow.com?vt">http://zohoshow.com?vt</a><br>><br>_______________________________________________<br>Get started with creating presentations online - <a href="http://zohoshow.com?vt">http://zohoshow.com?vt</a> <br>
</xbody>
</html></blockquote></body></html>