<!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 >Yup, I learnt that lesson pretty well last night. A good lesson and am<br>happy about it.<br><br>Matt it is then!<br><br>Richie<br><br><br><br>----sergiokessler@gmail.com wrote ---- <br><br>richie, richie, richie, the fact that 4.2.x absolutely need a<br>mantainer, doesn't mean that this mantainer should be vtiger core<br>developers.<br><br>please, delegate as much as possible, this is one of the core lessons of OSS.<br><br>in fact, I would name Matt the official vtiger 4.2.x mantainer, and<br>let him decide when release things, while the vtiger core developers<br>keep cooking V5...<br><br>and last but not least, *don't expect* that a 4.2.4 release will kill<br>the problem, 4.2.x will need MORE releases, wanted or not, so 4.2.x<br>need a COMMITED mantainer, ready to crank releases for many months...<br><br>and it seems to me, that Matt is very capable to do that...<br><br><br>/sak<br><br><br>On 2/2/06, Richie <richie@vtiger.com> wrote:<br>> Hello!<br>><br>> I stand corrected. I was munching on the logic<br>> hence the delay in replying.<br>> We will come up with a Patch4 to solve the issues.<br>><br>> Tell me what would the release naming ought to be before<br>> I screw up<br>> yet again. JeffK, JLee, Matt ...? This is the time to<br>> get the KO punch in!<br>><br>> Well, I honestly did not expect to have a patch4 so<br>> we went ahead<br>> with the 5.0 development. There was no other intention. I<br>> guess,<br>> the lack of foresight in itself is a flaw so I<br>> take the blame for it.<br>> On a lighter vein, this is the first time some<br>> aristocrat made so much<br>> noise!<br>><br>> Coming to brasstacks, Matt, thanks for the faith.<br>> I am trying to get things done as fast as possible.<br>> Kindly be patient in the<br>> meantime.<br>><br>> We do need help in the following areas and will be glad<br>> to have some help<br>><br>><br>> Trac and SVN combo. (I still do not know either of<br>> these and what/how is the advantage by using the combo. We<br>> will provide the machine for these if need be. I guess, Mike/Matt can make a<br>> call whether we can use the forge machine for these purposes. An immediate<br>> response will be appreciated so that I can start finding the resources here)<br>> Forge<br>><br>> I guess, once all these are setup nice and proper, we can have some real<br>> good developments for all to see and I can take some breathers here.<br>><br>> Richie<br>><br>><br>><br>> ----mmbrich@fosslabs.com wrote ----<br>><br>> On Wed, 2006-02-01 at 21:43 -0800, Richie wrote:<br>><br>> > a) Let us hold our head above water for sometime<br>> more and wait for 5.0 to be<br>> > out. I do not expect that 5.0 will take till summer to<br>> stabilize. I do expect that it<br>> > will take at the max April to be out as of today. We<br>> are not going to pump<br>> > in any great features as we used to do earlier. So,<br>> that is a saving!<br>> ><br>> Are you serious? How can we leave such a lame duck<br>> out there? Call me<br>> old-school but I think 5.x should be halted until 4.x is fixed and<br>> stable enough to keep people off your back while you<br>> work on 5.x.<br>><br>><br>> > b) The amount of effort going on to give patch4<br>> is not small and I feel<br>> > it is better to fix things on a case by case basis. I<br>> am trying here to make<br>> > things simpler and should have a plan by the end of<br>> the day. We can take<br>> > the fixes that we have put into the Dev3 release<br>> and integrate on top of<br>> > the 4.2.3 release or vice-versa. That should solve most<br>> of the issues. However,<br>> > I need to check the effort-estimate here.<br>> ><br>> That's fine, in this case I think considered cases<br>> should be any<br>> critical, showstopper or major bugs. As far as<br>> merging forward to<br>> something that has more bugs fixed than 4.2.3, great! Not<br>> many people<br>> wanted to start with our code base, which is fine, that<br>> was mostly a<br>> band-aide and we would have lost all the tracking<br>> info that should be in<br>> the SCM system right now. Anything that can be<br>> put forward that at<br>> least gets us a little bit a head of 4.2.3 _and_ has the<br>> check-in<br>> information would be great.<br>><br>><br>> > Please note, I repeat, all of this is simply because<br>> we did not intend to<br>> > release 4.2.4. This, is yet another on-the-run demand<br>> that we are facing, hence<br>> > it is painful. I do not deny that we did not follow<br>> proper industry wide standards<br>> > but we are willing to learn.<br>> I don't see how this is an on-the-run demand.<br>> Downloads have<br>> skyrocketed, forums posts are exploding, your user base<br>> is swelling.<br>> Now they get a lame duck security release and<br>> all development halts<br>> while 5.x is being cooked? I suspect someone spoke up<br>> about this<br>> already, had I been paying attention I would have<br>> made just as much<br>> noise, only sooner.<br>><br>><br>> > JLee and JeffK have been asking for the<br>> release namings changes<br>> > and we are working on those. We have changed the<br>> release naming as a start,<br>> > the source code naming was incorrect, I agree and<br>> proper action will be<br>> > taken to correct it.<br>> ><br>> Thats great because there is very little rhyme or<br>> reason behind the<br>> current naming convention and now package maintainers<br>> are starting to<br>> speak up. If we stop these folks from doing what<br>> they came to do, we<br>> can kiss a lot of users good-bye.<br>><br>><br>> > We are more than okay with having volunteers take<br>> up responsibility<br>> > for the release handling, bug fix handling , etc.<br>> The more hands<br>> > we have, the better it is.<br>> ><br>> I've already said that you can count me in as fully<br>> accountable for 4.x<br>> maintenance but I won't maintain this stream if<br>> it's going to be wrote<br>> off in favor of 5.x, which will have a breaking-in period<br>> of at least 3<br>> months and as long as a year before it passes for<br>> production use in most<br>> organizations.<br>> Some people will jump to 5.x right away, usually these are<br>> your early<br>> adopters, but what about the majority of other users<br>> out there that have<br>> spent a lot of time/money/both on custom mods or making 4.x<br>> 'just right'<br>> for their business? They don't even have the option of<br>> a support<br>> contract through vtiger right now let alone maintaining<br>> it on their own<br>> since the base they were depending on to merge<br>> back and pick fixes up<br>> from has gone dead.<br>><br>><br>> > Finally, I still respect you Matt. There is no 'hate'<br>> for you anywhere<br>> > only<br>> > respect. These are flaws that you pointed out in<br>> the system.<br>> > That is only fair.<br>> ><br>> I expected this response and this is exactly why I<br>> don't think this is a<br>> lost cause that has to fork. I know we can turn 4.x around<br>> and save<br>> everyone who has choose to support 4.x for their customers<br>> and users<br>> from having made a bad choice.<br>><br>> Matt<br>><br>> _______________________________________________<br>> vtigercrm-developers mailing list<br>> vtigercrm-developers@lists.vtigercrm.com<br>> http://lists.vtigercrm.com/mailman/listinfo/vtigercrm-developers<br>><br>> _______________________________________________<br>> vtigercrm-developers mailing list<br>> vtigercrm-developers@lists.vtigercrm.com<br>> http://lists.vtigercrm.com/mailman/listinfo/vtigercrm-developers<br>><br>><br>><br><br>_______________________________________________<br>vtigercrm-developers mailing list<br>vtigercrm-developers@lists.vtigercrm.com<br>http://lists.vtigercrm.com/mailman/listinfo/vtigercrm-developers<br></body></html>