Re: [Nautilus-list] GnomeVFS 1.0.2 Release

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs noisehavoc org> writes: 
> Anyway, I think the gnome-vfs developers would be happy to follow a
> more restrictive policy if it were generally agreed upon and other
> modules followed it too (and no, putting `experimental' or `hack' in
> the name of the function call doesn't make it magically not count :-).

I think that does matter.

There's room for common sense here. At one end of the spectrum, adding
a five-line function like gnome_dialog_whateveritwas was something
that led to people accidentally requiring new libs, and for some
5-line trivial function that could be cut-and-pasted, this was not
worth it at all.

Adding "experimental" or "hack" to the name does discourage use of the
function and indicate that depending on it might have weird
consequences; and indeed in the case of those GTK functions, I don't
think anyone has added any dependencies on them.

Another factor in the GTK additions was that they really weren't
_useful_ except to theme engines anyhow, so there was a reasonable
expectation that apps would not use them (and that prediction has been
true so far).

The gnome-vfs changes are somewhere in between. Clearly apps will end
up using those, but the pain isn't as pointless as
gnome_dialog_whatever either.

On the whole my opinion is that changes like the gnome-vfs ones, if
made regularly in all modules, are a big pain in the ass. I would
agree that any single change is not a big pain in the ass, but
everyone doing it once in a while means someone doing it all the
frickin' time.

I think it's also nearly impossible to get decent testing on any
noticeably complex API addition in stable, because you don't have any
way to make beta releases. And historically we've released several
broken APIs (in both interface and implementation) for this reason. A
way to solve this might be first releasing the API in a separate
package and merging it when complete.


Anyhow, I do think we should have a policy here, I don't think it
should be a boneheaded no-common-sense-allowed "if nm shows a new
symbol you are evil" kind of policy, but also I would say 95% of the
time adding API is wrong.

I agree that we do not currently have a policy though, because it's
always been a topic of debate, mostly between Miguel and myself.


This is another example of the hard tension between really stable libs
and moving the UI/applications forward. We sort of have to sacrifice a
bit on both of those things, to maintain general sanity in the system
as a whole.

Havoc