Re: [GNOME VFS] gob inside gnome-vfs ...

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes: 
> > But seriously, HEAD gnome-vfs is *very* unstable right now. That'll
> > settle down in a few weeks, hopefully much sooner, but till then the
> > branch is probably the right place to live :(
> 
> 	Well - this is pretty much not what we are hoping to agree for Gnome
> 2.X development, and fairly unacceptable on that basis. I understand
> that it was thought that all de-stabilizing development must be done on
> a branch, and only merged when it was stable. Thus keeping HEAD building
> and working at all times.
> 

While I think me agreeing with Michael must mean the world will end
tomorrow, ;-) - this is exactly right. *very* unstable is *very* not
OK.

Once again, let me disclaim any knowledge of gnome-vfs specifics. But
the general principles that should be applied:

 - In general, the 2.1.x branch (which is gnome-vfs HEAD right now)
   MUST always be usable. That is, it had better compile; and it
   should not create a problem that renders the desktop as a whole -
   such as Nautilus - impossible to use for daily work. If some bad
   bug is accidentally introduced, as is inevitable, then it should be
   fixed immediately, or reverted. Jacob or other build sherriffs will
   have the right to do the revert.

 - For libraries, things are really even more strict, because
   everything depends on them.

 - Therefore, if you want to do breakage, you need to make a
   "gnome-vfs-refactoring" branch or something, and do it there, then
   merge when you have Nautilus working fine again (without
   recompiling Nautilus, just to check your ABI ;-))

So those are the policies. If you break them, you are risking our
ability to get 2.2 out in 6 months with the new file selector
prototype, multihead support, cool Nautilus features, cool panel
features, launch feedback, media player, etc. etc.  and we will tell
all users it's your fault. ;-)

To toss in some opinions:

  - I'm really hoping that 2.2 (freezing in 4 months!) will mostly be
    about cool user-visible features. So the main goal should be to
    add features, and not break the existing ones. We already have a
    huge feature set (multihead, media player, metacity, vte, many
    others) waiting in the wings ready to be merged.

  - Let me reiterate Owen's point about GObject. You do _not_ want
    creating these things, or emitting signals, to happen too often.
    GObject should be used for relatively "heavy" large-scale code
    organization, in other cases a simple opaque struct with accessors
    is both faster and less error-prone, IMO. msm/src/client.h is an
    example of what I mean by such a struct.

    GNOME 2 is very small/fast compared to 1.4, 2.2 should continue
    the downward trend. It's a nice thing to have.

So, again, haven't looked at gnome-vfs changes, but. I'd apply the
above if I did.

Havoc