Re: GnomeVFS maintainership change - hmm

[Michael Meeks <michael ximian com>]

Hi Havoc,

On Mon, 2002-12-09 at 23:58, Havoc Pennington wrote:
> It's fairly unfun to discuss this kind of issue in a big mailing list

	Sure - but I think it's more important to say the hard things, and it's
unfair not to. I mean - if someone had told me before last week that I
ought to wash occasionally then I could have avoided 20 years of ruining
people's paintwork ;-)

> I know of several people (from several affiliations including "none,"
> so no conspiracy theories please) who have expressed concerns about
> the technical directions proposed by Alex G.

	Well - me too; I've certainly been concerned too[1], and I similarly
have more respect for Alex L's judgement. But that doesn't alter the
fact that this is a pretty shoddy way to go about doing anything.
Neither as I said before does it accurately reflect the people doing the
real work. It seems to me that unless the people that produce the code,
(and more fix the bugs) get some degree of control they are going to
have little incentive to do so.

> That's not to say other people can't work on the code and make good
> contributions, just that I see the value in Alex L helping keep things
> on track. Hopefully everyone can work together.

	My feeling is that gnome-vfs needs little change. It doesn't need new
APIs[2] rather it needs a prolonged period of bug fixing, robustness
testing, efficiency improvement, and that sort of good stuff. I believe
if anyone had spoken to Alex G - they would have discovered that he
broadly shares that view.

	Anyhow - none of the responses or the above waffle is relevant to the
immediate problem: which is that none of the people who have done and
are doing the ongoing maintenance work on gnome-vfs are 'maintainers'.

	I'd respectfully suggest again then, that a minimum fix for this is
restoring balance by appending Alex G's name to the list of maintainers.

	Comments ?

		Michael.

[1] - but then I'm also concerned by new APIs that ram random gpointers
      at handles grabbed from random strings ;-) unlike the kernel we
      can't return EFAULT.
[2] - or at least it needs GEPs and extreme conservatism with them -
      interesting that the ioctl stuff was not discussed using that
      process.
-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot