Hi all,

does the FPC 2.4.x should / must / need to build the latest stable version of Lazarus ( currently
0.9.28.2 ) ?

Is there a plan for a simultaneously release for both FPC 2.4.2 and Lazarus ( let's say 0.9.28.3 ) ?

regards,

Dimitrios Chr. Ioannidis wrote

does the FPC 2.4.x should / must / need to build the latest stable version of Lazarus ( currently 0.9.28.2 ) ?

lazarus 0.9.28 is based on fpc 2.4.0. No guaranties that it will work with 2.4.2

Is there a plan for a simultaneously release for both FPC 2.4.2 and Lazarus ( let's say 0.9.28.3 ) ?

Probably in a month after the fpc 2.4.2 release we will try to release the next version.

Until then is better to test what we have in the trunk and report regressions.

Best regards,
Paul Ishenin.

.28 or .30?

Marco van de Voort wrote

.28 or .30?

Possibly not .28 and not .30

Best regards,
Paul Ishenin.

Paul Ishenin wrote

Possibly not .28 and not .30

1.0 then? :-/ I'm all for the 1.0 release, but with the many regression bugs I found recently, that would worry me.

Graeme Geldenhuys wrote

but with the many regression bugs I found recently, that would worry me.

All reported regressions bugs must be fixed before any release.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

19.05.2010 21:45, Graeme Geldenhuys wrote: > but with the many > regression bugs I found recently, that would worry me. All reported regressions bugs must be fixed before any release.

It is all normal that snapshot/SVN-trunk code does have regressions, and while it is always good to have some people using it, and help reporting them.
(even so sometimes the reports sound more like a complaint, which is hard to understand, since why would you complain that something broke, if you went there *after* having been told that it will break?)

But despite this Graeme is right on his point: In the past couple of month several big changes where made, that from all we saw so far, have introduced a particulary high amount of those regressions.

As it stands currently, I am not 100% convinced, that not quite some of them may only be reported *after* the next release (Since not every user uses trunk).
Otherwise, we need to find a way to convince more people to test before we release. Some form of pre-release, but I think no one (who doesn't use trunk anyway) will test it unless it can easy and safely be tested without interfering with their stable installation.

Martin

Martin wrote

As it stands currently, I am not 100% convinced, that not quite some of them may only be reported *after* the next release (Since not every user uses trunk).

This is exactly the point I was trying to get across. I for one do not use Trunk as much as I did in the past. Simply because I am losing a lot of productivity in my day-to-day work fighting with bugs that did not exist before. Similar issue apply to FPC trunk.

I report 90% of what I find, but I fear other see me then as a nagging person always finding fault. This is unfortunate. Maybe it's just because I use Lazarus IDE in a commercial environment, and not as a hobby (like most developers here - I think). When I do use Trunk I don't expect everything to work, but I also don't expect so many regression bugs. Instead I would expect new features to have bugs, not old/existing features.

release. Some form of pre-release, but I think no one (who doesn't use trunk anyway) will test it unless it can easy and safely be tested without

The solution is simple. Create at least three rc (Release Candidate) releases. This will greatly improve the stability of a final release without the need for many point releases. Everybody in the software world knows that rc release can contain some bugs and will probably be fixed before the final release. But then I guess the argument starts, that releases take to long to create. In the world of software development that could, and should be streamlined, and never be an excuse.

FPC uses release candidates; We usually get very little response;
But maybe that's because the released versions are near perfect ;-)

Michael.

It may be so ;-)
But it may also be the fpc alone doesn't have enough visibility, and there should be some coordination with lazarus, like lazarus making new releases only to include the new fpc if for anything else (and daily laz snapshots include rc fpc versions when available).

Best regards,
Fl?vio

IHMO, snapshots about a week before a release can be considered release candidates.

Vincent

Vincent Snijders wrote

IHMO, snapshots about a week before a release can be considered release candidates.

The same way as current fpc 2.4.1 snapshots can be considered fpc 2.4.2 release candidates.

Vincent

Martin wrote

Otherwise, we need to find a way to convince more people to test before we release. Some form of pre-release, but I think no one (who doesn't use trunk anyway) will test it unless it can easy and safely be tested without interfering with their stable installation.

Every time a month before the release I ask the russian community to check the comming version for regressions. This practice always helps to find more bugs than bugtracker has and to release a more stable code.

Best regards,
Paul Ishenin.

???? 19/5/2010 9:36 ??, O/H Vincent Snijders ??????:

AFAIU, the fpc 2.4.2 is a maintenance release of the 2.4.0 branch. If i'm correct, no new features ( except maybe very small ones which don't break the compatibility ) and only bug fixes backported or not.

Being more involved, some time ago, with other open source project ( relative big all is in the ey of the beholder ), i assume that this maintenance release will have a smaller Release Candidate cycle. After all, it's all about fixing regressions and bugs. But, it will have one, right ? The "take the snapshot as a Release Candidate" is not an option for me.

The Alpha, Beta, RCx, Release, Maintenance cycle is a must if you care about your users. The people who use your product. Don't make them chase a moving target. If you need to break something do so. In another major or minor release. Not in maintenance releases.

regards,

???? 19/5/2010 4:47 ??, O/H Paul Ishenin ??????:

19.05.2010 21:45, Graeme Geldenhuys wrote: > but with the many > regression bugs I found recently, that would worry me. All reported regressions bugs must be fixed before any release.

Because ' ... it's difficult for a programmer to figure out how a change in one part of the software will echo in other parts of the software.', I agree.

But in this case, we're dealing with two different but closely coupled systems / software projects, fpc and lazarus. IMHO, if we assume for a moment that FPC and Lazarus is one entity, we need to test the latest stable release of Lazarus with the RC of the FPC, cause the FPC is what we change, playing the roll of a "new feature" or a "bug fix".

After all, "Regression bugs occur whenever software functionality that previously worked as desired stops working or no longer works in the same way that was previously planned. ".

If the plan of the Lazarus 0.9.28.2 release, is to work only with the 2.4.0, then mea culpa.

regards,

It is roughly that way for the compiler source.

With the RTL (except some of the deeper regions) and packages we are a bit less strict. (because otherwise it would take a major cycle for minor improvements to reach users). A fix typically sits a few weeks to several months in trunk before it is merged to fixes though, depending on complexity and risks.

maintenance release will have a smaller Release Candidate cycle. After all, it's all about fixing regressions and bugs. But, it will have one, right ? The "take the snapshot as a Release Candidate" is not an option for me.

It takes only one failure to break a release, and release candidates are about making sure that doesn't happen.

That said, fixes releases are indeed faster, but that has mostly to do with the fact that major releases are the first releases of a branch that hasn't seen releases yet. Thus there are often a lot of little release engineering things to fix. Specially for the rarer platforms that often only see major activity around a release (since they are threathened to be cut from it).

It is often more the release engineering and the waiting till all platforms are built that eats the time of RC cycles and delays releases time and time again, and less bugs discovered during release cycles (which happens, but are not that much responsible for delays)

The Alpha, Beta, RCx, Release, Maintenance cycle is a must if you care about your users. The people who use your product. Don't make them chase a moving target. If you need to break something do so. In another major or minor release. Not in maintenance releases.

Do you care about users? Do you volunteer for release engineering? We always have a few spots open?

Michael Van Canneyt wrote

FPC uses release candidates; We usually get very little response; But maybe that's because the released versions are near perfect ;-)

:-) Just remember that Lazarus introduce a lot more changes that FPC between releases. So by a huge margin, Lazarus has a lot more new code that needs testing. Also FPC at least has some type of testing framework, Lazarus has none.

Vincent Snijders wrote

IHMO, snapshots about a week before a release can be considered release candidates.

A week is not nearly enough time to test the amount of code and changes in Lazarus IDE and Lazarus LCL (and all it's many backends). fpGUI has a fraction of the code Lazarus has, and fpGUI has already been in a v0.7 release candidate state for over a month and still I find one or two minor defects. Yes, not all bugs will be found no matter how long you test, but thinking a week is enough for something as large as Lazarus is very optimistic (and totally unrealistic).

???? 20/5/2010 2:04 ??, O/H Marco van de Voort ??????:

... < me picking up the gauntlet > ...

I'm putting my money where my mouth is. I've done it before, i'll find time to do it again for FPC.

Shoot ...

regards,

Graeme Geldenhuys wrote

but thinking a week is enough for something as large as Lazarus is very optimistic (and totally unrealistic).

The next version will not be final. It will be still beta. And then we will have at least 3 RC.

Best regards,
Paul Ishenin.

Regardless of any Lazarus releases, IMHO
if maintenance release of FPC 2.4.2 is incompatible with 2.4.0, this is, by definition, a bug in said maintenance release and should be fixed.

This is exactly the point I was trying to get across. I for one do not use Trunk as much as I did in the past. Simply because I am losing a lot of productivity in my day-to-day work fighting with bugs that did

?>not exist before. Similar issue apply to FPC trunk...

I agree with that.

When ready version of Lazarus, appears a new version of GTK or QT, with new bugs, which affect Lazarus. The new version of Lazarus fix them, but appears a new version of GTK or QT and the cycle continues indefinitely. Or computer have a new version of GTK or QT, which Lazarus don't discover them. Most mails in this list are due to problems with GTK or QT. Do you know what is latest version of Lazarus, using only FPC without Gtk or QT?

?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/053633ea/attachment.html>

Marco van de Voort wrote

Do you care about users? Do you volunteer for release engineering? We always have a few spots open?

Is there a list of who does what for each release so we can see what spots are open?

For a new release http://wiki.freepascal.org/Release_Template needs to be copied and adapted, for 2.4.0 it looked like
http://wiki.freepascal.org/Release_2.4.0

Currently, there is a list of routine stuff to do. Most is done by the release manager (Joost for 2.2, me for 2.4), but others work on that list too (e.g. Jonas did a lot of the grunt work for 2.4.0)

For the rest there is every platform builders own responsibility.

Most delays come from the actual build steps, specially .deb and .rpm always delay. It would really make releasing more painless if that was already somewhat finished and tested if the release process starts.

(and I plan to branch 2.4.2 and do some of the bits on the list this weekend or next)

Hey, that's interesting. ;)

Most work is building the releases, but for that you almost always need some knowledge about the build process. So I think that's hard for a relatively outsider.
Other hard task is getting the maintainers to actually perform the builds. But that's also hard for some new people.

But maybe it would be very useful if you help with the basic testing. When a release is build (relatively simple) you always have to test it on an 'empty' system. You could help with that.

And, offcourse, you could try to build a release right now, using the fpc-2.4.1 branch. For as many as possible releases. Marco has posted url which explain how to do it. And report all problems you encounter. So that the chances that 'we' encounter them when we are building the official releases, don't have any problems.

That would be a big helper.

Joost.

On Thu, 20 May 2010 11:40:09 +0200, Joost van der Sluis wrote:

< snip >

I'm already in the process of setting up a box with VMware ESXi 4. It will be a
test bed and a build farm machine. It has a lot of RAM and is powerfull enough to
serve that purpose.

Is it possible to give me a list of OS's you think i can help ? I can do Linux,
Windows (win32, win64, wince) and some OSX ( I also have installed hackintosh 10.5.8 on my machine on a spare disk ... )

regards,

What targets can you build? Can you make sure that they remain buildable, and are updated with changes between releases?

Hackintosh could be easy for the first test, but I doubt Jonas will accept a release of fpc build on it. ;)

Take a look at the download-page of freepascal. What I miss is Linux 32 and 64 bit. (rpm and deb based. Plus our own installer in .tar format)

And FreeBSD (32 and 64 bit, Marco?), arm-linux.

Joost.

On Thu, 20 May 2010 12:19:27 +0200, Marco van de Voort wrote:

< snip >

What targets can you build? Can you make sure that they remain buildable, and are updated with changes between releases?

Ok, i probably miss something.

Can i ask what exactly are the project needs ?
If you need someone to package, do some tests and produce the releases then it has nothing to do with the second question IMO.

Can you elaborate plz ?

regards,

I'll take a look and inform what i can done for those OS's.

PS: For arm-linux i can give a try with my gumstix verdex pro XL6P, but i never tried something like that with that COM.