On Thu, May 24, 2007 at 08:34:04PM -0400, Aaron M. Ucko wrote: > "Paul Wise" <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
