Re: another gnome-libs .02

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs eazel com> writes: 
> I agree we would have these benefits but we must realize the cost in
> increased coordination complexity. 
> 
> Getting all the different packages together for GNOME 1.4 beta 1 was
> already non-trivial, and that was a case where we could use an old
> release for many modules, something that will not be true for
> compat-breaking releases.
> 

This is coordination complexity getting the modules on the ftp site
and contacting maintainers about release plans, etc. The bundling
creates coordination complexity getting the modules written and
maintained in terms of fixing bugs, etc. ... that's the distinction I
would draw. It also creates conflicts about when freezes happen and
such.

So the conclusion there is you bundle stuff into a big package _after_
it's already written and pretty bug-fixed. i.e. you keep it in a
separate place until it's done, and it goes in libgnomeui when it's
ready to ship so that it's easy for app developers to find and easy
for us to keep track of when releasing tarballs.

And then stuff that isn't done won't delay libgnomeui.

The most important reason for clear module lines though is to have a
defined scope for each module - as I said, putting stuff in a
general-purpose lib as soon as 2 apps use it is my idea of project
suicide.

(Long-term, I also like Owen's idea of having a public process for
discussion of new APIs and features - something like
http://python.sourceforge.net/peps/. We would like that for GTK. So
this ensures that due diligence always gets done for new features.)

Havoc


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers