Re: What happened to the code freeze?

[Fred Kiefer]

Am 20.04.2010 23:30, schrieb Nicola Pero:
>> Looks like we have more commit right now during code freeze then we
>> have at normal times. I would suggest that we give up the idea of
>> doing more tests. As long as people cannot stick to a code freeze
>> even for a week,
> 
> I thought we were in "feature freeze" - ie, all commits must be bug 
> fixes as opposed to implementation of new features.  A typical
> pre-release phase to iron out bugs before a release. :-)

I was referring to Gregory's mail from the 9th, there he suggested a
code/feature freeze for two weeks. The trouble with the current release
is that it was due before FOSDEM, we normal come out with a GNUstep
release about twice a year. And this time we really had enough new
features and bug fixes to warrant a release, that would be urgently
needed to get a new stable release of GNUstep onto current distributions.
But then just before FOSDEM Richard started that big reorganisation of
base, which was a very good thing to do. I tried to follow this with a
rather smaller change to gui and planned for a release right after that.
Of course with a bit of time for all applications to adjust to these
changes and also for any urgent bug fixes.

> Instead, you're suggesting we're in "code freeze" - meaning no
> commits at all ?  Ie, nothing gets done for weeks ?  I've never seen
> a project do that.  Anyway it would be easy enough to do, we just all
> have to stop doing anything.  Hmmm.  Not sure why that would be
> useful ? ;-)

Code freeze doesn't mean no "commits at all". It means restricting the
commits to important changes that all agree on. Normally this gets done
by assigning a release manager that will have to accept and apply
patches. We did not do this in GNUstep, but relied on people being careful.
I know that you are managing commercial software and that you are quite
aware of all these concepts. This means you also know why it is
sometimes a good thing to stop doing random changes. In our case it
would allow application developers to catch up. While freezing core
changes to gdl, Gorm, Gworkspace, GAP and so on are still valid.
It would also allow people to test a rather well defined version of
GNUstep core on many different platforms. And of course if there are any
regressions try to fix them.

> Having many commits during a "feature freeze" is very good as it is 
> supposed to mean that a lots of bugs are being fixed. :-)

As far as I can tell none of the recent commits in gui or back is
related to any reported bug. Quentin's change clearly addresses a bug so
it would be in your definition the only valid candidate for a commit.
And although I see this as the most important patch of the year, I think
it is to dangerous to apply it now. Something as deep as this needs at
least four weeks of testing time, give the slow responses to changes in
GNUstep.

> With about 150 bugs open in the bug tracking system, we probably
> need quite a few weeks of feature freeze / bug fixing to get a good
> release. :-)

Actually most of the changes done in GNUstep could be counted as bug
fixes. What we mostly do is correct cases where GNUstep behaves
differently from Cocoa. Event the XIB laoding, the only new feature I
added this year, could be seen as a bug fix. Fixing the "GNUstep wont
load XIB files" bug :-)

> If I am the one who misunderstood and we really are in "code
> freeze", please let me know. ;-)
> 
> Probably Gregory should clarify.
> 
> I personally suggest we stay in a "feature freeze / bug fixing only" 
> phase for a while until the bug count is down and the commits slow
> down because there are no more bugs to fix :-)

Again, at the moment the bug count is not decreasing, nobody is into
fixing old bugs. OK, Richard and you each fixed one bug from the bug
tracker during the last week. At that rate we could have a feature
freeze for over a year to get the bugs resolved.

> Finally, it is quite possible you were referring to some specific 
> changes that are new features instead of being bug fixes - presumably
> in the gui ?  If so, you should IMO feel free to point these out, and
> even revert them.

I am referring to the ongoing changes to gui by Eric and Doug. All of
these are valid changes as far as I can tell. They surely fix some
behaviour that was annoying enough for them. But all these changes may
and did also introduce new issues to others. This is fine in normal
development mode, while trying to come up with a stable release it wont
help.

Perhaps it was an error not to set up any strict release management. I
would prefer if we can do without that. This requires that we all need
to think about the release and not just our pet issue that is annoying
us at this very moment. Having a GNUstep core release soon would be good
for the project and for all developers that build on top of GNUstep.
This should be our main goal at the moment.

And right after the release everybody should go back to committing like
crazy.

Fred