Tag Archives: feature freeze

cURL and libcurl, libssh2

A new year with new fun

2 Comments

I had a great and relaxing winter/Christmas holiday and hence my silence here.

I’m now back up to speed, with a podcast interview done yesterday (I’ll post another entry when it gets available), I do some funded development on libcurl and libssh2 in the background while I’m spending my days at my client’s place working on a 10G traffic analyzer product.

It was rather calm during “the break” but I’ve now noticed that at least the curl project has gotten significantly increased activity again. We’re on a feature freeze now for the January release, but there seems to be at least 4 patches pending adding new stuff for the release planned to come after this (around March if things go well).

cURL and libcurl

curl feature freeze on August 10

In order to get the next curl release done, we’re entering feature freeze on Sunday August 10 (at 00:00 UTC to make it specific).

Starting then, we add no new features for the upcoming two weeks but we only fix bugs. At the end of the two week period, or possibly before that if all looks well, we release 7.19.0.

The work on CURLOPT_POSTREDIR and the “Limiting IP addresses” work can of course continue but if we don’t have working patches for them very quickly, they’ll have to wait for next release.

cURL and libcurl

curl feature freeze March 20 2008

It is yet again time to pause the add-new-features-craze in order to settle down and fix a few more remaining bugs before we go ship another curl and libcurl release in the beginning of April.

cURL

So at March 20 we hold back and only fix bugs for about 2 weeks until we release curl and libcurl 7.18.1.

The only currently mentioned flaw in TODO-RELEASE to fix before this release is the claimed race condition in win32 gethostbyname_thread but since the reporter doesn’t respond anymore and we can’t repeat the problem it is deemed to just be buried and forgotten.

Other problems currently mentioned on the mailing list is a POST problem with digest and read callbacks and a mysterious bad progress callbacks for uploads, but none of them seem very serious and thus terribly important to get fixed in case they should turn out hard-to-fix.

Yes, I picked the date on purpose as that is the magic date in this project. Especially this year.

cURL and libcurl

curl 7.18.0 feature freeze

2 Comments

Feature freeze!I just mailed the curl-library list about us entering feature freeze for the upcoming 7.18.0 release. The plan is to have two weeks of bug fixing and time to allow people to find bugs, before we release it to the public. Please get a daily snapshot and give it a spin!

Here’s the changes that’ll be coming:

… and there are 26 bug fixes mentioned in the RELEASE-NOTES in progress so far!

Rockbox

The Agony of Release

2 Comments

In the Rockbox project we haven’t had an official release in several years. We have >400K lines of code, some 60 committers. Some 300 patch contributors. At least 10,000 users, but probably up to 10-20 times that number.

We produce binary downloads after every single commit. We provide daily builds with a 30 day backlog. We provide a UI-based installer that can install the latest package for you.

So, we have a fair setup that provides releases in a fine way to everone interested. What we don’t have is a stable offer. Nobody can get a recent “stable” release (with a set of known bugs) or similar. We only have this endless series of “beta”-releases. We don’t have any particular push for doing a “real” release and among the developers there aren’t that many who think making releases is any fun, so we’re not really striving towards that.

The last time we tried to put together a release (to be called “3.0”) we decided to have a feature freeze period in which we’d only commit bug fixes and not do any new features. This lead to that most people simply stopped committing and developed their new stuff on the side, waiting for the freeze to go over. Only a few people did any actual bugfixing while we had some pretty serious flaws still in the code, so even with extended freezes we just couldn’t get the bug count down to a satisfiable level… we ended up just dumping the idea of a release 3.0 at that time, and it left some scars in the community that has so far prevented us from returning to this topic.

Rockbox

This said, today we’re more than 18 months further down the road, Rockbox runs on many more platforms, lots of code has changed and been improved since the previous 3.0 effort. Maybe it is time to once again make a release-attempt?

I think there are a few preconditions we need for this to succeed, including:

  • We need a single release manager person who single-handedly can decide when the release is finished. This person would also have the final say on the outstanding-issues list etc. We can’t manage to get consensus among this large amount of people for this black-and-white style of questions.
  • We need to accept that fact that some bugs just have to be in the release and we can live with them – after all most of these sorts of bugs have been with us for a very long time already and all of us have managed to live and use Rockbox fine for years in spite of their presence.
  • We need to accept and realize that most of “us” – the devs, the closest team of followers, will not use the release anyway as the day after the release we will provide a new set of spanking fresh binaries to download and use… We don’t do the release for us. We do the release to the huge audience out there who look for “stable” and “known to work” stuff.
  • Less people need to worry and have strong opinions about exactly what goes into the release or not. If we just get one release out, there will follow more further on that will get the stuff that is left out in this!

I am officially not volunteering to be a release manager! 😉