FWIW, I fully agree with Casey. Here are some further comments: On Wed, Apr 28, 2010 at 8:23 AM, Casey Duncan <casey.dun...@gmail.com>wrote:
> 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. > Right. Explaining each proposed change can be done in an issue report, or in this group, or both (with cross-references). It needs to be done "one proposed change at a time", and you need to make it clear exactly which diffs are involved with each change -- you can't ask other developers to scan a lumped-together diff and sort out which ones have what purpose. For each proposed change being discussed, it needs to be very clear whether that change is a bugfix or a pure optimization or an enhancement, and if an enhancement, whether it's an incompatible change in any way. If the change already exists somewhere, it needs to be clear whether that's in a final form (subject to review) or is still preliminary or experimental. An advantage of using the issue tracker (one issue per proposed change) is that the discussion can be extended in time and still be captured in one place, together with pointers to the related code changes if they ever occur. An advantage of the group is that all the developers will see it right away and be asked for their opinion. I suggest using both, with a summary in one mail to the group and the details (if there are any details yet) in a new issue. > - 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. > Yes. In general, the standards for consensus would get higher, the more user-visible the change is -- so bugfix is easiest to get consensus on, and incompatible change is hardest (the threshhold of usefulness would be higher as well). > - Then, the specific changes should be reviewed by a committer.... > > - 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. > I agree that bugfixes and optimizations (after the above-described process) could go into the 1.1 branch; as I said in another thread, I don't know whether it's high priority that they do, since that depends on future release plans. BTW for bugfixes and pure optimizations it is reasonable for almost all the discussion to occur in the issue tracker, up to the point where a specific patch exists that the developer thinks should be applied. Then the group can be asked for someone to volunteer to review that change and if necessary apply it. It's for enhancements (api changes) that earlier group discussion is essential. (BTW, I also agree that we sorely need to update our most public-facing info to be more accurate and up to date. I can take a stab at that, to the extent that I know what it should say and have commit rights, both of which are only partly true. What I don't know is 1.1-branch status, anyone's plans to complete the 1.2dev refactoring, cocoa branch status and plans, release plans. I have commit rights to the code and its wiki, but not to the group home page or the pyglet.org home page.) - Bruce Smith -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to pyglet-us...@googlegroups.com. To unsubscribe from this group, send email to pyglet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
