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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
