Re: [GNOME VFS] gob inside gnome-vfs ...
- From: Seth Nickell <snickell stanford edu>
- To: Havoc Pennington <hp redhat com>
- Cc: Michael Meeks <michael ximian com>, Ian McKellar <yakk yakk net>, vfs <gnome-vfs ximian com>, gnome-hackers gnome org
- Subject: Re: [GNOME VFS] gob inside gnome-vfs ...
- Date: 20 Jun 2002 12:19:04 -0700
> - 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. ;-)
Honestly, since all changes we are interested in making are going to
have some destabilizing effect, and as you point out there's already a
huge number of features targeted for 2.2 (and hence its not likely that
the applications using GnomeVFS will use those fetaures for their GNOME
2.2 release) there's no particular reason that the GNOME 2.2 release of
GnomeVFS has to be GnomeVFS 2.2 rather than GnomeVFS 2.0.x. I still hope
to have the bulk of feature changes done within the month, but its no
disaster if GnomeVFS 2.0.x gets used.
That said, I disagree with Ian's assessment of GnomeVFS's current build
state. I have been trying to make sure it always builds, and, unless you
use one of the new features (which are in their own .h files, etc), no
stability problems should be introduced. I will be making changes
affecting the module interface soon, which could potentially affect
stability, but I fully intend to swap them in only after they are
working reasonably well on my own machine.
*grumble*,
-Seth
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]