I think the project, as it stands, is a bit of a chicken with its head cut off. It is wonderful that Richard has stayed involved to the extent that he has, but I think he's spread pretty thin right now 8^)
Wrt pulling changes into core, I suggest the following needs to happen: - The developer of the changes needs to explain what the features are and what the motivations are for them, or what is being fixed. Not just throw a link at the list to a changeset. I am not motivated to try and guess intent from a set of diffs. This does not need to be a big deal, just a short explanation. - Following that there needs to be some consensus on the group that the changes are in general a good idea. And of course certain folks, like Richard and Alex have BDFL privileges to operate without consensus. - Then, the specific changes should be reviewed by a committer. I am happy to do it, but I will not do it before the above it satisfied, nor will I advocate on behalf of others I don't know. They need to advocate for themselves. Convince the group that the change is worthwhile and interesting. The tone of this conversation has not motivated me to help one iota. - Once the patch passes muster, we need to decide what branches it goes against. Sounds like this is an optimization, so long as it is not an api change, it could go into 1.1 as far as I'm concerned. For example, your change to vertexbuffer.py (c5514d55e5) looks pretty trivial. How much faster is it? Some quick measurements would be very helpful. I see the checkin comment says 3x faster. That's nice, why not say so in the original email? Specifically what change sets do you want pulled in? Your original email is quite vague in this regard. -Casey On Wed, Apr 28, 2010 at 4:11 AM, Florian Bösch <[email protected]> wrote: > On Apr 27, 7:42 pm, Joe Wreschnig <[email protected]> wrote: >> Did you look at my repository to see if the thing in it should be >> merged? I doubt it, since you didn't comment on it at all. So even >> your preferred method is not getting my changes reviewed or merged. > > I did not look at your changes because I do not have push rights and I > didn't feel like a dedicated project maintainer (the main reason I > don't even want push rights). > > What you raise is valid though, as it is, moving the project forward > doesn't work very well (so far nothing changed from the svn > situation). I'm assuming those dozen or so people who had commit > rights on SVN do have push rights on the hg repo now... > > The question is, how would we organize ourselves? I think the linux > model can work reasonably well. This boils down to a few questions we > must answer. > > - Who has dedication enough to scan (the ML, downstream repos) and > review all changes that are suggested in some way on a daily basis? > - Who has a focus on a specific area (for instance the cocoa port, > backports, bugfixes) and has dedication enough to be a "deputy" for > this, acting as a gateway for that topic. > - Where do we document the organization structure such that the random > person with a change can figure out where to go with his changes? > > -- > You received this message because you are subscribed to the Google Groups > "pyglet-users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/pyglet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
