[Gnustep-cvs] gnustep/core/make ChangeLog which_lib.c
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/10/23 08:25:05 Modified files: core/make : ChangeLog which_lib.c Log message: Fixes to support additional library types on mingw. (patch #4210) CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/ChangeLog.diff?tr1=1.1189&tr2=1.1190&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/which_lib.c.diff?tr1=1.20&tr2=1.21&r1=text&r2=text
[Gnustep-cvs] gnustep/core/make ChangeLog configure configure...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/10/23 08:10:34 Modified files: core/make : ChangeLog configure configure.ac rules.make target.make Log message: Apply patch #4209 CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/ChangeLog.diff?tr1=1.1188&tr2=1.1189&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/configure.diff?tr1=1.191&tr2=1.192&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/configure.ac.diff?tr1=1.53&tr2=1.54&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/rules.make.diff?tr1=1.171&tr2=1.172&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/target.make.diff?tr1=1.176&tr2=1.177&r1=text&r2=text
[Gnustep-cvs] gnustep/core/make ChangeLog which_lib.c
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/10/23 10:33:23 Modified files: core/make : ChangeLog which_lib.c Log message: Minor tidyups CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/ChangeLog.diff?tr1=1.1190&tr2=1.1191&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/which_lib.c.diff?tr1=1.21&tr2=1.22&r1=text&r2=text
[Gnustep-cvs] GNUstep Testfarm Results
Test results for GNUstep as of Sun Oct 23 06:35:37 EDT 2005 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to add your machine to this list, set up a cron job (make sure you set up your PATH and other environment variables correctly) to run the Startup/scripts/test-gnustep script (see the script comments for more info). Success Compile i386-unknown-netbsdelf2.0.2 Sun Oct 23 03:59:29 CEST 2005 Success Compile powerpc-apple-darwin7.9.0 Sun Oct 23 03:35:40 MDT 2005 Success Compile sparc-sun-solaris2.7 Sun Oct 23 02:09:28 EDT 2005
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSWindow.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/10/23 10:53:39 Modified files: core/gui : ChangeLog core/gui/Source: NSWindow.m Log message: Fix bug #14008 CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2575&tr2=1.2576&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSWindow.m.diff?tr1=1.327&tr2=1.328&r1=text&r2=text
[Gnustep-cvs] gnustep/core/make ChangeLog config.h.in configu...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/10/23 11:24:30 Modified files: core/make : ChangeLog config.h.in configure configure.ac which_lib.c Log message: Changes to better chack for whitespace at end of line CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/ChangeLog.diff?tr1=1.1191&tr2=1.1192&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/config.h.in.diff?tr1=1.3&tr2=1.4&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/configure.diff?tr1=1.192&tr2=1.193&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/configure.ac.diff?tr1=1.54&tr2=1.55&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/which_lib.c.diff?tr1=1.22&tr2=1.23&r1=text&r2=text
Re: Proposal: Subversion Migration
Am 23.10.2005 um 05:20 schrieb Adam Fedor:
/libs/base/{trunk,tags,branches}
/libs/gui/{trunk,tags,branches}
/libs/Renaissance/{trunk,tags,branches}
/apps/Gorm/{trunk,tags,branches}
/apps/gworkspace/{trunk,tags,branches}
and so on.
We could then have something like:
/modules/dev-apps
/modules/core
/modules/dev-libs
Sure. but I am not very familiar with svn.
Subversion doesn't enforce any directory layout at all. Tags,
branches and copies are all "cheap" and are all the same: a bunch of
references in a new directory to what you have copied/tagged/
branched. To me, it's unclear why there's still made a difference
between tags and branches[1], but that's how the Subversion book
recommends it and it seems to be widely accepted.
Unlike CVS, Subversion numbers versions throughout the whole
repository. A bunch of files checked out have always the same
version; files get higher version numbers even without being changed.
As a result, one should tend to make small repositories, i.e. one for
each app, one for each tool, one for each lib.
That's how I understand it,
Markus
[1] IMHO, a layout like /path/to/part/{trunk,releases,branches} might
throw away some CVS relicts but fit better into reality.
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/base ChangeLog Documentation/Base....
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/10/23 11:27:32 Modified files: core/base : ChangeLog core/base/Documentation: Base.gsdoc core/base/Headers/Foundation: NSFileManager.h NSString.h core/base/Source: NSString.m NSUserDefaults.m Log message: More path handling tweaks. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/ChangeLog.diff?tr1=1.2622&tr2=1.2623&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Documentation/Base.gsdoc.diff?tr1=1.27&tr2=1.28&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Headers/Foundation/NSFileManager.h.diff?tr1=1.6&tr2=1.7&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Headers/Foundation/NSString.h.diff?tr1=1.22&tr2=1.23&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSString.m.diff?tr1=1.348&tr2=1.349&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSUserDefaults.m.diff?tr1=1.132&tr2=1.133&r1=text&r2=text
Re: GNUstep moving forward
Hi, (a bit longer reply or rather alternative. If you like, go directly at the end with suggested next steps) On 22.10.2005, at 12:46, Gregory John Casamento wrote: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. I am observing the same thing and realised few reasons (ordered how they comeunder my fingers on keyboard): External issues: 1. GNUstep desperately lacks an attractor for developers 2. GNUstep lacks attractor for users (this adds to the impact on 1.) 3. adoption (first contact, first setup, first installation) of GNUstep is very difficult Internal issues: 4. GNUstep has no project management, nor resources management, nor task management 5. GNUstep has no single achievable goal, neither short therm nor long term You have already mentioned some solutions that I have removed from this email, as they are already being discussed. Your suggestions address mainly points 2,3 and somehow point 1. But there is still problem 4 and 5. GNUstep developers and friends are pulling the rope on the same end, but to thousands of different directions :-) This reminds me a story for children by Czech writer Josef Capek in a book Of Dog and Cat. Dog (the dog) and Cat (the cat) wanted to bake a cake. They were putting in a pot everything they liked and they thought that would be good to have in the cake... "I like this, so I add it there" "Ok, that would be fine. I'll at that, because I like that and it is good" ... The cake was mixture only of "all good things", however at the end it was uneatable. We are baking similar cake too... Lack of larger picture, roadmap and kind of management affects development. Also lack of requirements specifications is making development of GNUstep much difficult and slow. Potential developers do not know what should be implemented, not speaking about how it should be developed. From management point of view, first step that should be done in GNUstep is detailed roadmap with very good task breakdown and expressend depencencies. For this I would suggest to either revive the 'Tasks' on savannah or use Wiki. With savannah one would have better task tracking, however on the wiki there would be better public visibility and accessibility, even it would be in a plain- text. I would vote for the wiki option. Tasks should be laid in a tree-like structure with good breakdown. 'CORBA' is an example of very bad task. Yes, one should start with taks like 'Windows support', but then it should be broken into 'Installation', 'Pasteboard', 'UI', 'Distributed Objects', etc. It is still not enough, because neither current nor new developer would know, what should be implemented for 'pasteboard'. Therefore one who knows should write: 'implement handling of type XY this or that way'. Now back to the project, people, resources and time. Many, if not all, core gnustep developers complain that they do not have time. Ok, me neither. But I ask: "WHO IS GOING TO IMPLEMENT MISSING GNUSTEP PARTS, IF THE ONLY KNOW-HOW HOLDER IS YOU?". Answer is: noone. Solution: GET THE KNOW HOW OUT OF YOUR HEAD AND SHARE IT!. Please, if every core developer was able to find just a little bit of time to write unordered bulleted list of his observations or knowledge about GNUstep that would be really helpful. And most importantly, write what is missing. GNUstep developers do not even know what they do not know, not to say that they do not know what they do not know and they need to know. Sharing your knowledge about GNUstep is investment in time. Shared knowledge will decrease obscurity and therefore decrease entry barrier for potential developers. From the management point of view, as open-source project has two major kinds of developers: voulentary ones and company developers. Voulentary developers do what they like to do. Company developers develop manily to satisfy company needs ignoring for them irrelevant parts. Very roughly speaking, of course. We all know, that main problem is lack of interested developers and time. Therefore the person with a role manager or leader in this case should allocate more resources for single task to decrease risk of non-implementation. Please, do not underestimate the importance of good project and knowledge management in development process. If a project is open- source, it does not mean, that it should be only programming driven as it is widely thought... Suggested next steps: - create roadmap with breakdown do implementable and understandable tasks - collect current knowledge - learn what we do not know - learn what we do not know and we need to know - define project roles (and use person redundancy) and last, but not least: - observe and copy behaviour of successful players (*) Regards, Stefan Urbanek (*) there are many inferior projects that have great success compared to their alt
Re: Proposal: Subversion Migration
Andy,
--- Andrew Ruder <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 22, 2005 at 09:20:53PM -0600, Adam Fedor wrote:
> > No, they will not do that. We could just as easily decide to make our
> > project non-free and then tell everyone to delete their free copies of
> > the project. I don't think that would go over well :-)
>
> Ah, well, I think most of the developers will catch on pretty quick ;)
> We can put up some README.MOVED files in various places perhaps?
This might be a good idea.
> > >/libs/base/{trunk,tags,branches}
> > >/libs/gui/{trunk,tags,branches}
> > >/libs/Renaissance/{trunk,tags,branches}
> > >/apps/Gorm/{trunk,tags,branches}
> > >/apps/gworkspace/{trunk,tags,branches}
> > >
> > >and so on.
> > >
> > >We could then have something like:
> > >
> > >/modules/dev-apps
> > >/modules/core
> > >/modules/dev-libs
> > >
> > >
> > Sure. but I am not very familiar with svn.
>
> Maybe someone who is familiar with svn can give a basic OK to this
> layout. Greg?
I believe, that until we come up with a plan to modularize things further, we
should leave the directory layout as it is. The way I see it we have two
choices:
1) Take the CVS repository whole-cloth into the SVN repo and make any changes
incrementally from there.
2) Take the burden of a redesign/relayout now and put it into SVN in some new
layout.
I, personally, prefer the incremental approach as it doesn't cause too much
disruption. Moving to SVN is disruption enought. ;)
> > Were will we actually be transferring this project to?
> > i.e.: Are we going to create a gnustep project on gna?
> > Who will be admin and who will determine access rights?
>
> There is a gnustep gna project already. I'm sure Alex Perez (who has it
> registered) wouldn't mind setting you up as administrator and some other
> people that could give out the commit access although we'll have to ask
> him.
>
> Alex set the gnustep project up on gna due to Savannah not being able to
> set up a -ui and -packagers mailing list when they were needed some time
> ago.
>
> > How will we verify that the transfer was correct?
>
> I'm not sure what the best approach would be here. Subversion has
> repository-wide revision numbers, so it is difficult to check that
> (although the original CVS revision number will be stored in the
> metadata for the file). I can run a couple diffs on various different
> dates through the history (including the latest) svn vs. cvs?
This would be easier to verify if we simply did a wholesale copy from one repo
to another. Unless you're referring to *all* of the metadata (history, etc)
for each file. That's somewhat more difficult. :)
> - Andy
GJC
Gregory John Casamento
-- CEO/President Open Logic Corp. (A MD Corp.)
## Maintainer of Gorm (IB Equiv.) for GNUstep.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Stefan, --- Stefan Urbanek <[EMAIL PROTECTED]> wrote: > Hi, > > (a bit longer reply or rather alternative. If you like, go directly > at the end with suggested next steps) > > On 22.10.2005, at 12:46, Gregory John Casamento wrote: > > > GNUstep has been relatively stagnant over the last several months > > and it has > > become a cause for concern for me. > > > > I am observing the same thing and realised few reasons (ordered how > they comeunder my fingers on keyboard): > > External issues: > 1. GNUstep desperately lacks an attractor for developers Although we have Gorm and ProjectCenter, I believe we do need more to make GNUstep attractive to devs. Some debugging (think MallocDebug) tools and other things might be nice in this regard. Also, a fully working ProjectCenter would be good as well. > 2. GNUstep lacks attractor for users (this adds to the impact on 1.) We need more apps to make this happen. > 3. adoption (first contact, first setup, first installation) of > GNUstep is very difficult It would be nice if we could simplify things for users to make it easier to install. > Internal issues: > 4. GNUstep has no project management, nor resources management, nor > task management > 5. GNUstep has no single achievable goal, neither short therm nor > long term Both of these can be taken care of by the creation of a roadmap to show what the project is and will be doing in the future. > You have already mentioned some solutions that I have removed from > this email, as they are already being discussed. Your suggestions > address mainly points 2,3 and somehow point 1. But there is still > problem 4 and 5. > > GNUstep developers and friends are pulling the rope on the same end, > but to thousands of different directions :-) This reminds me a story > for children by Czech writer Josef Capek in a book Of Dog and Cat. > Dog (the dog) and Cat (the cat) wanted to bake a cake. They were > putting in a pot everything they liked and they thought that would be > good to have in the cake... "I like this, so I add it there" "Ok, > that would be fine. I'll at that, because I like that and it is > good" ... The cake was mixture only of "all good things", however at > the end it was uneatable. We are baking similar cake too... > > Lack of larger picture, roadmap and kind of management affects > development. Also lack of requirements specifications is making > development of GNUstep much difficult and slow. Potential developers > do not know what should be implemented, not speaking about how it > should be developed. > > From management point of view, first step that should be done in > GNUstep is detailed roadmap with very good task breakdown and > expressend depencencies. For this I would suggest to either revive > the 'Tasks' on savannah or use Wiki. With savannah one would have > better task tracking, however on the wiki there would be better > public visibility and accessibility, even it would be in a plain- > text. I would vote for the wiki option. > > Tasks should be laid in a tree-like structure with good breakdown. > 'CORBA' is an example of very bad task. Yes, one should start with > taks like 'Windows support', but then it should be broken into > 'Installation', 'Pasteboard', 'UI', 'Distributed Objects', etc. It is > still not enough, because neither current nor new developer would > know, what should be implemented for 'pasteboard'. Therefore one who > knows should write: 'implement handling of type XY this or that way'. > > Now back to the project, people, resources and time. Many, if not > all, core gnustep developers complain that they do not have time. Ok, > me neither. But I ask: "WHO IS GOING TO IMPLEMENT MISSING GNUSTEP > PARTS, IF THE ONLY KNOW-HOW HOLDER IS YOU?". Answer is: noone. > Solution: GET THE KNOW HOW OUT OF YOUR HEAD AND SHARE IT!. Please, if > every core developer was able to find just a little bit of time to > write unordered bulleted list of his observations or knowledge about > GNUstep that would be really helpful. And most importantly, write > what is missing. GNUstep developers do not even know what they do not > know, not to say that they do not know what they do not know and they > need to know. > > Sharing your knowledge about GNUstep is investment in time. Shared > knowledge will decrease obscurity and therefore decrease entry > barrier for potential developers. > > From the management point of view, as open-source project has two > major kinds of developers: voulentary ones and company developers. > Voulentary developers do what they like to do. Company developers > develop manily to satisfy company needs ignoring for them irrelevant > parts. Very roughly speaking, of course. We all know, that main > problem is lack of interested developers and time. Therefore the > person with a role manager or leader in this case should allocate > more resources for sin
[Gnustep-cvs] gnustep/core/base ChangeLog Headers/Foundation/...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/10/23 14:53:03 Modified files: core/base : ChangeLog core/base/Headers/Foundation: NSFileManager.h NSString.h core/base/Source: NSFileManager.m NSString.m Log message: More tidyups ... rem ove some previously deprecated methods and improve docs CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/ChangeLog.diff?tr1=1.2623&tr2=1.2624&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Headers/Foundation/NSFileManager.h.diff?tr1=1.7&tr2=1.8&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Headers/Foundation/NSString.h.diff?tr1=1.23&tr2=1.24&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSFileManager.m.diff?tr1=1.119&tr2=1.120&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSString.m.diff?tr1=1.349&tr2=1.350&r1=text&r2=text
[Gnustep-cvs] gnustep/core/make ChangeLog which_lib.c
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Nicola Pero <[EMAIL PROTECTED]> 05/10/23 14:57:32 Modified files: core/make : ChangeLog which_lib.c Log message: Tidied up changes to search for xxx.dll before libxxx.dll.a in which_lib CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/ChangeLog.diff?tr1=1.1192&tr2=1.1193&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/which_lib.c.diff?tr1=1.23&tr2=1.24&r1=text&r2=text
[Gnustep-cvs] gnustep/core/base ChangeLog Source/NSException.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/10/23 15:11:19 Modified files: core/base : ChangeLog core/base/Source: NSException.m Log message: Added nice debugging patch from Jeremy CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/ChangeLog.diff?tr1=1.2624&tr2=1.2625&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSException.m.diff?tr1=1.49&tr2=1.50&r1=text&r2=text
[Gnustep-cvs] gnustep/core/base/Source NSException.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/10/23 15:14:35 Modified files: core/base/Source: NSException.m Log message: Use fprintf rather than NSLog to avoid any recursive exception problems CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSException.m.diff?tr1=1.50&tr2=1.51&r1=text&r2=text
[Gnustep-cvs] gnustep/core/make GNUstep.conf.in
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Nicola Pero <[EMAIL PROTECTED]> 05/10/23 15:42:17 Modified files: core/make : GNUstep.conf.in Log message: Extended comments a bit CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/GNUstep.conf.in.diff?tr1=1.3&tr2=1.4&r1=text&r2=text
[Gnustep-cvs] gnustep/core/make ChangeLog config.make.in comm...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Nicola Pero <[EMAIL PROTECTED]> 05/10/23 16:44:28 Modified files: core/make : ChangeLog config.make.in common.make Log message: Read the config files in makefiles while building CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/ChangeLog.diff?tr1=1.1193&tr2=1.1194&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/config.make.in.diff?tr1=1.67&tr2=1.68&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/common.make.diff?tr1=1.148&tr2=1.149&r1=text&r2=text
[Gnustep-cvs] gnustep/core/make config.make.in ChangeLog
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Nicola Pero <[EMAIL PROTECTED]> 05/10/23 16:51:06 Modified files: core/make : config.make.in ChangeLog Log message: Removed duplicated code that was already in names.make CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/config.make.in.diff?tr1=1.68&tr2=1.69&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/ChangeLog.diff?tr1=1.1194&tr2=1.1195&r1=text&r2=text
Re: Proposal: Subversion Migration
On Sun, Oct 23, 2005 at 06:50:31AM -0700, Gregory John Casamento wrote:
> > > >/libs/base/{trunk,tags,branches}
> > > >/libs/gui/{trunk,tags,branches}
> > > >/libs/Renaissance/{trunk,tags,branches}
> > > >/apps/Gorm/{trunk,tags,branches}
> > > >/apps/gworkspace/{trunk,tags,branches}
> > > >
> > > >and so on.
> > > >
> > > >We could then have something like:
> > > >
> > > >/modules/dev-apps
> > > >/modules/core
> > > >/modules/dev-libs
> > > >
> > > >
> > > Sure. but I am not very familiar with svn.
> >
> > Maybe someone who is familiar with svn can give a basic OK to this
> > layout. Greg?
>
> I believe, that until we come up with a plan to modularize things further, we
> should leave the directory layout as it is. The way I see it we have two
> choices:
>
> 1) Take the CVS repository whole-cloth into the SVN repo and make any changes
> incrementally from there.
> 2) Take the burden of a redesign/relayout now and put it into SVN in some new
> layout.
The relayout during the conversion is very simple. I was only
suggesting it because sometimes it is easier to follow the history when
things have not been rearranged :)
Plus, having a trunk/branches/tags per project would be much cleaner
than having a single trunk/branches/tags for the entire project. (i.e.
if we have a single tags directory, we'll be making tags like
/tags/gnustep-gui-1.0
whereas if we lay it out properly, we'll just have
/libs/gui/tags/1.0
Likewise we wouldn't have every projects tags and branches cluttering up
every other projects tags and branches hierarchy. The cvs2svn utility
also does a decent job of figuring out which tags and branches applied
to which subprojects. i.e.
http://local.aeruder.net/websvn/listing.php?repname=gnustep&path=%2FGorm%2Ftags%2F&rev=0&sc=0
shows only the tags made on GORM afaict.
We can of course, reorganize in the tree and move around all the tags
and branches to the appropriate places, but that may actually be more
difficult :)
> This would be easier to verify if we simply did a wholesale copy from one repo
> to another. Unless you're referring to *all* of the metadata (history, etc)
> for each file. That's somewhat more difficult. :)
Good point. Either way, a simple shell script or perl script can do the
grunt work.
--
Andrew Ruder
http://www.aeruder.net
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/make ChangeLog configure.ac configure
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Nicola Pero <[EMAIL PROTECTED]> 05/10/23 19:42:00 Modified files: core/make : ChangeLog configure.ac configure Log message: Fixed error in documentation of configure option CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/ChangeLog.diff?tr1=1.1195&tr2=1.1196&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/configure.ac.diff?tr1=1.55&tr2=1.56&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/make/configure.diff?tr1=1.193&tr2=1.194&r1=text&r2=text
Re: Proposal: Subversion Migration
On Sun, Oct 23, 2005 at 01:25:20PM +0200, Markus Hitter wrote: > Subversion doesn't enforce any directory layout at all. Tags, > branches and copies are all "cheap" and are all the same: a bunch of > references in a new directory to what you have copied/tagged/ > branched. To me, it's unclear why there's still made a difference > between tags and branches[1], but that's how the Subversion book > recommends it and it seems to be widely accepted. It is mostly just a namespace/convention issue. If I look through the tags directory, I should see only unchanging things marking the actual 1.0 release or the actual 1.1 release or some marker before some major changes are merged in, etc... I know that if I check those out I won't be needing to run svn update from time to time. The branches/ directory would be similar but I could assume that they are still being worked on or will have been actively developed in the past. There is no reason to have them, just a general convention which seems to have worked well over the years. > Unlike CVS, Subversion numbers versions throughout the whole > repository. A bunch of files checked out have always the same > version; files get higher version numbers even without being changed. > As a result, one should tend to make small repositories, i.e. one for > each app, one for each tool, one for each lib. You can, but svn does a good job of not making the revision #'s a pain. It is kind of weird to see the history on gorm and see that it changed at revision 11500 and 11420 and nothing inbetween, but there is no reason why that's an overly bad thing, imo. The bad thing about having small repositories is that you have to be very sure they will never have overlap (i.e. make sure that you'll never have to reorganize across repository boundaries) or you'll have yourself a mess for sure :) -- Andrew Ruder http://www.aeruder.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
Andrew Ruder schrieb:
> On Sun, Oct 23, 2005 at 06:50:31AM -0700, Gregory John Casamento wrote:
>
>/libs/base/{trunk,tags,branches}
>/libs/gui/{trunk,tags,branches}
>/libs/Renaissance/{trunk,tags,branches}
>/apps/Gorm/{trunk,tags,branches}
>/apps/gworkspace/{trunk,tags,branches}
>
>and so on.
>
>We could then have something like:
>
>/modules/dev-apps
>/modules/core
>/modules/dev-libs
>
>
Sure. but I am not very familiar with svn.
>>>
>>>Maybe someone who is familiar with svn can give a basic OK to this
>>>layout. Greg?
>>
>>I believe, that until we come up with a plan to modularize things further, we
>>should leave the directory layout as it is. The way I see it we have two
>>choices:
>>
>>1) Take the CVS repository whole-cloth into the SVN repo and make any changes
>>incrementally from there.
>>2) Take the burden of a redesign/relayout now and put it into SVN in some new
>>layout.
>
>
> The relayout during the conversion is very simple. I was only
> suggesting it because sometimes it is easier to follow the history when
> things have not been rearranged :)
>
> Plus, having a trunk/branches/tags per project would be much cleaner
> than having a single trunk/branches/tags for the entire project. (i.e.
> if we have a single tags directory, we'll be making tags like
>
> /tags/gnustep-gui-1.0
>
> whereas if we lay it out properly, we'll just have
>
> /libs/gui/tags/1.0
>
> Likewise we wouldn't have every projects tags and branches cluttering up
> every other projects tags and branches hierarchy. The cvs2svn utility
> also does a decent job of figuring out which tags and branches applied
> to which subprojects. i.e.
>
> http://local.aeruder.net/websvn/listing.php?repname=gnustep&path=%2FGorm%2Ftags%2F&rev=0&sc=0
>
> shows only the tags made on GORM afaict.
>
Pretty cool!
IMHO, this already looks very promising and I think a restructuring
could also be quit nice. But I don't have any good ideas about what the
structure should really look like, only unripe thoughts...
(should there be a distinction between:
libs/frameworks - tendency: no
tools/apps/servers - tendency: maybe
dev/user - tendency: maybe not)
I do think it would be good time to distinguish the non-FSF copyright
assigned projects like extensions and gsantlr. That could also be a
place where I could put the GPL'ed MySQL Adaptor for GDL2.
Anyway I'm looking forward to a transition to subversion and since the
FSF doesn't have any reservations about the source being hosted at
gna.org, I withdraw mine.
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
On Sun, Oct 23, 2005 at 10:17:08PM +0200, David Ayers wrote: > libs/frameworks - tendency: no > tools/apps/servers - tendency: maybe > dev/user - tendency: maybe not) nah, I think we will run into issues if we try to subdivide too much and make it only harder to do a checkout. Organizational things like that can also be partially accomplished by having modules in a /modules directory that when checked out would checkout all the other locations automatically. For example, I can make a /modules/dev-apps that basically says: Check out /apps/gorm/trunk into the gorm directory Check out /apps/easydiff/trunk into the easydiff directory and so on. When you do an svn update, or a commit or anything, it will commit to the actual location in the repository. svn:externals are a powerful thing when used in this regard... > I do think it would be good time to distinguish the non-FSF copyright > assigned projects like extensions and gsantlr. That could also be a > place where I could put the GPL'ed MySQL Adaptor for GDL2. Interesting, I did not realize that non-fsf-copyright-assigned projects existed in the GNUstep CVS. Perhaps to save the confusion we should set up another project for the nonfsf stuff. The modules I refer to above can reference external svn repository locations every bit as easily, so we could still make dev-libs pull in from the non-fsf place. But when setting up commit access we'd have the advantage that anyone getting the fsf gnustep commit access would need to have signed the forms, etc.. to assign copyright on code placed in that repository. Having such a project may also be an excellent place for people to host non-fsf-copyright-assigned projects directly related to gnustep. Thoughts? - Andy -- Andrew Ruder http://www.aeruder.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/base/Source NSException.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]> 05/10/23 21:30:25 Modified files: core/base/Source: NSException.m Log message: Add missing newlines in fprintfs CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSException.m.diff?tr1=1.51&tr2=1.52&r1=text&r2=text
Re: Proposal: Subversion Migration
On 23. Okt 2005, at 13:25 Uhr, Markus Hitter wrote: Unlike CVS, Subversion numbers versions throughout the whole repository. A bunch of files checked out have always the same version; files get higher version numbers even without being changed. As a result, one should tend to make small repositories, i.e. one for each app, one for each tool, one for each lib. Exactly. But notable repositories can refer each other so that other repositories are checked out automagically as subtrees. So the user doesn't usually need to be concerned about the actual repository a source comes from. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Gregory John Casamento wrote: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. I am observing the same thing and realised few reasons (ordered how they comeunder my fingers on keyboard): External issues: 1. GNUstep desperately lacks an attractor for developers Although we have Gorm and ProjectCenter, I believe we do need more to make GNUstep attractive to devs. Some debugging (think MallocDebug) tools and other things might be nice in this regard. Also, a fully working ProjectCenter would be good as well. I sort of agree with this. I feel it's more a symptom than a cause. We need better documentation and better support tools. To some degree these become self generating when the project is moving well with momentum. 2. GNUstep lacks attractor for users (this adds to the impact on 1.) We need more apps to make this happen. If you build it, they will come. Better dev environment means better dev, a precursor to the apps. Internal issues: 4. GNUstep has no project management, nor resources management, nor task management 5. GNUstep has no single achievable goal, neither short therm nor long term Both of these can be taken care of by the creation of a roadmap to show what the project is and will be doing in the future. I disagree. Completely. A roadmap is not project management. It's not resource management. It's not even task management. It's an idea of where things are going, not an implementable plan of how to get there. I do agree entirely that project management is a key issue. Probably THE issue. The size and complexity have grown beyond simple, organic organisation. You have already mentioned some solutions that I have removed from this email, as they are already being discussed. Your suggestions address mainly points 2,3 and somehow point 1. But there is still problem 4 and 5. GNUstep developers and friends are pulling the rope on the same end, but to thousands of different directions :-) This reminds me a story for children by Czech writer Josef Capek in a book Of Dog and Cat. Dog (the dog) and Cat (the cat) wanted to bake a cake. They were putting in a pot everything they liked and they thought that would be good to have in the cake... "I like this, so I add it there" "Ok, that would be fine. I'll at that, because I like that and it is good" ... The cake was mixture only of "all good things", however at the end it was uneatable. We are baking similar cake too... Lack of larger picture, roadmap and kind of management affects development. Also lack of requirements specifications is making development of GNUstep much difficult and slow. Potential developers do not know what should be implemented, not speaking about how it should be developed. From management point of view, first step that should be done in GNUstep is detailed roadmap with very good task breakdown and expressend depencencies. For this I would suggest to either revive the 'Tasks' on savannah or use Wiki. With savannah one would have better task tracking, however on the wiki there would be better public visibility and accessibility, even it would be in a plain- text. I would vote for the wiki option. I'd vote for savannah unless we have a better solution. The one I'd really like to see is one written around oOGO/gsweb... Tasks should be laid in a tree-like structure with good breakdown. 'CORBA' is an example of very bad task. Yes, one should start with taks like 'Windows support', but then it should be broken into 'Installation', 'Pasteboard', 'UI', 'Distributed Objects', etc. It is still not enough, because neither current nor new developer would know, what should be implemented for 'pasteboard'. Therefore one who knows should write: 'implement handling of type XY this or that way'. Now back to the project, people, resources and time. Many, if not all, core gnustep developers complain that they do not have time. Ok, me neither. But I ask: "WHO IS GOING TO IMPLEMENT MISSING GNUSTEP PARTS, IF THE ONLY KNOW-HOW HOLDER IS YOU?". Answer is: noone. Solution: GET THE KNOW HOW OUT OF YOUR HEAD AND SHARE IT!. Please, if every core developer was able to find just a little bit of time to write unordered bulleted list of his observations or knowledge about GNUstep that would be really helpful. And most importantly, write what is missing. GNUstep developers do not even know what they do not know, not to say that they do not know what they do not know and they need to know. This sort of thing would be very useful. If you take a look at NSTimeZone there is a lengthy comments section at the start which talks about the module and what it does. I wrote that original lengthy spiel. I should contribute such discussions to other modules. I'd say, though, that a better solution is to identify those with the knowledge and interest/dedication for a particular modul
[Gnustep-cvs] gnustep/core/back ChangeLog configure configure.ac
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Adam Fedor <[EMAIL PROTECTED]> 05/10/24 02:55:47 Modified files: core/back : ChangeLog configure configure.ac Log message: * configure.ac: Check for invalid backend graphics name. Error if no X11 libraries if using x11 server. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.392&tr2=1.393&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/configure.diff?tr1=1.38&tr2=1.39&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/configure.ac.diff?tr1=1.32&tr2=1.33&r1=text&r2=text
[Gnustep-cvs] gnustep/Startup ANNOUNCE ChangeLog ErrorList In...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Adam Fedor <[EMAIL PROTECTED]> 05/10/24 02:59:56 Modified files: Startup: ANNOUNCE ChangeLog ErrorList InstallGNUstep configure configure.ac setupvars.in Log message: * configure.ac: Update to set GNUstep dirs based on config file (like recent make changes). Check for X11 libraries * InstallGNUstep: More consistent usage of prefix and installation dirs. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/Startup/ANNOUNCE.diff?tr1=1.16&tr2=1.17&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/Startup/ChangeLog.diff?tr1=1.40&tr2=1.41&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/Startup/ErrorList.diff?tr1=1.13&tr2=1.14&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/Startup/InstallGNUstep.diff?tr1=1.29&tr2=1.30&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/Startup/configure.diff?tr1=1.25&tr2=1.26&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/Startup/configure.ac.diff?tr1=1.25&tr2=1.26&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/Startup/setupvars.in.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
