[Discuss-gnustep] RE: GNUstep Environment - the core

[Nicola Pero]

Hi Philippe, 

I think in the end we agree on most things :-) 

Sorry if my comments on 'newbie' seemed - aggressive ? - They were not
intended to be. 

About packaging things, I think a very very intelligent idea someone had
was to try adding some sort of rpm & deb support to the GNUstep make
system itself.  The thing must be studied for a while from a technical
point of view, but it could be feasible.  

After all, we build all our libraries, apps and bundles using the same
make packages - the procedure is standard - it is probably possible to add
rpms and debs support to our make package.

By the way, this would help a lot to spread our apps, libraries and tools 
around; but it would also be very useful for people or companies having 
their own software running on top of GNUstep: instead of moving the full 
sources to a new machine and recompiling everything, they could just 
create an rmp on their compiling machine (by simply typing 'make rpm'),
and then simply move this binary rpm to any machine they want to install 
the whole software on, and type 'rpm -Uvh myPackage.rpm'.  Pretty easy 
it seems.  Also, rpm/deb are the two standard formats for binary packages 
on GNU/Linux, so I think it would be great if we could add support for 
them in the make package.

AFAIK being able of creating binary rpms/debs without any additional
hassle (a part from a little file describing the package - or even the
system could be so intelligent that this info could be extracted from the
Info.plist stuff if any so that the info on the package is extracted from
the same files which are then compiled in the app ?)  would make our
GNUstep make package outstand in usability and simplicity all make
packages I am aware of. :-) 

> We seem to have a slightly different meaning of the term 'newbie', I believe.
> For me this term is not negative. 

OK.

> Yes, but I'd rather see *one* working app instead of several incomplete
> projects... And since the GNUstep/ObjC community is (for now) relatively 
> small, we should concentrate our man power!

I would say - we should create the tools and structures so that our man
power can concentrate.  Unless you are wishing to coordinate yourself the
writing of a mail application, why not letting the people who will do it
to concentrate and organize their powers as they wish ?  My point is
simply against trying to establish too strict a structure from the
outside.  We want a mail app, we already have two zombie mail app
projects, it's a void area - free for anybody having the will and the 
skill to take it.  If a new contributor/developer wants to take this 
area, let him decide and organize himself as he wishes.  Unless that 
developer are you :-) I don't see why we need to force people into 
doing something rather than something else.

You can't expect people to contribute to a zombie project unless you allow
them to take the project over and give it new life.  Also, because, for
example sending patches to a zombie project is like sending them to the
trash bin.  I remember sending some patches to GNUMail.app many many
months ago, I think they were accepted, but since no new release of
GNUMail.app was ever released, my patches were completely lost :-)

> And I never wanted to imply that they  need 'supervision', it's just a fact
> (well at least from my experience), that it helps a *lot* if you have sb
> telling you the crucial points, doing some code review etc. when entering 
> a new world.

It's true - it can help a lot - I agree on your idea on putting in 
the database also projects looking for volunteers etc.  

But let them choose.  Don't force them into going into old unmaintained
zombie projects.  Zombie projects and code should be cannibalized into 
new projects - that's a fact of life and it is the only way not to loose 
the code and the effort which was spent in the old project.