Re: [Gnustep-cvs] r28488 - /libs/gui/branches/testplant_1/

2009-08-21 Thread Fred Kiefer
Gregory Casamento schrieb:
> Author: gcasa
> Date: Thu Aug 20 00:25:33 2009
> New Revision: 28488
> 
> URL: http://svn.gna.org/viewcvs/gnustep?rev=28488&view=rev
> Log:
> Add new branch with corrected revision number.
> 
> Added:
> libs/gui/branches/testplant_1/
>   - copied from r28233, libs/gui/trunk/
> 
Hi Greg,

could you please explain the purpose of this new branch? I can see that
Doug and Jonathan have started using it. Most of the changes they made
up to now are perfectly legitimate for trunk (Apart from those already
in trunk and that GSContext change. I am unsure about the NSOpenPanel patch)
Who will be porting these changes back to trunk? Currently the commits
on the branch are without Change log entries, how are we going to add these?

Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: [Gnustep-cvs] r28488 - /libs/gui/branches/testplant_1/

2009-08-21 Thread Riccardo Mottola

Fred Kiefer wrote:

Gregory Casamento schrieb:
  

Author: gcasa
Date: Thu Aug 20 00:25:33 2009
New Revision: 28488

URL: http://svn.gna.org/viewcvs/gnustep?rev=28488&view=rev
Log:
Add new branch with corrected revision number.

Added:
libs/gui/branches/testplant_1/
  - copied from r28233, libs/gui/trunk/



Hi Greg,

could you please explain the purpose of this new branch? I can see that
Doug and Jonathan have started using it. Most of the changes they made
up to now are perfectly legitimate for trunk (Apart from those already
in trunk and that GSContext change. I am unsure about the NSOpenPanel patch)
Who will be porting these changes back to trunk? Currently the commits
on the branch are without Change log entries, how are we going to add these?
  


I think I can agree with Fred here, keeping the ChangeLog would make 
things much easier in the futuere event of a merge.


Riccardo
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: [Gnustep-cvs] r28488 - /libs/gui/branches/testplant_1/

2009-08-21 Thread Gregory Casamento
Fred,

The Testplant guys are doing a maintenance release.   The branch is
based on 28233 which was the last version their software was released
against.   They didn't want to take all of the changes from the trunk
just yet for the maintenance release since there is some instability
there with their app.

I've been taking selected fixes, currently only the deadlock fixes
from NSUserDefaults.

I'd appreciate any detailed feedback you have on the others before
inclusion into the trunk.

With respect to the GSContext change, it has helped prevent some
issues with multi-threaded apps in GUI.  I would like to make it less
coarse grained so that it can be brought to the trunk as well.

Greg

On Fri, Aug 21, 2009 at 7:20 AM, Fred Kiefer wrote:
> Gregory Casamento schrieb:
>> Author: gcasa
>> Date: Thu Aug 20 00:25:33 2009
>> New Revision: 28488
>>
>> URL: http://svn.gna.org/viewcvs/gnustep?rev=28488&view=rev
>> Log:
>> Add new branch with corrected revision number.
>>
>> Added:
>>     libs/gui/branches/testplant_1/
>>       - copied from r28233, libs/gui/trunk/
>>
> Hi Greg,
>
> could you please explain the purpose of this new branch? I can see that
> Doug and Jonathan have started using it. Most of the changes they made
> up to now are perfectly legitimate for trunk (Apart from those already
> in trunk and that GSContext change. I am unsure about the NSOpenPanel patch)
> Who will be porting these changes back to trunk? Currently the commits
> on the branch are without Change log entries, how are we going to add these?
>
> Fred
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>



-- 
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: [Gnustep-cvs] r28488 - /libs/gui/branches/testplant_1/

2009-08-21 Thread Fred Kiefer
Gregory Casamento schrieb:
> I've been taking selected fixes, currently only the deadlock fixes
> from NSUserDefaults.

Great.

> I'd appreciate any detailed feedback you have on the others before
> inclusion into the trunk.

Patches that look ok to me:

28492 GSLayoutManager.m


Patches that will need a bit more explanation/rework:

28498 NSOpenPanel.m
Why not change the method _shouldShowExtension: or what is the difference?

28494 NSFont.m
The user default is fine, but will need documentation too.

> With respect to the GSContext change, it has helped prevent some
> issues with multi-threaded apps in GUI.  I would like to make it less
> coarse grained so that it can be brought to the trunk as well.

As I already explained: This change is working around the problem that
we use the same graphic context for a window in different threads. What
we should do is create a specific context for each thread.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: [Gnustep-cvs] r28488 - /libs/gui/branches/testplant_1/

2009-08-21 Thread Gregory Casamento
Fred,

On Fri, Aug 21, 2009 at 3:57 PM, Fred Kiefer wrote:
> Gregory Casamento schrieb:
>> I've been taking selected fixes, currently only the deadlock fixes
>> from NSUserDefaults.
>
> Great.
>
>> I'd appreciate any detailed feedback you have on the others before
>> inclusion into the trunk.
>
> Patches that look ok to me:
>
> 28492 GSLayoutManager.m
>

Okay, I'll go ahead and pull this one into the trunk.

> Patches that will need a bit more explanation/rework:
>
> 28498 NSOpenPanel.m
> Why not change the method _shouldShowExtension: or what is the difference?

I'll forward this concern.

> 28494 NSFont.m
> The user default is fine, but will need documentation too.

Okay.

>> With respect to the GSContext change, it has helped prevent some
>> issues with multi-threaded apps in GUI.  I would like to make it less
>> coarse grained so that it can be brought to the trunk as well.
>
> As I already explained: This change is working around the problem that
> we use the same graphic context for a window in different threads. What
> we should do is create a specific context for each thread.

Yes, I agree. Ideally I would like to make it per window identifier/device.

GC

-- 
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: [Gnustep-cvs] r28488 - /libs/gui/branches/testplant_1/

2009-08-22 Thread Doug Simons
Hi, sorry if I'm not following protocol. These are my first direct  
commits. I entered a log message on each change, but I guess that  
doesn't automatically go to the ChangeLog. How should I go about  
entering information in the ChangeLog?


As for the purpose of the branch: We need a known version that we have  
verified works for us, for our production builds. We would like to be  
using the tip of the trunk, in order to get recent fixes, but some of  
the recent commits have broken things for us. Until we have time to  
track those down and get them corrected, we need a place to add some  
of our own fixes based on a version that is stable for us.


We will also try to build from the trunk when we have a chance during  
our development, and find, report, or fix any issues we run into. But  
we've found that the tip is too risky (understandably!) for deployment  
builds.


Hopefully, our fixes can be merged into the trunk, and we can jump our  
branch ahead (or create new branches, I guess) to later points along  
the trunk periodically, when we are able to verify a version that  
works for us.


--
Doug Simons
Principal Developer


TestPlant Inc   T+1 720-890-0211 ext 13
4730 Walnut Street  F+1 720-890-0209
Boulder, CO 80301   doug.sim...@testplant.com
USA
http://www.testplant.com
This email and any attachments may contain privileged / confidential  
information. If you have received this email in error
or believe that you are not the intended recipient, please delete all  
content and attached files and contact TestPlant via
the switchboard on +1 720-890-0211 or via return e-mail. You should  
not copy, forward or use any part of the
contents in any way. Any such unauthorised use or disclosure may be  
unlawful.


On Aug 21, 2009, at 8:43 AM, Riccardo Mottola wrote:


Fred Kiefer wrote:


Gregory Casamento schrieb:


Author: gcasa
Date: Thu Aug 20 00:25:33 2009
New Revision: 28488

URL: http://svn.gna.org/viewcvs/gnustep?rev=28488&view=rev
Log:
Add new branch with corrected revision number.

Added:
libs/gui/branches/testplant_1/
  - copied from r28233, libs/gui/trunk/



Hi Greg,

could you please explain the purpose of this new branch? I can see  
that
Doug and Jonathan have started using it. Most of the changes they  
made
up to now are perfectly legitimate for trunk (Apart from those  
already
in trunk and that GSContext change. I am unsure about the  
NSOpenPanel patch)
Who will be porting these changes back to trunk? Currently the  
commits
on the branch are without Change log entries, how are we going to  
add these?




I think I can agree with Fred here, keeping the ChangeLog would make  
things much easier in the futuere event of a merge.


Riccardo
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev


Re: [Gnustep-cvs] r28488 - /libs/gui/branches/testplant_1/

2009-08-22 Thread David Chisnall

On 21 Aug 2009, at 18:01, Doug Simons wrote:

Hi, sorry if I'm not following protocol. These are my first direct  
commits. I entered a log message on each change, but I guess that  
doesn't automatically go to the ChangeLog. How should I go about  
entering information in the ChangeLog?


If people really care about duplicating the commit messages in the  
ChangeLog[1] then perhaps they could write a pre-commit hook that  
simple prepends the output of svn log to the ChangeLog.


David

[1] Compare and contrast:

Commit messages:  http://cia.vc/stats/project/gnustep
ChangeLog:  
http://svn.gna.org/viewcvs/gnustep/libs/base/trunk/ChangeLog?rev=28504&view=auto



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev