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

[Philippe C.D. Robert]

Hi Nicola,

On Thu, 14 Sep 2000, Nicola Pero wrote:
> Hi Philippe, 
> I think in the end we agree on most things :-) 

Yup...;-)

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

No problem...;-)
 
> 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.  

Yup, esp because almost every distro depends on rpm these days, it could help
to be added to a distro, which again would help the project!
  
> 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.

I think so, although I don't know enough about deb and rpm.
 
> 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.

Yes! But we also have to think about platforms where you don't have rpm's,
AFAIK Solaris is one of them.
   
> > 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.

Of course, I agree with all that...;-)
 
> 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.

Of course, after all it's up to every interested developer, webmaster,
graphician to chose what he/she likes to do!
  
sweet dreams, Phil
-- 
Philippe C.D. Robert
Developer - StudioSendai.com