(split) The "parser.lockfile" is blocking POP3/IMAP fetching

[NC Software]

Can we finally get 3.30 released? The heinous issues are mounting, it's time to wrap up your work and publish a STABLE folks!!!

[Jamie Edwards]

Originally Posted by NC Software

Can we finally get 3.30 released? The heinous issues are mounting, it's time to wrap up your work and publish a STABLE folks!!!

Neal; being a developer yourself, I am sure that you appreciate that when you rush out fixes and builds things go wrong and the quality is poor.

In most of your posts you claim that we do not pay attention to quality assurance in our builds; but here you are pressuring us to do just that.

Release candidates will be released, and the build will be quality assured.

[NC Software]

Originally Posted by Jamie Edwards

Neal; being a developer yourself, I am sure that you appreciate that when you rush out fixes and builds things go wrong and the quality is poor.

In most of your posts you claim that we do not pay attention to quality assurance in our builds; but here you are pressuring us to do just that.

Release candidates will be released, and the build will be quality assured.

Jamie,

As a software developer myself, as you know, I do know exactly what is involved. You have a stable release, at not time should this release go UNSTABLE to the point you can add a few features and release a hotfix, patch, or new stable. If you use a good source code control method such as trunks and branches, you are able to work on new development and then go back to a branch, make a few fixes and release a new stable that only have the necessary fixes. The fact that you all can go from a stable to an extremely unstable so fast is very concerning to me! The fact you can release a build as poorly as your last with the beta cycle you had is also shocking. Once again, try following your mentor, yeah, vBulletin, and learn from them. They use their own builds BEFORE the public gets them. You guys are completely opposite. You release something and then some distant time later update your own help desk. You haven't figured out yet why this is backwards - you would be aware of heinous issues such as the ajax drop downs IF YOU USED IT YOURSELF before ever pushing it out as stable!

You guys really need to read a few books on software production as you just aren't getting it right. You shut us down for two weeks, one from the lockfile issue, the other from a logging issue. When you cause a company harm, that should signal you its time to fix it. If you have so many pieces out of sync that prevent you from building a stable release within 24 hours, then you have a system that's pretty broke. Now if SS was never released and only in beta, that's a different story. When was the official release date of SS 3? And how long ago was that? Any why are we having these critical issues this amount of time later? Are you still working on the call center? Come on folks, let's get in gear here!

[craigbrass]

I agree with the fact that Kayako *SHOULD* use their own builds prior to releasing a stable and the reason why they choose not to is the fact that they have modified their help desk to allow the "Get Support" link to work in the members area.

In a few days I will be releasing an Integration API to allow you to list tickets and knowledge base articles from a third party product. Kayako should use this and then they won't have the above problem.

[NC Software]

I haven't been able to make that work.

I look forward to Kayako releasing 3.30 STABLE by Friday June 27th.

[craigbrass]

by Friday June 27th.

Where did you get that date from?

[Jamie Edwards]

Originally Posted by craigbrass

Where did you get that date from?

Neal is just making up deadlines for us. If he wants an unfinished, untested build by that date then he is free to download one of the nightly CVS builds available to everyone within their member's area.

[craigbrass]

Neal is just making up deadlines for us.

Isn't that your job Jamie?

[Jamie Edwards]

Originally Posted by craigbrass

Isn't that your job Jamie?

Nope - only the people writing the code can say how long something is going to take and what is required to do so. Someone else picking deadline dates is one of the fundamental causes of most major project failures and mistakes.

[John Haugeland]

Originally Posted by tparikka

it sounds like other bugs have been introduced that make upgrading a poor decision.

Upgrading to CVS is always a bad decision. The reason it hasn't been released is that it hasn't been tested yet. Some things in CVS are there in an incomplete state.

Unfortunately, it is common for people to choose to upgrade to CVS because they believe it will fix things, on grounds that our support staff is able to make controlled partial upgrades.

Please do not upgrade to CVS without staff support.

[NC Software]

1) Why would you make CVS available to the public then?
2) Why are you checking incomplete items into source code control?
3)

Someone else picking deadline dates is one of the fundamental causes of most major project failures and mistakes.

What the heck are you talking about? That statement makes NO sense. I guess then: I'm sorry everyone, the reason your SupportSuite is such poor quality and has so many bugs and interrupts your business is MY fault! LOL - that was funny! Thanks Jamie!

[Ryan Lederman]

Originally Posted by NC Software

1) Why would you make CVS available to the public then?
2) Why are you checking incomplete items into source code control?
3)



What the heck are you talking about? That statement makes NO sense. I guess then: I'm sorry everyone, the reason your SupportSuite is such poor quality and has so many bugs and interrupts your business is MY fault! LOL - that was funny! Thanks Jamie!

1. Because under certain circumstances, it can be beneficial to take one or two files from the CVS repository to patch a bug. This does not mean that CVS should ever be used for live installations and there is a warning when you download it to that effect.
2. Being able to check items in to source control in any stage of their development is the whole purpose of source control.
3. Jamie was referring to the fact that when people outside of the development team try to set unrealistic deadlines, bad things happen. I would tend to agree with him. Being aggressive and chastising this company so that we do your bidding will get you nowhere.

[NC Software]

Re: #1 - I would suggest not making builds available that cannot be used. If in the event you need to provide files to someone, that is what HotFixes are for. I think that's where you all are missing the boat here, there is NO reason that I can see that the ajax drop down issue could not have been resolved via a HotFix. You all are so deadlocked into STABLE releases and they are so far apart you're parallizing companies.

Re: #2 - Different techniques obviously. But typical practice is you don't put something back into source control until the task is completed and an error free build can be accomplished. Again, this is technique among the dev teams and obviously varies on what is being developed.

Re: #3 - The ridiculous and unfounded comment should have never been made.

Once again, I hope you guys will follow vBulletin, you have a great mentor. I believe their policy is an update once a month. Your update schedule leaves us vulnerable to security problems such as the latest XSS issues which I'm sure SS is vulnerable to. The comments system being as wide open as it is lends to a huge security threat.

[craigbrass]

1. I disagree. Having CVS builds available allows people to do testing on a none-production environment.
2. General development practice is to commit after every bug fix / feature implementation and after the implemented functionality has been tested.
3. This comment Jamie made was in reference to me saying I thought it was Jamie's job to do so. He then responded and said the development team pick the deadlines.

[GoneShootin]

1. Storm
2. In a
3. Teacup