Hello,

I just received my copy of Linux Journal:
Issue 185 with the 5-page Lazarus article by Mattias Gaertner.

After many years, finally Lazarus in Linux Journal, I thought I'd never see the day :-)

Good job, Mattias !

Michael.

Thanks.

I'm eager to receive my copy.

Mattias

There is no competition from the other articles.
Only Qt comes more or less close.

The Titanium IDE looks nice but is a misguided attempt at cross-platform development.

Michael.

You Serious !?! They didn't send you a complimentary copy.

I think now would be a great time to release 9.27 to really keep anyone testing it out. I we don't place 9.27 up front now I feel it will be a wasted opportunity.

IMO this is big news. Please get the best build out on the website. If I could stress this enough I would. I liken 9.26 to Delph 5 an 9.27 to Delphi 7. It's very important not underestimate the power of press. Its can be like body surfing on the beach.... If you miss the wave Lazarus may need another 2 years to catch another wave. The Ubuntu repositories should be updated as well.

In the future it probably would have been better to coordinate with a release team and hold off on issues until after a major version increase...

Congrats on all the hard work and good writing.

Andrew Brunner wrote

hold off on issues until after a major version increase...

What do you mean by that?

Anyway, we (at least I) started working on a new release almost 4 months ago: http://lazarus-dev.blogspot.com/2009/04/no-updates-on-0926-fixes-branch.html

Vincent

Hi Vincent, I mean that having the 9.26 release on the website when 9.27 from SVN is so much better by any standards, press should be held off until the PRESS AND VERSION are at the same time. I would have liked new comers to see the 9.27 version. 9.27 is totally improved over 9.26 and I feel that it is best to hold off (wait) on the publications to major readerships.

A much better version just sitting in subversion - many new leads will never see the latest and greatest. And I assert the BEST version of Lazarus ever produced should be seen.

I just checked the Lazarus site and I still see 96 as an offering...

This is more of a marketing issue than anything... But all marketing should be done in concert with development. And I am trying to get a point across that if Lazarus team knew of the article, we should have worked to get a latest and greatest pushed out the door. A best face on Lazarus if you will.

Anyway, we (at least I) started working on a new release almost 4 months ago: http://lazarus-dev.blogspot.com/2009/04/no-updates-on-0926-fixes-branch.html

Sweet. How much effort does an "Automated" build process take to developer so on a whim, with a good codebase a Lazarus team member could generate an interim Release like say 9.27 :-)

Andrew Brunner wrote

Sweet. How much effort does an "Automated" build process take to developer so on a whim, with a good codebase a Lazarus team member could generate an interim Release like say 9.27 :-)

Click on "Daily snapshots" and end up here:
http://www.hu.freepascal.org/lazarus/

Vincent

I know how to get the latest and greatest. What I'm trying to convey is that Ubuntu and other Linux offerings are bringing people under their wing away from Windows. Packages, RPMs, Repositories, SubVersion, Apt-get Install, All unknown and scary to an new age linux user.

We need to have a good download page with the latest and greatest release, organized so an idiot will download and install the best version we got.

Meaning I think it's Lazarus has interim releases that supersede prior versions. At this point ANYTHING is better than 9.26. And I'm sure more and more improvements will be made. I just want people to be able to see them so they don't write off the entire project.

I'd rather not release a product that destroys files, even it looks great: http://bugs.freepascal.org/view.php?id=14167
and maybe:
http://bugs.freepascal.org/view.php?id=13931

Vincent

True. Nobody wants their code deleted. But with good Q/A an interim release could be flagged for critical bugs to be resolved prior to kicking off any release. And you could argue that at least one of those bugs justifies a critical flaw that needs to be addressed prior to the kick off.

Bug tracking should be able to report all critical flaws and be cleared out by the community. Could actually speed things along if you think about it.

Take the present opportunity, for example as if we did have interim releases.

Someone suggests interim release.

Automated system checks for critical flaws.

Emails go out to mailing list regarding laws that are blocking an interim release. Pleading with the community that hey... We help with these two things... Please help... you get the point... An escalation of awareness to the community as time goes on...

Just my thoughts on how to make things better...

I fear I cannot follow you. Since two months or so, we want to make a release. We have identified critical bugs and regressions that we want to resolve before the release and marked them with the 0.9.28 target. Do you say we should start a release anyway, even if it these critical issue have not been fixed? What do you mean by "kick off".

Bug tracking should be able to report all critical flaws and be cleared out by the community. Could actually speed things along if you think about it.

Goto http://bugs.freepascal.org/view_all_bug_page.php, select the Lazarus project and choose the "target 0.9.28" filter/

Please, provide patches for the remaining 10 0.9.28 issues and we start release building tomorrow.

Vincent

El jue, 06-08-2009 a las 13:26 +0200, Michael Van Canneyt escribi?:

Oops, my last mail was suppose to be a answer to this thread, sorry.

If its possible and legal, somebody can scan it to share with the rest of us?

Cheers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090806/454b1b80/attachment.html>

The bug tracking software would need to include a flag for a bug that would cause the build process to be blocked. Critical bugs are not ones that can be carried over to the next release. A "Stop-Release" flag are from flaws that cause data corruption or crashes in the IDE, or any others that someone else can suggest here.

I see a "Major" tag assigned to a scroll key getting stuck. To me, this is not "Stop-Release" kind of bug but it is listed as a Major flaw. While this flaw was marked as "Major" it should never be flagged as a "Stop-Release" flag.

Please, provide patches for the remaining 10 0.9.28 issues and we start release building tomorrow.

I am going to help pound out a few of those bugs. But I think before I start I would like to know my efforts are being applied to a concerted endeavor. So, how difficult would it be to examine all of those issues and sift through them, assigning a "Stop-Release" flag to them. Certianly, an interim release would not have to have all bugs resolved... Just the "Stop-Release" ones.

Q: Out of all outstanding bugs... How many would be "Stop-Release" flagged ?

A somewhat related but completely uninformed suggestion: what about making the next release 0.10.0?

-Fl?vio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090806/02129ceb/attachment.html>

All bugs in the 0.9.28 section stops the release of 0.9.28. They are all stop-release bugs.

Critical bugs are not ones that can be carried over to the next release. A "Stop-Release" flag are from flaws that cause data corruption or crashes in the IDE, or any others that someone else can suggest here.

Most regressions are also critical for a release.

It's a pretty annoying bug, but luckily it appears only on few machines. So the "Major" depends on pov.

All.
If a bug's annoyance level can be lowered far enough or if no good fix can be found, then it can be moved to the next version.

Mattias

On Thu, 06 Aug 2009 15:43:02 +0200, Giuseppe Luigi Punzi wrote about Re: [Lazarus] Linux Journal article:

[snip]

If its possible and legal, somebody can scan it to share with the rest of us?

Linux Journal usually makes its articles available from its Web site a couple of weeks after the paper publication has been sent out. There should be a URL available some time soon.

Mattias Gaertner wrote

All bugs in the 0.9.28 section stops the release of 0.9.28. They are all stop-release bugs.

I am going to say this for the benefit of all when I say that this should not be the case. Taking months if not years between releases makes this project look untouched, outdated, and dead. I for one think it's come far enough to have quarterly releases.

No. I disagree. It should not stop the of
views are not relavent in a "Stop-Release" flag. If adopted, we should come up with a specific criteria for such a flag. Data corruption would be primary candidate - or Test if you will.

I think that a work in progress (Agile) with quarterly release schedules would certainly benefit the project as far as repeat visitors and prospective contributors.

All wish that we release more often.
But a release is a lot of work.

Speaking for myself: I had far less time in the last few months.

The POV is about 'Minor' or 'Major' and is merely an indicator. The release tags are set by the developers, when they think a bug is grave enough.

About this particular bug:
There were several tries to fix this bug. One of them made it better for some users and worse for others. Under ubuntu switching to another app and back made the IDE mad. You
used a short cut or clicked somewhere and something completely different happened. For short-cut junkies this resulted even in data loss. After some more fixes this now only happens on a few systems and less worse.
That's why it is major.
Of course for the majority this bug was never a problem.

True.
OTOH:
Releases with regressions will make the existing users unhappy.

Mattias

From an agile point of view, we are releasing almost daily (sometimes a build is broken or something goes wrong with the build machine) with the snapshots.

Ideally, I would like to release every 6-8 weeks. That is unrealistic now, so I aim for once every 3-4 months, which usually gets at least 5-6 months.

What gets into a release:
* all fixes for bugs that are regressions, things that worked with a previous release. This one is harder now than usually, because of the switch from gtk1 to gtk2, some things did work on gtk1 better than one gtk2 (most things it is the other way around, so I have heard).
* patches that are submitted enough time before a freeze (patches that have been submitted in the last month or so, got the target for 0.9.30). Patches usually won't block a release and are postponed rather easily.

If you think you can manage a quarterly release, you should have taken over the fixes 0.9.26 branch (last paragraphs of
http://lazarus-dev.blogspot.com/2009/04/no-updates-on-0926-fixes-branch.html). You could have maintained that and I would even allow you to merge most of trunk to it, if you as a maintainer felt that was a good decision. I think the offer is still valid.

Vincent

Mattias certainly has all the material, but he may be bound by his contract with the Linux Journal. He might be allowed to publish his article in the FPC site, after a certain time.

DoDi

On Thu, 06 Aug 2009 15:43:02 +0200, Giuseppe Luigi Punzi wrote about Re: [Lazarus] Linux Journal article:

[snip]

If its possible and legal, somebody can scan it to share with the rest of us?

Try the following URI:

http://www.linuxjournal.com/article/10502

I just got a notice from Linux Journal that the article is available online at the following url.

http://www.linuxjournal.com/article/10502

Regards,
- Graeme -