And we don't have the modification offered for review either?
I never said it was an "official project". Elizabeth just posted the
modified version to the list.
Yeah our mails crossed in the ether :) Thanks Elizabeth.
GtkExtra (no 's') was requested on the list last week, and it's a
trivial extension to wrap. I even asked on the dev list if you or
Elizabeth could do it if you had time before I did.
And I said I would do it; and I did. Instead of putting it on a tarball,
I put in an SVN repository with some other extensions I had lying around
which were'nt in CVS so other people could use it. So maybe I shouldn't
have called it php-gtk-edge. My mistake; I apologize. Let's call it the
"Patches waiting for approval" repository instead.
I don't understand what's so hard about saying 'I have two extensions here, can I commit them' and marking them EXPERIMENTAL?
Anything but C, but I'll let Andrei comment on that since he's the
project lead. Personally I'd ask for peer review for anything intended
to go into the core and get Andrei's approval before committing a new
extension or generator changes, but that's just me.
Trouble is, that slows down development a bit. Frankly, I don't mind it;
but it would be nice to let people try out stuff as they happen.
It slows down development a bit, but it's called 'discipline'. Look at what happens in PHP development, and you'll see that _new code_ is dealt with in exactly the same way. If we didn't have that there'd be chaos.... The only difference is there's PECL for experimental extensions, but even there you're expected to mention on-list that you're planning a new extension before you actually commit it.
Users
can provide useful feedback. And so what if CVS is broken for sometime,
everyone expects CVS to be broken anyway!
Erm, you might. I don't. PHP CVS rarely is, why should PHP-GTK CVS be so?
- Steph