Re: What happened to the code freeze?
>> So the correct fix is simply to delete that block of code (and the >> declaration >> and assignment of 'sub' a few lines earlier). I've done that, and also >> delete >> the other call to setSupermenu: that I had added. > > If that works for you, all the better. It is always great to remove some > code :-) > > Did you also read the rest of my mail? What do you think about the > suggestion to move the last menu theme call out of NSApplication? > > With that (and the indentation) sorted out you should be able to push > your change. Done and committed. :-) Cheers, Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Am 23.04.2010 19:59, schrieb Doug Simons:
>
> On Apr 23, 2010, at 2:21 AM, Fred Kiefer wrote:
>
>> Am 23.04.2010 07:42, schrieb Doug Simons:
>>> On Apr 22, 2010, at 1:41 AM, Fred Kiefer wrote:
>>>
You change to set the super menu on a decoded submenu in NSMenu is most
likely wrong. This value already gets set in NSMenuItem +setSubmenu: and
before doing so the code checks that the old super menu is nil. I don't
see how your code could have ever worked.
If there was an issue with the super menu not being set correctly we
need to investigate it. I don't think this is the right fix for it.
>>>
>>> Okay, on looking at this more closely now, I think you are right about the
>>> call
>>> to setSupermenu: while decoding. I'm not sure of exactly what was happening
>>> (and
>>> don't have time to debug it at the moment), but the supermenu was nil in
>>> all of
>>> the submenus of our main menu (which is loaded from a nib file). The new
>>> call to
>>> setSupermenu: in insertItem:atIndex: seems to be enough to fix the problem
>>> for
>>> me. My guess now is that the root problem is probably in the nib loading
>>> code
>>> for the menu. But the fix as it stands now shouldn't be a problem I think.
>>
>> Your new change to this code surely wont break things as the old one
>> did. Still I am not convinced that this is needed. And looking at the
>> code surely proves this. I believe you that it makes a difference for
>> you and we need to find out where this difference comes from. If we
>> don't we not only clutter GNUstep with unneeded code, we will also
>> surely break things the next time this code gets touched. As a
>> maintainer I am not only thinking about current code correctness, but
>> try to assure we can guarantee this over a longer time. Sorry, for
>> causing you extra work here. On the other hand you would expect me to do
>> the same for other peoples changes, or for that for my own ones.
>>
>> Your change in NSMenu looks like this (last line added):
>>
>> // Set this after the insert notification has been sent.
>> [newItem setMenu: self];
>> [[newItem submenu] setSupermenu:self];
>>
>> And in NSMenuItem we have:
>>
>> - (void) setMenu: (NSMenu*)menu
>> {
>> /* The menu is retaining us. Do not retain it. */
>> _menu = menu;
>> if (_submenu != nil)
>> {
>> [_submenu setSupermenu: menu];
>> [self setTarget: _menu];
>> }
>> }
>>
>> In which cases could your code make any difference?
>> - newItem could not be of class NSMenuItem.
>>
>> - submenu returned from the method could be different from the slot.
>> This is not the case for NSMenuItem, so it falls back to the first case.
>>
>> - setTarget: on the menu item does something strange. This is also not
>> the case for NSMenuItem.
>>
>> - There is a redefinition of setMenu: somewhere.
>>
>> The most likely reason seems to be that we are not dealing with an
>> NSMenuItem here. Could you please check that?
>>
>> What is strange when comparing your new patch with your old is that when
>> NIB loading the new patch will now set the menu twice and the NIB
>> loading code will set it to nil again and then get it set again via
>> setSubmenu:forItem:. This all looks so completely wrong. I really would
>> prefer to understand this before we plaster it over.
>
> Okay, it looks like I was mistaken about some things. The hazards of coding
> after my usual bedtime, I suppose. ;-)
>
> It turns out that the call to setSupermenu: that I added (in the insert
> method)
> does absolutely nothing. It was the change I made to setSupermenu:self
> instead
> of setSupermenu:nil during decoding that fixed the problem for me. But I
> didn't
> look closely enough at the time to fully understand why that fixed it. As
> you've
> astutely observed, that looks like it ought to cause problems. But what's
> actually happening is that everything is already set at that point. I should
> have paid more attention to the FIXME comment at that point in the code:
> // FIXME: We propably don't need this, as all the fields are
> // already set up for the submenu item.
> if (sub != nil)
> {
> [sub setSupermenu: nil];
> [self setSubmenu: sub forItem: item];
> }
>
> By changing it to call [sub setSupermenu:self] what I achieved was a no-op,
> since the supermenu was already set by the earlier call to [self
> addItem:item].
> The next line was also a no-op, since item's submenu was also set already at
> this point. The root of the problem was the call to [sub setSupermenu: nil]
> which wiped out the supermenu that was already set correctly!
>
> So the correct fix is simply to delete that block of code (and the
> declaration
> and assignment of 'sub' a few lines earlier). I've done that, and also delete
> the other call to setSupermenu: that I had added.
If that works for you, all the better. It is always great to remove some
code :-)
Did you also read the rest of my mail? What do you think about the
suggestion to move the last menu theme call out o
Re: What happened to the code freeze?
Am 23.04.2010 07:42, schrieb Doug Simons:
> On Apr 22, 2010, at 1:41 AM, Fred Kiefer wrote:
>
>> You change to set the super menu on a decoded submenu in NSMenu is most
>> likely wrong. This value already gets set in NSMenuItem +setSubmenu: and
>> before doing so the code checks that the old super menu is nil. I don't
>> see how your code could have ever worked.
>> If there was an issue with the super menu not being set correctly we
>> need to investigate it. I don't think this is the right fix for it.
>
> Okay, on looking at this more closely now, I think you are right about the
> call
> to setSupermenu: while decoding. I'm not sure of exactly what was happening
> (and
> don't have time to debug it at the moment), but the supermenu was nil in all
> of
> the submenus of our main menu (which is loaded from a nib file). The new call
> to
> setSupermenu: in insertItem:atIndex: seems to be enough to fix the problem
> for
> me. My guess now is that the root problem is probably in the nib loading code
> for the menu. But the fix as it stands now shouldn't be a problem I think.
Your new change to this code surely wont break things as the old one
did. Still I am not convinced that this is needed. And looking at the
code surely proves this. I believe you that it makes a difference for
you and we need to find out where this difference comes from. If we
don't we not only clutter GNUstep with unneeded code, we will also
surely break things the next time this code gets touched. As a
maintainer I am not only thinking about current code correctness, but
try to assure we can guarantee this over a longer time. Sorry, for
causing you extra work here. On the other hand you would expect me to do
the same for other peoples changes, or for that for my own ones.
Your change in NSMenu looks like this (last line added):
// Set this after the insert notification has been sent.
[newItem setMenu: self];
[[newItem submenu] setSupermenu:self];
And in NSMenuItem we have:
- (void) setMenu: (NSMenu*)menu
{
/* The menu is retaining us. Do not retain it. */
_menu = menu;
if (_submenu != nil)
{
[_submenu setSupermenu: menu];
[self setTarget: _menu];
}
}
In which cases could your code make any difference?
- newItem could not be of class NSMenuItem.
- submenu returned from the method could be different from the slot.
This is not the case for NSMenuItem, so it falls back to the first case.
- setTarget: on the menu item does something strange. This is also not
the case for NSMenuItem.
- There is a redefinition of setMenu: somewhere.
The most likely reason seems to be that we are not dealing with an
NSMenuItem here. Could you please check that?
What is strange when comparing your new patch with your old is that when
NIB loading the new patch will now set the menu twice and the NIB
loading code will set it to nil again and then get it set again via
setSubmenu:forItem:. This all looks so completely wrong. I really would
prefer to understand this before we plaster it over.
>> I like all the simplifications you did for the menu update for the in
>> window menu. Why not hide all the details in the
>> setMenuChangedMessagesEnabled: method? That is have the change passed up
>> to the super menu and when we are the app menu, do what is needed there?
>> You will then miss out on some more menu changes, for example when the
>> main menu doesn't have autoenabled items. Looks like I need to think
>> about this some more.
>
> Good point. I've moved the call to menuChanged into all of the individual
> methods that note the changes.
Great.
>> The changes to NSApplication I don't like. Why should the application be
>> concerned about the display of the main menu at all? At least one of
>> these could be moved into NSMenu -setMain: and perhaps that change could
>> take care of the second call as well?
>
> Moving the one call into [NSMenu setMain:] is reasonable. Unfortunately, the
> call to updateAllWindowsWithMenu: in _didFinishLaunching is necessary, now
> that
> it isn't being called all the time from [NSMenu update]. Without this call
> the
> menus never get built. I guess either setMain: isn't being called at launch,
> or
> it is called too early to be effective.
This is rather sad. Anybody out there with an idea how to resolve this?
We could of course have the main menu listen for the
NSApplicationDidFinishLaunchingNotification notification, but this looks
like overkill for this small issue. But then we already do! We call
_showTornOffMenuIfAny: inthat case. Why not add your code there?
Perhaps we should rename this method then, but it looks like the right
place to me.
>> Your patch also seems to have an indentation problem are you using tabs?
>
> Sorry, it looks consistent to me. I'm using Notepad++ on Windows. I guess
> I'll
> have to fiddle with the settings and see if I can get it to conform properly.
> Does anyone know the right settings to use?
Us two spaces in stead of tabs
Re: What happened to the code freeze?
Great that you send this change to the list so we can discuss it in advance. Anything that touches the system that deep should better be analysed by many developers even when not in feature freeze mode. The changes to NSMenuItem are so obvious, why didn't we do it that way in the first place? You change to set the super menu on a decoded submenu in NSMenu is most likely wrong. This value already gets set in NSMenuItem +setSubmenu: and before doing so the code checks that the old super menu is nil. I don't see how your code could have ever worked. If there was an issue with the super menu not being set correctly we need to investigate it. I don't think this is the right fix for it. I like all the simplifications you did for the menu update for the in window menu. Why not hide all the details in the setMenuChangedMessagesEnabled: method? That is have the change passed up to the super menu and when we are the app menu, do what is needed there? You will then miss out on some more menu changes, for example when the main menu doesn't have autoenabled items. Looks like I need to think about this some more. The changes to NSApplication I don't like. Why should the application be concerned about the display of the main menu at all? At least one of these could be moved into NSMenu -setMain: and perhaps that change could take care of the second call as well? Your patch also seems to have an indentation problem are you using tabs? Any changes that affect only the Windows backend aren't that problematic. They wont be noticed by most people running GNUstep. :-) Fred Am 21.04.2010 21:26, schrieb Doug Simons: > Okay, here are the files I updated for this fix to NSMenu. These are based on > r30210 if you want to do a diff to see what's changed. Or drop them in and > see > how it works for you (Eric, I agree that this should help with the scroll > wheel > in Ink. Let me know. Also, try typing very fast in a text view before and > after > applying this change). > > Fred and anyone else who takes a look: let me know in the next day or so if > you > see any issues here or have any questions. I'll hold off checking them in for > the moment. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
A very very nice feature fix would be having the instalaltion domain configuration working on windows like on linux! I bet Gregory agrees... I have already fixed it :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Hi, * I also wanted to look at the Cygwin port, but that may not have time before the release. I would appreciate that. I think it is currently broken, at least for me. Somebody worked here on the list, but he never replied me when I asked how far he got. Since I consider it broken, I would not put it subject to "feature freeze". If you improve it even partially (atl least to get base working) go on. A very very nice feature fix would be having the instalaltion domain configuration working on windows like on linux! I bet Gregory agrees... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Nicola Pero wrote: 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. :-) Exactly! I understood the same. Of course some fixes might introduce new bugs, btu this is normal during testing. 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 ? ;-) Never head about that, not even at work. A freeze of 1-2 days is possible there, for pure testing, but we can't in opensource do that. Or we might declare a certain weekend to be test weekend, if a couple of people can follow that. 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. :-) Yes, we have a lot of bugs. I was speaking with Gregory and it would be nice to have some of these fixed. 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 :-) Yes, or at least a certain number of bugs have been addressed or explained or posponed. I undertand that this release is long due, but it is a very important release I think. There are many changes, I noticed that many applications need a new release because of adjustments needed. Even smalls tuff, like the header and import cleanup done by Fred. Of course he did a good job, the applications were wrong, but they need to be released soon, so that people don't experience broken applications. There will be some sort of avalanche effect. We must be careful about that, but if done well it will give us exposure and advertisement! They can't call us dead anymore. 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. Some of the commits clearly marked fixes. How good they are we must retest. Cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
The feature freeze only includes core (make, base, gui and back). I don't really consider the WinUXTheme (or any of the themes) to be part of the freeze, so your changes are fine where they are. I should have been more concise about the scope of the freeze I wanted in the first place. That would have avoided some of the current confusion. I would like Doug to send the patches he's got in mind to Fred for review and testing. GC On Wed, Apr 21, 2010 at 2:04 PM, Eric Wasylishen wrote: > Sorry, two of my recent theme-related commits were probably inappropriate to > make during the feature freeze (adding an option to disable the inner > border in NSScrollView, and moving NSBrowser header drawing to GSTheme). I > can revert these if you'd like. > Doug: the Windows menu fixes sound great. I was noticing a lot of menu > flickering with the WinUX theme, and mousewheel scrolling in Ink was really > laggy - I bet your patch will fix those problems. > Eric > On Wed, Apr 21, 2010 at 11:32 AM, Gregory Casamento > wrote: >> >> I believe that "feature freeze" is the correct term and what I was >> really after when I suggested the freeze. I'm comfortable with any >> changes that fix or improve existing functionality so long as: >> >> 1) they don't add new features and >> 2) They don't involve drastic refactoring of existing code. >> >> GC -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Sorry, two of my recent theme-related commits were probably inappropriate to make during the feature freeze (adding an option to disable the inner border in NSScrollView, and moving NSBrowser header drawing to GSTheme). I can revert these if you'd like. Doug: the Windows menu fixes sound great. I was noticing a lot of menu flickering with the WinUX theme, and mousewheel scrolling in Ink was really laggy - I bet your patch will fix those problems. Eric On Wed, Apr 21, 2010 at 11:32 AM, Gregory Casamento < greg.casame...@gmail.com> wrote: > I believe that "feature freeze" is the correct term and what I was > really after when I suggested the freeze. I'm comfortable with any > changes that fix or improve existing functionality so long as: > > 1) they don't add new features and > 2) They don't involve drastic refactoring of existing code. > > GC ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
I believe that "feature freeze" is the correct term and what I was really after when I suggested the freeze. I'm comfortable with any changes that fix or improve existing functionality so long as: 1) they don't add new features and 2) They don't involve drastic refactoring of existing code. GC On Tue, Apr 20, 2010 at 5:30 PM, Nicola Pero wrote: > >> 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. :-) > > 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 ? ;-) > > Having many commits during a "feature freeze" is very good as it is supposed > to mean > that a lots of bugs are being fixed. :-) > > 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. :-) > > 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 :-) > > 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. > > Thanks > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Hello, Fred wrote: > As far as I can tell none of the recent commits in gui or back is > related to any reported bug. > [snip] > 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. It's true that the changes I've been submitting aren't in response to bugs in the GNUstep bug system. We are actively fixing bugs in our own application. As an illustration, when we have a bug that affects only the Windows version of our product, I'm pretty sure that it's caused by a problem somewhere in GNUstep, but I don't know for sure until I dig in and debug exactly what's going wrong. This typically takes several hours of debugging, at which point I can see what the problem is, so I fix it. Now, at that point I suppose I could enter a bug on savannah and then mark it as fixed, but I don't really see the point of doing that (and I'm under a lot of time pressure right now, as we are scheduled for a release next week!). So I've just been careful to review my own fixes and try to describe what I'm fixing when I check it in. Since we're in 'code freeze' mode, I hope that someone (maybe more than one someone?) is looking at any changes that are checked in to make sure they look sane, and perhaps think about whether they might have unintended consequences. I'm about to check in a significant fix, that substantially improves performance on Windows (with in-window menus). The change dramatically reduces the frequency of rebuilding the Windows menus. They were rebuilding with every event rather than only when needed. The resulting drag on performance wasn't just an "annoyance" -- it basically made editing text in an NSTextView almost unusable. I've checked my code over carefully, and believe it won't have any negative consequences. As part of this fix, I corrected a bug in NSMenu which was never setting its supermenu ivar correctly, and improved NSMenuItem to only notify its menu that it has changed when something actually changes. It's conceivable that that could impact some other code, but is clearly more "correct" now than its former behavior. The main impact of this change will only be on Windows for applications that use in-window menus. For those applications, there is a small chance that I missed something such that menus will fail to update when they should, now that they're not updating all the time (I don't think so, but it's worth watching out for). I could hold off on submitting this change, but it seems to me like exactly the kind of fix that I (at least) would like to see going in right now. So I plan to check it in as soon as it's validated by some other people here. Please let me know if you see any problems with this change or any others that I submit. We really appreciate the timing of this "feature freeze", by the way, since we are in the middle of a release. Knowing that things are relatively stable and only getting bug fixes is perfect for us right now. And while I'm at it, I'd like to say "THANK YOU" to everyone on the GNUstep team! The more I dig into the code, the more I'm reminded of what an incredible amount of work has gone into it, and despite the bugs (which are frustrating, and are the cause of my digging into the code in the first place) there is an amazing amount of functionality here that is working really well. Hopefully our small contributions will help GNUstep to be even better. Cheers, Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
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 _
Re: What happened to the code freeze?
As an outsider, it does seem that GUI needs a few weeks of feature freeze and bug fixing, so I wouldn't give up on that just because it needs to be organized somehow ;-) Could you please give an explanation of this impression? Was this a general statement that before any gui release we should have such a period or was this based on any specific know limitation of gui? It's a general statement. The GUI is complicated because of all the interactions. A change in one place might break something somewhere else and which would seem completely unrelated ;-) (I blame the API, but you could conceivably blame the implementation) Because of that, I'd expect the GUI to need even more bug fixing than the rest ? For the non-graphical stuff (gnustep-make, gnustep-base, jigs, SQLClient, WebServer, WebServices, etc) that we use at work, we are very keen on having very stable and bug free releases. We almost don't care about new features. But we need very stable software. So a long bug fixing phase is really good. :-) I would imagine most other users appreciate very stable software too. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Am 21.04.2010 09:50, schrieb Nicola Pero: > As far as I understand, you're in charge of GUI, so maybe you (and/or > Gregory) could propose > how you want to manage that ? Maybe patches for GUI must be approved by > you before being > committed during the feature freeze ? I'd rather rely on people being careful in what they commit. This used to work in previous years. This time it is different perhaps because we let the release drag on for too long? > As an outsider, it does seem that GUI needs a few weeks of feature > freeze and bug fixing, so I wouldn't > give up on that just because it needs to be organized somehow ;-) Could you please give an explanation of this impression? Was this a general statement that before any gui release we should have such a period or was this based on any specific know limitation of gui? With regards to gui I still don't see you as an outsider, you were the one that committed my first patches to gui and commented on them. In my thinking you still know a lot more about gui than I do. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
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. [...] Ok - thanks! - that clarifies the problem then :-) I'm sure individual committers would probably disagree or have good arguments why their changes should have gone in - it sounds like we need some simple process to resolve the disagreements and decide what goes in and what doesn't go in at this stage ? ;-) As far as I understand, you're in charge of GUI, so maybe you (and/or Gregory) could propose how you want to manage that ? Maybe patches for GUI must be approved by you before being committed during the feature freeze ? As an outsider, it does seem that GUI needs a few weeks of feature freeze and bug fixing, so I wouldn't give up on that just because it needs to be organized somehow ;-) (btw sorry, I don't mean to interfere - I'll disappear from the discussion of the GUI release freeze after this email) -- For the part I work on (gnustep-make and core makefiles) anyone can make any small fixes they want, but for substantial changes please talk to me before committing (this is always the case though). :-) gnustep-make is quite ready for the 2.4.0 release, except that: * there is this long-standing issue of whether we should link all libraries or not when linking executables. I was planning on making that configurable at ./configure stage (with some reasonable, OS-dependent defaults). It would be good to do this before a release, as it might change how things are linked. On the other hand, I have a feeling it's too late for 2.4.0, so I'll probably do it as the first thing after this release instead. * I haven't looked at how gnustep-make works on Apple at all. I wanted to make sure the apple-apple-apple settings and compiler/linker flags are meaningful and usable - at the moment, I don't think they are as many people reported you have to tweak them in non-obvious ways to use it. If I get some time, I'll try to do this before the release. * I also wanted to look at the Cygwin port, but that may not have time before the release. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Am 20.04.2010 um 14:30 schrieb Nicola Pero: > 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. Would not make any sense to me. > 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. :-) True. Cheers, David Wetzel ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
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. :-) 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 ? ;-) Having many commits during a "feature freeze" is very good as it is supposed to mean that a lots of bugs are being fixed. :-) 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. :-) 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 :-) 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. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
