Re: more gnome 2 proposal

[Alex Graveley <alex ximian com>]

Hi,

I think that the point of Jacob's proposal (as I understand it) is being
lost here. 

Arguments about a single module being easier to build are not the point.
Dependencies being easier and development more streamlined is also not
the point. They are secondary bonuses gained through the implementation
of the real purpose: large scale componentization of Gnome.

What this means is that we would not building a huge monolithic
unmaintainable beast. Your arguments do not apply as they are not
thinking in this mindset. We would be building components that rely on
eachother heavily and should be in the same package to make development
sane.  

What being a componentized framework means is: 

    Dependencies become simple interface-driven mechanisms.

    Replacing buggy or bad ideas (Imlib, GtkXmHtml) becomes simple as
    applications will simply be unable to find those deprecated
    components, or will find interface compatible wrappers to their
    replacements.

    New implementations of core components can be rolled in to the
    system by third parties. 

    Use of developmental implementations become transparent to the
    system and applications.

    Yadda yadda, read Don Box if you find this interesting :)

Your arguments wrt Microsoft are invalid as the COM/MFC/ATL split is
only present because the system is not inherantly COM based. We have the
chance to do things the right way that microsoft never had. Also be
aware that ATL and COM are for all intents "merged", along with MTS, in
COM+. And that all four are going away to be replaced with an integrated
component system: .NET.

To make a bad counter reference, Sun packages their Java as one; the VM
"component system", and print/application/gui/utility "components" are
all in a single source tree. Sun hits Java deadlines, while continually
adding useful features and components. :-)

Also, it is important to mention that this would not be a "huge" module.
We are talking about merging non-ui bonobo, non-ui gnome-libs (tiny
after the bonobo merge), gconf, oaf, and gnome-vfs into one module.
Bonobo-ui, gnome-libs-ui (tiny after bonobo merge), and gnome-canvas
into another. Possibly adding gnome-print and gnome-print-ui
respectively, but I am not adamant about it.

Also, given that everything will be merged and component-based, the
chances for refactoring are immense.

Wrt complexity of the tree, the fact that everything would 1)
component-based and b) integrated, means that we can come up with a sane
tree layout that makes sense for all of the core modules. Not just one
that makes sense for bonobo, one for gnome-libs, one for gconf... all
that make sense for the individual package but when taken with all the
other packages in the system add to a confusing non-uniform mess.

-Alex

On 11 Mar 2001 02:03:44 -0800, Maciej Stachowiak wrote:
> Alex Graveley <alex ximian com> writes:
> 
> > Hi,
> > 
> > On 10 Mar 2001 18:39:56 -0500, Havoc Pennington wrote:
> > > I think the largest and most substantive point of disagreement right
> > > now is library packaging, i.e. lots of small modules vs. two big
> > > modules. 
> > 
> > My personal view is that this is a major mistake. You run the risk of
> > continuing the tradition of difficult builds and complex dependencies.
> > 
> > Keeping everything in one or two modules is nearly guaranteed to fix
> > both problems.
> >
> 
> I disagree. Huge modules are difficult to build. This is because for
> any given module, there's only a few people that really pay attention
> to build stuff, and the bigger it is, the harder it is for these few
> people to keep things building well and have time to do anything else.
> 
> In fact, gnome-libs is the main module we have that's a big grab-bag
> of various stuff, and it's one of the hardest to build.
> 
> On the other hand, there are good solutions today for building many
> modules easily in the correct order. At Eazel we have a setup where I
> can just type `rebuild' and nautilus and all it's dependencies get
> checked out and built off the correct branches and in the correct
> order. And it's always building, because we keep a tinderbox going
> that sends us whiny mail when it does not. Alternately, I can type
> `gnome_1_4_beta2' followed by `rebuild' and build the whole GNOME 1.4
> beta from tarballs.
> 
> I can't really imagine a simpler build experience. 
> 
> If other people are really having a hard time getting compiled, we can
> distribute our eazel-hacking setup more widely (it's available but we
> don't publicize it a lot because it's pretty customized for Eazel's
> environment, and we assumed other people had their own good build
> solutions).
> 
> It's also important to recall that the set of people who build GNOME
> from source with any regularity is vanishingly small - 99%+ of users
> get everything from binary packages. Even most users using
> bleeding-edge packages like Nautilus and Evolution use binary packages.
> 
> For these users, having things split up nicely is much better than
> having one big honking package. Their needs are much more important
> than the relatively small handful of people who actually build stuff
> from source.
> 
> 
> > It is important to keep in mind that having everything in one or two
> > CVS modules does not in any way influence our ability to generate as
> > many libraries as we want, or as many binary package descriptions
> > that make sense. It also does not hinder the ability to have a
> > maintainer for a given functional area.
> > 
> 
> But it _does_ hinder the ability to release and update these
> separately, and to manage cross-dependencies effectively. Please read
> the section in the proposal about how Microsoft keeps different parts
> of the API split up and cleanly layered, and why. Do you think we're
> so much better at release engineering than Microsoft, and so much
> better at anticipating future changes, that we don't need to take the
> prudent measure of keeping the development platform well-factored?
> 
> Read the parable there about COM, MFC and ATL. This exactly parallels
> the stories of gnome-libs and imlib and GtkXmHTML - except Microsoft
> wasn't screwed, because they'd kept the COM layer and the MFC layer
> well separated.
> 
> > Your major argument for further splitting the tree is that if bugs
> > are fixed in, for instance, ZVT, it would be necessary to wait until
> > the next major release of Gnome. This is not the case as new
> > tarballs could be pushed every month or so with only bug fixes and a
> > bumped build number. Keeping the API frozen between major releases
> > is key, but this is what everyone is already advocating.
> 
> That's not the argument at all. Any change you make to a library, even
> a bug fix, introduces a risk of new bugs. Having a critical bug in zvt
> right now means you have to release all of gnome-libs to fix it -
> which means that many changes which are in general *not* critical,
> also go out. This means unnecessary risk. It also means an unnecessary
> download for users using auto-updaters - if they only need a fix from
> Zvt, why should they have to update the whole gnome-libs package?
> 
> But this is hardly the main argument. It's just one adjunct argument.
> 
> >From a release engineering perspective, it's obvious that having the
> ability to release different parts of the platform to deliver fixes on
> different timetables, or to start experimental lines of development on
> different timetables, is the right thing to do.
> 
> I have worked professionally as a release engineer, which I doubt many
> people in the GNOME community have. I've also been doing a lot of the
> release coordination work for GNOME 1.4. And from what I've seen in
> both cases, it's obvious that big monolithic packages are harder to
> manage and make it harder to deploy targeted fixes.
> 
> > 
> > What this does mean is that development for Gnome becomes a hard
> > target for third-parties. You would be able to develop against the
> > currently released frozen Gnome API, not whichever API is current
> > for a module, or whichever version of packages a given distibution
> > decides to ship.
> 
> Whether things are in one module or many does not affect the platform
> compatibility policy (which we really need to get written up and
> officially adopt).
> 
> > In addition this means that complex bugs become easier to track as
> > you can narrow bugs to between major or build releases, not a
> > certain version of libgnome, a certain version of libgnomeui, a
> > certain version of libgnomecanvas, etc.
> 
> I don't think the case where you need to know many library versions in
> details to identify a bug comes up very often. I have personally never
> seen it.
> 
> On the other hand, being able to vary versions of different libraries
> independently can be a powerful tool for pinpointing the bug. Many are
> the times when I tried cvs checkout -D "one week ago" on different
> modules in turn until a bug went away, and this allowed me to figure
> out what piece of code the bug was likely to be in. This would be way
> harder if everything was in one big module.
> 
> > 
> > Also, I believe that blurring the lines between existing core
> > modules makes for a more uniform interpretation of Gnome, one which
> > would allow contributors to easily come up to speed and start
> > working.
> 
> No, it would make it way harder to start working. Right now to
> contribute to GNOME, you only need to know one module and understand
> the APIs and conventions and design there. For complex modules, it
> gets too hard. We have a lot of people right now getting involved in
> bonobo and gnome-vfs and the like, because they only have to
> understand that one small piece of the puzzle. If the barrier to entry
> were understanding the whole GNOME platform, it would be almost
> impossible to become involved in GNOME as a weekend hacker. Notice
> that you don't see a whole lot of people getting involved in
> gnome-libs, because it has already passed that complexity threshold.
> 
> The bottom line is that gnome-libs is a huge mess, whereas individual
> purpose-specific libraries are much better managed. Dumping all of
> these well-run projects into one disastrous already messy module will
> make things way way worse and is a step in the wrong direction.
> 
> 
> Regards,
> 
> Maciej
> 
> 
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers
> 
-- 
 make: *** No rule to make target `sense'.  Stop.