Is wx salvageable? (was Re: Is Ron Lee MIA?)
On Thu, May 24, 2007 at 08:34:04PM -0400, Aaron M. Ucko wrote:
> "Paul Wise" <pabs@debian.org> writes:
>
> > I exchanged a couple of emails with him about GPG signing in April.
>
> Good to know; apologies for the false alarm.
>
> > I'm thinking there needs to be a co-maintainence team for wxWidgets,
> > and ron seems open to the idea.
>
> Sounds reasonable, though I'm spread too thin already to participate
> myself; wxWidgets is rather large and popular for anyone to take on
> solo, even with close ties to upstream.
Just so we're all nice and clear on what I think is really needed here:
Linus doesn't have any trouble with the kernel tree, and its somewhat
larger, much more popular, and probably most importantly in this
context, much better managed.
The problem here is not that anything is all on one person's head.
Its actually more like the problem of the security council where a
small group of self proclaimed superpowers all claim the right of
veto over what the others try to do. The result is not unlike that
of any other committee where the majority of players like to put Dr.
in their names.
Devoted self-interest and serving the best needs of a broadening
userbase just don't always go hand in hand, and I think that simply
throwing more eager beavers at a problem like that might give you
a bigger pile of lumber, but they aren't going to do very much to
improve your architecture.
So, if this lib is going to have a long and prosperous future,
then what it really needs is for its most devoted users to take
control over their own future with it from a grass roots level.
They are the people who are actually testing it in real use
situations, and they are the people most able to identify what
features are missing and what bugs are troublesome.
Perhaps we need to get this in git and set up a system where
people can push changes that they tested locally through a web
of related users toward inclusion in a new package release.
That seems a lot more sustainable than having me or some arbitrary
team foisting random new releases upon the users in the hope that
more of them will swim than sink. Changes that apps in the distro
require can percolate into a new upload in a controlled and well
tested fashion, and changes that they don't require, or that are
harmful to too many of them can be excluded until they are refined.
UNPUBLISHED PROPRIETARY SOURCE (their caps not mine) and its ilk
should also be less likely to slip in and be nearly included in a
release with more eyes overseeing what gets pushed to the common
tree.
Actually maintaining the package that gets uploaded is trivial
beyond the mythical Good Judgement, its auditing the changes made
to the library api and implementation itself that is the really
tricky and ultimately the only important task, which is why I think
that what we need here is not really a team of co-maintainers so much
as a way to empower the existing and future co-dependents to share
their knowledge of what needs to change where and when.
The lib itself is pretty useless without the authors of dependent
apps, so ideally it should evolve to suit their needs, not the
other way around, whatever the rule of thumb for using a 'framework'
is supposed to be.
So if you're still reading at this point, and think I'm talking
about you and that this is a way you'd like to get _your_ work
done effectively, then give me a ping in private mail and we'll
see what sort of infrastructure we'll need to get it bootstrapped.
This isn't really a package that takes well to people dabbling in
it, but I really do think it could benefit greatly at this point
in its lifecycle from engaging its active users far more closely.
Cheers,
Ron
Reply to: