The future of pyglet
Alex Holkner
It has probably become quite apparent over the last few months that
pyglet is not being maintained or developed. Both Richard and I have
become quite occupied with other, er, occupations this year, and
without the necessary free time to devote to pyglet.
Richard and I started working on pyglet in August 2006, initially as
an experimental OpenGL front-end for Python, and then as an
alternative to PyGame/SDL. Looking at the early design documents [1],
it's satisfying to note that all of the main goals were achieved, and
most of the "pie in sky" ideas have been implemented as modules
specifically for pyglet by other developers.
In June 2007 the pyglet 1.0alpha1 was published, and after months of
fairly intensive testing, feedback and fixing from hundreds of
developers, pyglet 1.0 was released in early 2008. pyglet-1.1,
released in August 2008, has been downloaded some 13,000 times.
While there have been no subsequent releases or feature enhancements
since then, the pyglet community continues to grow. There are
currently 670 members in the pyglet-users mailing list, with a new
member joining every one or two days.
The issue tracker is currently filled not just with bug reports, but
also many patches for those bugs which have yet to make it into the
code base. Many bugs that have been fixed in trunk have not been
back-ported to the maintenance branch. At this stage it appears that
mine and Richard's non-involvement with pyglet is harming the project.
If you have some time to contribute to pyglet, I invite you now to do
so directly. Email me privately with your Google account ID (email
address) so I can add you to the googlecode project committer list.
This will give you full access to SVN, the issue tracker and wiki.
I am not restricting access to people with specific patches to commit
or ideas to implement. For example, there is substantial work
available just in verifying issues in the tracker, applying patches
and closing duplicates. The trunk is a mostly-complete refactor of
the codebase with several new features that possibly just needs
documentation and fixes to complete. I'm hoping that some sort of
semi-organised anarchy will form to continue pyglet maintenance and
development.
I am looking forward to granting you all commit access!
Regards
Alex
[1] http://code.google.com/p/pyglet/source/browse/trunk/DESIGN?spec=svn19&r=19
Florian Bösch
> If you have some time to contribute to pyglet, I invite you now to do
> so directly. Email me privately with your Google account ID (email
> address) so I can add you to the googlecode project committer list.
> This will give you full access to SVN, the issue tracker and wiki.
to a dvcs and following the Linux model, where Alex becomes Linus,
Richard and whoever else becomes core developers and everybody else
who wants his favorite patch in becomes a contributor that has to go
trough the gates of the core teams pull/push. Alex and Richard would
still have some work in the short term, but it'd allow to build a core-
team that could eventually replace them and ensure a continuing
quality of changes.
Cheers,
Florian
Seo Sanghyeon
> I don't think that'd work particularly well. I would suggest switching
> to a dvcs and following the Linux model, where Alex becomes Linus,
> Richard and whoever else becomes core developers and everybody else
> who wants his favorite patch in becomes a contributor that has to go
> trough the gates of the core teams pull/push. Alex and Richard would
> still have some work in the short term, but it'd allow to build a core-
> team that could eventually replace them and ensure a continuing
> quality of changes.
I disagree, because:
1. I don't like DVCS.
2. Someone has to do the repository migration. (Are you volunteering?)
3. As you said yourself, "playing Linus" still takes some time, which
defeats the whole point of the exercise.
--
Seo Sanghyeon
Nicolas Rougier
I agree with Florian and I think that giving full SVN access to
anybody might make things a real mess in a short period of time. We
need some sort of roadmap and identify priorities (bug fix, adding
feature, doc, ...). I think Alex made a fantastic job with the pyglet
abstraction and I would be happy to code for pyglet under his
direction. Also, there is already a lot of contribution that could
make it into pyglet (gletools, simplui/kytten, ...).
Nicolas
Francesco Pischedda
I agree that opening the repository to everyone interested could be a
problem; if in a short period of time Alex could spot some talend
contributors that share the same vison of pyglet, the work of
patch/code review can be offloaded to said developers
p.s. I've done a quick research in "vcs to dvcs migration" topic and
it seems that it's not that difficult to migrate subversion to
mercurial; I can try to do the migration if you agree
2009/8/14 Nicolas Rougier <nicolas...@gmail.com>:
"Rendete ogni cosa il più semplice possibile, ma non di più" (Albert Einstein)
"You are what you choose today, not what you've chosen before"
"Unix IS user friendly. It's just selective about who its friend are"
Mikael Lind
> I agree that opening the repository to everyone interested could be a
> problem; if in a short period of time Alex could spot some talend
> contributors that share the same vison of pyglet, the work of
> patch/code review can be offloaded to said developers
>
> p.s. I've done a quick research in "vcs to dvcs migration" topic and
> it seems that it's not that difficult to migrate subversion to
> mercurial; I can try to do the migration if you agree
Sounds great. I've only used Git but I too like DVCS. I suppose
Mercurial still makes better sense than Git for Windows development.
--
Mikael Lind
http://elemel.se/
Florian Bösch
> I disagree, because:
> 1. I don't like DVCS.
decentralized development then.
> 2. Someone has to do the repository migration. (Are you volunteering?)
> 3. As you said yourself, "playing Linus" still takes some time, which
> defeats the whole point of the exercise.
and regardless of what vcs you use, trying to get there with the help
of the lead developer will be far smoother then letting anarchy ensue,
in my opinion.
Richard Jones
> I agree with Florian and I think that giving full SVN access to
> anybody might make things a real mess in a short period of time. We
> need some sort of roadmap and identify priorities (bug fix, adding
> feature, doc, ...). I think Alex made a fantastic job with the pyglet
> abstraction and I would be happy to code for pyglet under his
> direction. Also, there is already a lot of contribution that could
> make it into pyglet (gletools, simplui/kytten, ...).
Alex and I believe that pyglet should not grow in scope (actually,
Alex would argue that pyglet covers too much scope right now). It
should be a solid core on which those 3rd party libraries may be
developed. See the design document link that Alex posted in his
email[1].
To that end the open SVN access isn't really that great a problem:
there should always be a tight rein on any sort of feature creep and
definitely an eye for backwards compatibility in any commit.
Let's see how we go with contributors using SVN before we jump off on
any DVCS tangent.
Richard
[1] http://code.google.com/p/pyglet/source/browse/trunk/DESIGN?spec=svn19&r=19
Martin O'Leary
> Alex and I believe that pyglet should not grow in scope (actually,
> Alex would argue that pyglet covers too much scope right now). It
> should be a solid core on which those 3rd party libraries may be
> developed. See the design document link that Alex posted in his
> email[1].
>
> To that end the open SVN access isn't really that great a problem:
> there should always be a tight rein on any sort of feature creep and
> definitely an eye for backwards compatibility in any commit.
Something that would be really useful for those of us interested in
continuing the project would be a consensus on what the appropriate
scope for Pyglet should be. While that design document is very
interesting, and certainly gives a feeling for the flavour of Pyglet,
it's somewhat out of date, as far as current Pyglet development goes.
I'd be very interested to hear both Richard and Alex's opinions on
this matter, as they're the most familiar with Pyglet from a technical
perspective. In particular, the future of the "experimental" branch is
something I'd like to talk about.
While I'm with Alex on the idea of "semi-organised anarchy", we have
just increased the number of people who can make commits by more than
a factor of five. I think we need to start thinking about what form
that semi-organisation should take.
Martin
Florian Bösch
repository from the google svn one. I'm hosting it on my server and
its also pushed to bitbucket.
http://hg.codeflow.org/pyglet
http://bitbucket.org/pyalot/pyglet
I'm going to add some patches which I need (mainly concerned with
evdev). You can let me know if you have some repo you want me to pull
from or send me quilts/patchsets via email.
Cheers,
Florian
Steve Johnson
it wouldn't be hard for us to use hg-svn for our working copies and
treat the svn server as a push target. Is that an acceptable solution,
or are there other factors?
I wold also be in favor of switching over to a DVCS completely,
preferably hg because Google Code supports it.
On Aug 14, 7:35 am, Florian Bösch <pya...@gmail.com> wrote:
> I've used a combination of svnsync and hg convert to create a hg
> repository from the google svn one. I'm hosting it on my server and
> its also pushed to bitbucket.
>
Martin O'Leary
>
> I mentioned switching to a DVCS to Alex in another email, and he said
> it wouldn't be hard for us to use hg-svn for our working copies and
> treat the svn server as a push target. Is that an acceptable solution,
> or are there other factors?
>
> I wold also be in favor of switching over to a DVCS completely,
> preferably hg because Google Code supports it.
I think a lot of this is tied up in the question of where the future
of Pyglet lies. If we're going to be adding heaps of new
functionality, which Richard and Alex are both against, and which I at
least have fairly strong reservations about, then yes, we probably
need a DVCS system. However, if we're considering Pyglet to be roughly
feature-complete, and only talking about bug fixes and minor
enhancements, then the current SVN system seems perfectly acceptable.
At the moment, it seems like people have a new toy, and are rushing to
play with it. Let's sit back, fix the bugs that we've got, and have a
discussion about where we'd like things to go, development-wise. Then
we can decide what the appropriate technical solution should be.
Martin
Florian Bösch
> I think a lot of this is tied up in the question of where the future
> of Pyglet lies. If we're going to be adding heaps of new
> functionality, which Richard and Alex are both against, and which I at
> least have fairly strong reservations about, then yes, we probably
> need a DVCS system. However, if we're considering Pyglet to be roughly
> feature-complete, and only talking about bug fixes and minor
> enhancements, then the current SVN system seems perfectly acceptable.
1) if you give everybody commit rights, chaos ensues.
2) if you limit commit access to a small number of people, the whole
burden of reviewing/applying patches falls onto their shoulders.
A DVCS is actually better suited to distribute the workload of moving
a project forward, whatever the destination, be that less bugs or more
features.
Nicolas Rougier
I also would prefer to have first bug fixed and then take time to
think on whether some features are necessary and how to integrate them
within the existing architecture. If there is no principal maintainer
anymore, I guess we also need some procedure to decide whether or not
to include this or that feature. In this context, having a minimal
bulletproof pyglet would certainly help further development.
Nicolas
Tartley
is a worthy endeavour, it's not what I'm looking for here.
On Aug 14, 12:47 pm, "Martin O'Leary" <m.e.w.ole...@gmail.com> wrote:
> 2009/8/14 Steve Johnson <dior...@gmail.com>:
Martin O'Leary
> I don't think SVN is suited if many people want to contribute.
> 1) if you give everybody commit rights, chaos ensues.
> 2) if you limit commit access to a small number of people, the whole
> burden of reviewing/applying patches falls onto their shoulders.
>
> A DVCS is actually better suited to distribute the workload of moving
> a project forward, whatever the destination, be that less bugs or more
> features.
At the moment we have 11 "contributors", including Richard and Alex. I
think we can safely assume that not all of these people are going to
be regular contributors - everyone starts with the best of intentions,
but interest is going to wane after time. I think we can assume a
maximum of ten people contributing in the long term, with only about
half that number genuinely working on the project on a regular basis.
Even those numbers seem quite optimistic to me, and they don't sound
like they're going to lead to chaos.
Pyglet isn't GNOME or the Linux kernel. It's a fairly small project,
with a small number of users. Switching to a DVCS is a technical
solution to a social problem that doesn't exist, and I think it's
distracting from the discussion we ought to be having, which is that
of the future of the project in general.
Martin
Florian Bösch
> 2009/8/14 Florian Bösch <pya...@gmail.com>:
> At the moment we have 11 "contributors", including Richard and Alex. I
> think we can safely assume that not all of these people are going to
> be regular contributors - everyone starts with the best of intentions,
> but interest is going to wane after time. I think we can assume a
> maximum of ten people contributing in the long term, with only about
> half that number genuinely working on the project on a regular basis.
> Even those numbers seem quite optimistic to me, and they don't sound
> like they're going to lead to chaos.
> Pyglet isn't GNOME or the Linux kernel. It's a fairly small project,
> with a small number of users. Switching to a DVCS is a technical
> solution to a social problem that doesn't exist, and I think it's
> distracting from the discussion we ought to be having, which is that
> of the future of the project in general.
continue working with it as if it was SVN. I've left SVN behind some
years ago, and I appreciate the flexibility of it when its handy. The
social problem might or might not exist, or it might or might not
arise, but sticking to a centralized vcs you'll never know, because
you'll have forced people into one way to interact. I'm not going to
go trough the hassle with SVN again and I'll stick to DVCSes for easy
cloning, pulling, pushing, merging, queue adding/dropping and patchset
application.
Tristam MacDonald
+1. I like pyglet because it doesn't try to be a PyGame - while that
is a worthy endeavour, it's not what I'm looking for here.
On Aug 14, 12:47 pm, "Martin O'Leary" <m.e.w.ole...@gmail.com> wrote:
> 2009/8/14 Steve Johnson <dior...@gmail.com>:
> I think a lot of this is tied up in the question of where the future
> of Pyglet lies. If we're going to be adding heaps of new
> functionality, which Richard and Alex are both against, and which I at
> least have fairly strong reservations about, then yes, we probably
> need a DVCS system. However, if we're considering Pyglet to be roughly
> feature-complete, and only talking about bug fixes and minor
> enhancements, then the current SVN system seems perfectly acceptable.
>
> At the moment, it seems like people have a new toy, and are rushing to
> play with it. Let's sit back, fix the bugs that we've got, and have a
> discussion about where we'd like things to go, development-wise. Then
> we can decide what the appropriate technical solution should be.
>
> Martin
--
Tristam MacDonald
http://swiftcoder.wordpress.com/
George Oliver
On Aug 14, 6:24 am, Tristam MacDonald <swiftco...@gmail.com> wrote:
>
> > +1. I like pyglet because it doesn't try to be a PyGame - while that
> > is a worthy endeavour, it's not what I'm looking for here.
>
> +1 for trimming pyglet down, rather than adding features.
support to the above. I appreciate pyglet for precisely the reasons
Tartley noted.
Ben Smith
I've been reading this thread with interest. I would like to help out
on pyglet maintenance, particularly I'd be interested (for now) in
doing the appropriate things to open issues. So far, I've been
pleased with the scope of pyglet, though I haven't used the font and
text stuff myself(yet).
I think what should be done for the immediate future of pyglet is to
take care of all of the important open issues and get a release out
without a scope change. While that's going on, we can easily discuss
longer-term choices and attempt to determine the fashion in which
pyglet should continue, whether it be a minimalist core with easy ways
to extend, or whether it should become emacs(not a slam on emacs, I <3
it though that's not where I want pyglet to go, myself).
I enjoy DVCS, but sort of as a corollary to the immediate future, we
don't need to jump head first into a different version control system
in order to get an updated release out. I personally can use git
locally and just build patches for what is to be published via svn, no
big deal. Or I can just use svn for now. One issue that comes up in
either case is that some entity(individual or committee) needs to
authoritatively determine whether things are ready for release. What
may be a determining factor for version control is whichever system is
going to match this entity's style and composition best. If that is
the case, before making version control decisions, we need to see how
the next wave of pyglet authority shakes out and we'll have a much
better idea which technologies to apply.
My $0.02,
-b
Richard Thomas
Been following all this and for my money switching any part of project
management (whether that be source control, issue tracking, discussion
groups) is not worth the effort for one simple reason: its not about
what's better and what's worse, it's about what works and what
doesn't. It seems that the discussion of DVCS going is trying to solve
a problem that may not exist yet. Switching to a broader base of
developers will cause some problems but would it not be best to see
what those problems are before trying to fix them?
In response to Martin's concerns about the direction that pyglet is
going, obviously I don't know and I don't want to make decisions
without the input of either Alex or Richard but as we have this new
base of interested developers we should get some discussion going
(although possibly pyglet-users is the wrong place for it).
Having just thought about that last comment I speculatively created
the pyglet-devs group.
Richard.
joe hall
would hack the system to pieces, leaving nothing to base future
development on. Given that the serious "pygleter" would do everything
to keep the core intact, there are many of us who with all good
intentions, will just mess up the base, due to some small oversight of
misconceptions on the "way we would prefer things to be done". A new
core team is a controlled migration, that is required move the pyglet
gem forwards:)
We love your work Alex, don't just go flush it away now.
Tristam MacDonald
I agree with Florian, Opening up the floodgates to the core of pyglet,
would hack the system to pieces, leaving nothing to base future
development on. Given that the serious "pygleter" would do everything
to keep the core intact, there are many of us who with all good
intentions, will just mess up the base, due to some small oversight of
misconceptions on the "way we would prefer things to be done". A new
core team is a controlled migration, that is required move the pyglet
gem forwards:)
We love your work Alex, don't just go flush it away now.
Francesco Pischedda
2009/8/15 Tristam MacDonald <swift...@gmail.com>:
Florian Bösch
> well, private branch are the common and required features of dvcs-es and I agree
1) create a branch (named or unnamed) and continue developing it,
merging changes in from the tip as you go, when you commit this head
will be visible.
2) create a clone of the repository where you work on the changes,
pull and merge from the upstream repository and when you're done
commit, no new branch will be created for others.
3) create a Queue which gets re-applied after you've pulled from
upstream repositories, therefore creating a local "view" of what you
do, you can add/drop the whole queue at any time (particularly handy
if somebody wants to try out your changes with his own non published
clone)
I really don't see what's the handwaving over "ohno don't change the
VCS". It's a nobrainer. mercurial is as easy to use as SVN (it allows
you to ignore most of the fancy features), it is a hell of a lot
faster doing a full checkout, it's a hell of a lot faster displaying
diffs, it's a *lot* more flexible, the migration to it has been done
and closed...
Now you can cry all you want how this is a solution in search of a
problem, or how it's all to risky or you simply hate DVCSes, at the
end of the day, Mercurial *is* better then SVN in every respect.
Richard Thomas
the arguments for or against distributed version control. If it seemed
important I would reason the whole thing out and then I might come
down on one side or the other. However, it isn't important. What we're
doing here is going from a project with one or two commiters to a
project with five to eight commiters if that. It's hardly the kind of
expansion that needs this kind of thought put into project management.
But even if a change of source control would be good and even if it
would be good enough to upset the established mechanisms and even if
would be good enough to make potentially interested developers stray
from what everyone is familiar enough with to use we should still wait
to see if there is a problem. If development can continue smoothly
without excessive time commitments from anyone then we should let it
continue. It's not about hating DVCSs. It's not about the features we
might want to use. It's not even about fear of a "risky" change. It's
about caring about the source more than the source control. Because
without caring about the source the source control is really just
control... Telling, no?
Richard.
Florian Bösch
> Your vehemence in support of Mercurial is quite evident. I don't know
> the arguments for or against distributed version control. If it seemed
> important I would reason the whole thing out and then I might come
> down on one side or the other. However, it isn't important. What we're
> doing here is going from a project with one or two commiters to a
> project with five to eight commiters if that. It's hardly the kind of
> expansion that needs this kind of thought put into project management.
anarchy ensue, in my opinion that's an excellent time to think about
project management and how to avoid this in the future. Part of
avoiding this is not having a single bottleneck of source control/
group of people who are capable of holding up the whole. Making it
easy for people to clone the source and pulling/pushing among
themselves virtually guarantees that no matter what happens, it will
move forward.
> But even if a change of source control would be good
> and even if it
> would be good enough to upset the established mechanisms
instead of svn up/commit is not mentally challenging.
> and even if
> would be good enough to make potentially interested developers stray
> from what everyone is familiar enough with to use we should still wait
> to see if there is a problem.
go in un-reviewed, at best somebody makes a post-mortem review and
will revert them if necessary, not quite optimal.
> It's not about hating DVCSs. It's not about the features we
> might want to use. It's not even about fear of a "risky" change. It's
> about caring about the source more than the source control. Because
> without caring about the source the source control is really just
> control... Telling, no?
care, I propose not putting it into a shitty garbage bin like SVN and
having a flat "free for all" commit process. I have left SVN (and
centralized VCSes) behind a long time ago, and I'm not going to go
back to the jumping trough hoops days of finding social/technical
solutions to make SVN happy. The bottom line is that your single choke-
point of control over the repository just collapsed in itself, and
instead of rethinking how you can structure interactions, you continue
to build the next train-wreck to happen.
John Lehmann
> While svn has served the development team well, it needs to be admitted that svn does not serve the needs of non-committers as well as a DVCS does. Because svn only provides its features such as version control, branching, etc. to people with commit privileges on the repository it can be a hinderance for people who lack commit privileges. But DVCSs have no such limitiation as anyone can create a local branch of Python and perform their own local commits without the burden that comes with cloning the entire svn repository. Allowing anyone to have the same workflow as the core developers was the key reason to switch from svn to hg.
> Orthogonal to the benefits of allowing anyone to easily commit locally to their own branches is offline, fast operations. Because hg stores all data locally there is no need to send requests to a server remotely and instead work off of the local disk. This improves response times tremendously. It also allows for offline usage for when one lacks an Internet connection. But this benefit is minor and considered simply a side-effect benefit instead of a driving factor for switching off of Subversion.
I don't know that this will be a greatly important issue for Pyglet - it remains to be seen how many active developers there are going to be.
John
Richard Thomas
* Alex has not quit, I believe he owned up to his "non-
involvement" (which was evident beforehand).
* Anarchy has not ensued. The closest thing we have to anarchy is
currently this discussion.
* We don't have a development culture, disucssion of code review is
rather premature. Pyglet has presumably not had code review so far...
* Any implementation of any aspect of project management should be
informed by usage and experience in the context in which that
implementation will take place. We don't know how many active
developers we'll have, what kind of discussion dynamic will go on,
whether anyone will partake of an active review process, how much Alex
and Richard are going to be involved from this point on.
* Finally, not that you should really care for my opinion but I'm
rather disappointed by your comparison of what's happening to a train
wreck. Pyglet development had stagnated for a long while and this is
an opportunity to revitalise it. While I'm sure your intentions are as
good as mine in that regard it seems doubtful that I can see eye to
eye with you on this issue.
Richard.
Florian Bösch
> * We don't have a development culture, disucssion of code review is
> rather premature. Pyglet has presumably not had code review so far...
same page.
> * Any implementation of any aspect of project management should be
> informed by usage and experience in the context in which that
> implementation will take place. We don't know how many active
> developers we'll have, what kind of discussion dynamic will go on,
> whether anyone will partake of an active review process, how much Alex
> and Richard are going to be involved from this point on.
> * Finally, not that you should really care for my opinion but I'm
> rather disappointed by your comparison of what's happening to a train
> wreck. Pyglet development had stagnated for a long while and this is
> an opportunity to revitalise it. While I'm sure your intentions are as
> good as mine in that regard it seems doubtful that I can see eye to
> eye with you on this issue.
can fill that role if needed, otherwise it stays out of your way. SVN
is incapable of giving you the flexibiity should the need arise.
Sticking to SVN guarantees that non-comitters will not contribute and
that you're holding back any sort of social/structure development
beyond SVN capabilities. It is thus so dissapointing to see you and
your ilk, who presumably cares about the project, become its greatest
hindrance.
Martin O'Leary
> beyond SVN capabilities. It is thus so dissapointing to see you and
> your ilk, who presumably cares about the project, become its greatest
> hindrance.
Okay, this here is the point where this discussion became out of line.
I spent yesterday afternoon fixing Pyglet bugs and committing the
fixes to the repository. Richard T did likewise yesterday evening. If
doing that, and expressing concern about unneeded changes to the
source control system makes us Pyglet's "greatest hindrance", then I'm
very sorry, but we intend to be a hindrance for a good time to come.
I've tried to remain civil on this issue, largely because I don't
think it's very important. I certainly don't think it's a decision we
need to make in the near future. I think any move away from
centralisation of the project, at this time of "anarchy", is quite
likely a mistake, but probably not a huge one. It's obvious that you
disagree with quite some force. However, I don't think this entitles
you to make personal attacks.
As an aside, Florian, I note that you've been posting links to your
Mercurial repository on the issue tracker, saying that various issues
are fixed in it. Would it be possible for you to either commit these
changes to the SVN repo, or if you don't have access (I don't see your
name on the list), provide patches so that someone else can. Whatever
we decide to do, I don't think we benefit from having two version
control systems in parallel use.
Martin
Florian Bösch
> 2009/8/15 Florian Bösch <pya...@gmail.com>:
> Mercurial repository on the issue tracker, saying that various issues
> are fixed in it. Would it be possible for you to either commit these
> changes to the SVN repo, or if you don't have access (I don't see your
> name on the list), provide patches so that someone else can. Whatever
> we decide to do, I don't think we benefit from having two version
> control systems in parallel use.
changes or extract patchsets. I will not use SVN and go back to the
dark ages.
Alex Holkner
> As an aside, Florian, I note that you've been posting links to your
> Mercurial repository on the issue tracker, saying that various issues
> are fixed in it. Would it be possible for you to either commit these
> changes to the SVN repo, or if you don't have access (I don't see your
> name on the list), provide patches so that someone else can. Whatever
> we decide to do, I don't think we benefit from having two version
> control systems in parallel use.
Given the extent of the disagreement here, perhaps a reasonable
compromise can be to accept Florian's (and others') Mercurial links as
if they were patches sent to the tracker. So long as the issue
remains open (and not marked Fixed as long as the patch has not been
committed to SVN), another contributor who is comfortable with using
both SVN and Mercurial can integrate the change at their convenience.
Just my 2c.
Cheers
Alex
Martin O'Leary
> Given the extent of the disagreement here, perhaps a reasonable
> compromise can be to accept Florian's (and others') Mercurial links as
> if they were patches sent to the tracker. So long as the issue
> remains open (and not marked Fixed as long as the patch has not been
> committed to SVN), another contributor who is comfortable with using
> both SVN and Mercurial can integrate the change at their convenience.
>
I'm happy to do that. It would just make things slightly easier if the
contributor of a patch could provide a patch file, given that it's a
one line command to generate one. It's a fairly minor issue, though.
Martin
Lucas
My 2 cents:
I think that this discussion has moved from the important topic.
I don't think it is important right now which VCS we keep using (it is
just a tool),
the important thing right now, is how pyglet is going to keep alive
(maintenance, bug fixing, improvements, port to python 3, etc).
I agree we Tristam, we must start by merging back maintenance branch
with trunk.
regards,
Lucas
Steve Johnson
antagonistic and unhelpful. So let's back up a bit.
The main issue right now is that there are still changes with proposed
fixes in the issue tracker, and they have not been applied. There are
also a bunch of fixes in the 1.2dev branch which could conceivably be
back-ported. Cleaning those up is more of an immediate cleanup task
than a major effort. It needs to be completed before we can change the
system. If we start changing the system, we will be occupied with that
instead of with fixing bugs and cleaning up the issue tracker.
When the dust settles on the 1.1 branch (I would estimate that
happening about two months from now), then I would seriously recommend
a move to hg, leaving 1.1 on svn or just importing its history.
Although we are "only adding 2 or 3 committers," that is still at
least a 100% increase, and the committers will likely be working on
unrelated tasks most of the time, with occasional bouts of
collaboration or specific bug fixes.
If we have a system which allows them to keep separate branches for
specific new features and leave the 1.2 branch to bug fixes, then we
will no longer have the problem we have right now, which is that some
bugs are fixed in 1.2dev that should have been fixed in 1.1, but
weren't back-ported due to architectural changes that change the
nature of the bug fix. When a new feature is baked enough to merge in,
we can do that without having worried about keeping up with bug fixes
to the old version the whole time. In addition, I believe hg's patch
system is easier to use than svn's, and if we keep our local repos on
bitbucket as well, it will be easier to browse changes made by another
developer and determine whether a pull would be appropriate.
Until then, we really need to focus on cleaning up the existing issues
to make any future transitions easier, and to push out the first
"community release" which should contain the fixes we are making right
now.
And for those of you who haven't tried hg or git, I really think you
should at least read a couple of pages of tutorials for one or the
other. At least do due diligence on it. I used svn for a long time,
but switched because of issues very similar to the ones we are having
now. DVCSes solve problems you didn't even know you had.
Doug Philips
> I think that this discussion has moved from the important topic.
> I don't think it is important right now which VCS we keep using (it is just a tool),
> the important thing right now, is how pyglet is going to keep alive
> (maintenance, bug fixing, improvements, port to python 3, etc).
I agree that the VCS is a secondary decision but I also agree that
once we've read the charts and decided to set sail, the VCS used will
have an affect on how/if folks participate. I feel we can afford to
cruise on SVN for now since there is resistance to changing it right
now.
> I agree we Tristam, we must start by merging back maintenance branch with trunk.
I've just started using pyglet(1) and was lured in to its elegance by
Steve Johnson's "Game Development With Python and Pyglet" talk at
pyohio a few weeks ago.(2)
I don't yet even know what the outstanding bugs are, as I'm still
getting my head around how little it takes to do some awesome
things... Which leads me to the point of this reply. I'm having a bit
of trouble constructing a google search for snippets and bits of
user-shared pyglet code. Then I said: "Wait! Why isn't there a place
on the pyglet site for sharing code (kind of like CPAN or pypi)?"
I don't know that it matters where the code itself is, maybe it's good
enough to have a wiki page or three which are just links to bitbucket
or git hub or whatever.
I'm also wondering about the release testing process. I use a Mac (OS
X Leopard) at home and a <shudder>Dell running Windows XP</shudder> at
work. The former is only one while being used and the latter is behind
a firewall, so I can't offer them as buildbot slaves, but I would be
willing to put release candidates through their paces and report
bugs/issues.
Thanks for listening,
-Doug
(1) - I'm using a lot of the font/text features because I'm using this
for my day-job, not (yet) for personal/game apps. :)
(2) - http://www.pyohio.org/Talks#talk18
Adam Biltcliffe
I haven't seen a lot of talk yet about how pyglet development might
continue outside of technical suggestions for managing code, which
seems slightly premature. First off, I may have read it differently
from everyone else here, but Alex's email that started this thread
seemed to say to me, pretty clearly, "I am offering to give anyone who
wants it access to the pyglet repository so that you can help fix up
existing issues", and it feels as though it might be a bit premature
to assume that that means public carte blanche for the pyglet
community (whoever that consists of) to do whatever they like. Pyglet
is Alex and Richard's baby, and I think we should respect their wishes
(whatever they are, and I'd love to know more precisely!) about what
should be done with it first and foremost.
That said, Alex's comment about hoping an organised anarchy might come
together to carry on pyglet development does seem to imply that he's
hoping that some of the responsibilities might be taken out of his
hands. If that's so, I see that there are two different issues we
should be discussing here:
1) How do we reach an agreement on the vision for pyglet, and more
specifically, decide whether a given feature should be part of it or
not?
2) How do we ensure that no-one commits buggy code to pyglet?
Those are two pretty different issues, and I'm worried that the idea
of "forming a core team" might be conflating the two of them. A lot of
people have a vested interest in pyglet and would want input into the
first issue, whereas the responsibility of reviewing commits is a more
mundane chore that a community-spirited volunteer could probably take
on without upsetting anyone else.
As far as I see it, options for the first one are: a) Alex and Richard
can keep it, if they want it; b) some other person or group is given
the responsibility somehow; c) all the decisions are made by some
democratic process or by lengthy mailing-list arguments. Options for
the second one seem to be a) someone or some group of people review
all changes; b) we cross our fingers and hope.
If we can get any kind of idea about the answers to those questions, I
figure then (and only then) is it sensible to start talking about
specifics like version-control systems.
Adam
Greg Ewing
> 1) if you give everybody commit rights, chaos ensues.
> 2) if you limit commit access to a small number of people, the whole
> burden of reviewing/applying patches falls onto their shoulders.
>
> A DVCS is actually better suited to distribute the workload of moving
> a project forward
I don't see how a DVCS helps with this issue. Either way
you still have the problem of merging everyone's changes
into a single official version, and you have to decide
how many people get a say in what goes into that version.
That's not to say a DVCS wouldn't be helpful in other
ways, but I can't see it magically solving this particular
problem.
--
Greg
Doug Philips
> That's not to say a DVCS wouldn't be helpful in other
> ways, but I can't see it magically solving this particular
> problem.
It is a matter of how do the outsiders-with-patches-to-be-considered
manage their changes?
With a DVCS they use the exact same tools as those in the inner sanctum.
With a DVCS they can cooperate amongst themselves, sharing and
improving patches until they're worthy.
At some point a difference in quantity makes a difference in quality,
and this is one of these kinds of points.
But, again, I agree that the immediate goals are to sort out and work
through the issues and patches that already exist.
-Doug
Tartley
On Aug 14, 1:11 pm, Ben Smith <benjamin.coder.sm...@gmail.com> wrote:
> ..
> take care of all of the important open issues and get a release out
> without a scope change. While that's going on, we can easily discuss
> longer-term choices
I think this idea of an initial minimal release tackling known, open
issues is something we can all agree on.
The question of whether (and when) to switch to a DVCS seems to be one
that people differ on.
I wouldn't normally suggest a poll, but in this case I think that the
pros and cons of each case are already clear to everyone, and
whichever decision we make will work just fine. Therefore it's more
important to make the decision in a way that keeps the most people
happy and engaged, then we can move on.
Does a poll seem productive? Or is more chat required to assess the
merits of using or not-using a DVCS?
Thanks all!
Tristam MacDonald
Ben Smith
only for when. I think that doing this migration will be simpler when
we have fewer disparities between trunk, maintenance, and the issue
tracker. This allows a simpler path to making a public release before
time is taken to make the transition.
I propose we identify the issues that we want fixed right away from
the open issues list and from the fixes in 1.2dev and apply them to
1.1 maintenance to create a 1.1.4 release. 1.2 sounds like it needs a
good amount of testing, and that'll take some time. It seems to me
like that would be an ideal time to migrate, as important issues will
be addressed for general consumption.
Yes, I'm volunteering. And yes, I can be convinced to look at it
other ways.
-b
On Aug 16, 7:42 am, Tristam MacDonald <swiftco...@gmail.com> wrote:
Martin O'Leary
> I wouldn't normally suggest a poll, but in this case I think that the
> pros and cons of each case are already clear to everyone, and
> whichever decision we make will work just fine. Therefore it's more
> important to make the decision in a way that keeps the most people
> happy and engaged, then we can move on.
>
> Does a poll seem productive? Or is more chat required to assess the
> merits of using or not-using a DVCS?
I think there's an issue here in that the project doesn't have a
decision-making process. There was a fairly effective one in place
(Alex makes decisions), but that's changed now to an extent that I
think is unclear. I really would appreciate some clarification from
Alex about how much control over the project he is handing over to
"the community". As Adam pointed out a few posts back in this thread,
people have been jumping the gun on this, assuming that an offer of
commit access to the repository is the same as an offer of complete
control over the project.
For my part, I don't think mailing list polls are a good way to make
project decisions, be they logistical ones such as this, or the design
and technical decisions which are going to have to be made down the
road. Pyglet has benefited thus far from a strong individual vision of
how things should be done. I'd hate to see that lost in any future
structure, and I have fairly strong concerns about the ability of
mailing list democracy to emulate it.
On a more concrete not, my objections to a switch to a DVCS are fairly
mild - I'm certainly willing to compromise with those who hold much
stronger views in the other direction. However, I am strongly against
the idea that we should make this change without the decision to do so
happening in an organised manner. Let's work out how decisions are
going to be made before we start making any.
Martin
Richard Thomas
adopting a development team of unknown size I am happy. There is
plenty of consensus on getting open issues fixed and creating a stable
trunk in this and other threads so that sounds good too.
A decision making process would be nice. We could easily hold such
votes in a invitation only group managed by all the committers.
Preceding vote discussions with a "Vote:" prefix and maintaining a
policy of not posting arguments or points of view in excess of "in
favor" or "not in favor" in such discussions would make the process
quite clean. That's far from complete. There are additional things
needed, like time limits and a consensus on who posts that the vote
finished and whatnot. But the process would be accessible and
transparent and those sound like the most important details.
Just a thought anyway. I would also like some input from Alex on
whether or not he does wish to pass control of the project down to a
group of volunteers.
Richard
On Aug 16, 4:41 pm, "Martin O'Leary" <m.e.w.ole...@gmail.com> wrote:
> 2009/8/16 Tartley <tart...@tartley.com>:
Martin O'Leary
> A decision making process would be nice. We could easily hold such
> votes in a invitation only group managed by all the committers.
> Preceding vote discussions with a "Vote:" prefix and maintaining a
> policy of not posting arguments or points of view in excess of "in
> favor" or "not in favor" in such discussions would make the process
> quite clean. That's far from complete. There are additional things
> needed, like time limits and a consensus on who posts that the vote
> finished and whatnot. But the process would be accessible and
> transparent and those sound like the most important details.
I'm slightly concerned that you're making a jump here from
"decision-making process" to "votes". Democracy is one option for how
the project should be run, but I'm not convinced it's the best one.
Martin
Richard Thomas
the project, like Python does, which is what we have until Alex tells
us how he wants it run. We could limit the democratic process to a
selected body (selected how I don't know). It sounded to me like the
cleanest solution if Alex isn't going to be very involved. Just trying
to get discussion going about something other that source control...
:-)
Richard.
On Aug 16, 5:13 pm, "Martin O'Leary" <m.e.w.ole...@gmail.com> wrote:
> 2009/8/16 Richard Thomas <chards...@gmail.com>:
Bruce Smith
Seriously, I think when a controversy remains, it is worth taking the trouble to continue discussing it until a near-consensus arises. This can happen because almost everyone gets convinced, or because some people voluntarily defer to others who they respect or who are doing more of the work, or because they agree to put something off for now because it's not worth continuing to discuss it right now. This informally allows the community to have more influential members, without requiring a formalized "insider group" that alienates some people. Anyone who "loses an argument" is always allowed to keep arguing if it's important enough to them or if things change. Whereas a vote would artificially cut off discussion. (And besides, the decision about when to hold the vote, and what exactly to vote on, would have to be made somehow....)
That said, I agree with others who are eager for clarification from Alex (and/or Richard) about how much and what kind of influence he hopes or expects to continue having. (And personally, I hope it's as much as possible.)
- Bruce
A decision making process would be nice. We could easily hold such
votes in a invitation only group managed by all the committers....
Tartley
> Democracy is one option for how
> the project should be run, but I'm not convinced it's the best one.
agree it's not usually a great way to decide. :-)
Richard Thomas
discussing the library anything that doesn't garner a very wide
majority of the support might well be a bad idea. Anyway, I prefer to
have a problem before solving it.
Richard.
On Aug 16, 6:28 pm, Bruce Smith <ores...@gmail.com> wrote:
> I vote against making any use of "formal" voting. :-)
>
> Seriously, I think when a controversy remains, it is worth taking the
> trouble to continue discussing it until a near-consensus arises. This can
> happen because almost everyone gets convinced, or because some people
> voluntarily defer to others who they respect or who are doing more of the
> work, or because they agree to put something off for now because it's not
> worth continuing to discuss it right now. This informally allows the
> community to have more influential members, without requiring a formalized
> "insider group" that alienates some people. Anyone who "loses an argument"
> is always allowed to keep arguing if it's important enough to them or if
> things change. Whereas a vote would artificially cut off discussion. (And
> besides, the decision about when to hold the vote, and what exactly to vote
> on, would have to be made somehow....)
>
> That said, I agree with others who are eager for clarification from Alex
> (and/or Richard) about how much and what kind of influence he hopes or
> expects to continue having. (And personally, I hope it's as much as
> possible.)
>
> - Bruce
>
Bruce Smith
....
I propose we identify the issues that we want fixed right away from
the open issues list and from the fixes in 1.2dev and apply them to
1.1 maintenance to create a 1.1.4 release. 1.2 sounds like it needs a
good amount of testing, and that'll take some time. It seems to me
like that would be an ideal time to migrate, as important issues will
be addressed for general consumption.
Yes, I'm volunteering. And yes, I can be convinced to look at it
other ways.
That sounds pretty good to me, if it's not too much work to migrate all the bugfixes. I would point out a few things:
* PyWeek participants are an important part of the community of Pyglet users, and due to PyWeek rules, we might want to wait until after it's over (September 6th) before making any release, or we'd risk disqualifying Pyglet for use in the current PyWeek. (Or it could be that a pure-bugfix release would be ok... Richard? The rules require use of libraries that were available and fully documented at the start of August, but a submission must still work when used with the "latest version" of those libraries -- so incompatible changes are certainly a problem.)
(At least one of the bugs that 1.1.4 would fix (timer crashes) is one that caused trouble for quite a few PyWeek games last time, so it would be really nice if the rules do permit releasing a 1.1.4 in time to be used for this PyWeek... but taken strictly, I think they'd require judging the entries using 1.1.3 even if 1.1.4 was out, unless Richard can be persuaded to do something about that.)
* What 1.2 needs is more than just testing -- some documentation (at least listing new undocumented APIs), and dealing with at least one old audio feature that is no longer supported, and (perhaps, not sure) upgrading some existing documentation and example code to work with it. (At least some code in experimental has been broken by the changes; I don't know if anything else has but it seems quite possible.) And in the community, a decision about whether to split audio into a separate project so that each user can choose whether the old or new version is better for them, independently of the pyglet 1.1 vs 1.2 choice; and if yes, a bunch more work to do that. It seems to me that the people doing that work should have the main say about which VCS/DVCS would best facilitate it.
* It would be possible to have a "stable 1.1.4 release" and an "unstable 1.2.0 release" at the same time, or almost the same time. Then some of the wider community of users would be helping with the testing of 1.2. So a possible timeline would be to make both those releases from svn, then (if the decision is made to do so) switch to Hg, then improve 1.2 (and its documentation and examples) until it's "stable" and release it as 1.2.1.
- Bruce
Doug Philips
> Very fair - even though it was me who mentioned the idea of a vote, I
> agree it's not usually a great way to decide. :-)
I'd rather not see a vote. Unity/focus of vision is hard enough as it is.
I'm not sure about endless discussion aspects. For new
directions/features it seems not too bad, maybe.
Since it seems we've deferred changing version control systems, what's
the next step for moving forward on bug fixes?
I'm particular keen to have a testing/release-candidate/validation
process that is separate from discussions about new features and the
next big direction(s).
FWIW last night I ran through a bunch of the self-tests (if that is
the right term), which were the docs/test.py program.
I haven't a clue how to automate them since they're of the form "did
the right thing happen?"; I'm resigned to spending an hour(ish)
running through the test suite for a RC. Annoying, but I think it
should be done, and I'll volunteer to do it on Mac OS X Leopard and
Windows XP Home Edition(1).
Lurker at the threshold,
--Doug
(1) - Cringe, I know. It's an little Acer Netbook; I have it so I can
verify side projects work under XP without using my work laptop which
would risk "Imperial entanglements." :)
Bruce Smith
- Bruce
Martin O'Leary
> * PyWeek participants are an important part of the community of Pyglet
> users, and due to PyWeek rules, we might want to wait until after it's over
> (September 6th) before making any release, or we'd risk disqualifying Pyglet
> for use in the current PyWeek. (Or it could be that a pure-bugfix release
> would be ok... Richard? The rules require use of libraries that were
> available and fully documented at the start of August, but a submission must
> still work when used with the "latest version" of those libraries -- so
> incompatible changes are certainly a problem.)
>
previous Pyweeks after the library deadline. I don't think anyone
would have any problems with a Pyglet 1.1.4 release being used,
assuming such a release happens before Pyweek itself.
> * It would be possible to have a "stable 1.1.4 release" and an "unstable
> 1.2.0 release" at the same time, or almost the same time. Then some of the
> wider community of users would be helping with the testing of 1.2. So a
> possible timeline would be to make both those releases from svn, then (if
> the decision is made to do so) switch to Hg, then improve 1.2 (and its
> documentation and examples) until it's "stable" and release it as 1.2.1.
I think the model used previously of successive alpha and beta
releases worked very well. We could have 1.2alpha1, 1.2alpha2, etc,
until we're sure that the API is fixed, then 1.2beta1, 1.2beta2, etc,
until it's (relatively) bug-free, then a full 1.2 release. This could
easily sit beside 1.1.4, and indeed 1.1.5 if such a thing turns out to
be necessary. Hopefully by then 1.2 should be stable enough that the
1.1 branch can be left behind.
A change in version control systems could take place at any point in
the above, really, if it's decided that one is necessary. Obviously it
would be helpful if there was a consensus among developers about what
was happening, but that sits hand-in-hand with what I've said
previously about decision-making structures. The important thing in my
view is clarity about what decisions have been made, and unity in
implementing decisions once they have been.
Martin
Ben Smith
to use a bugfixed pyglet, I have even *more* motivation heh.
-b
On Aug 16, 11:20 am, "Martin O'Leary" <m.e.w.ole...@gmail.com> wrote:
> 2009/8/16 Bruce Smith <ores...@gmail.com>:> * PyWeek participants are an important part of the community of Pyglet
Bruce Smith
Pure bugfix releases of libraries have been allowed (welcomed!) in
previous Pyweeks after the library deadline. I don't think anyone
would have any problems with a Pyglet 1.1.4 release being used,
assuming such a release happens before Pyweek itself.
That's good news.
> * It would be possible to have a "stable 1.1.4 release" and an "unstable
> 1.2.0 release" at ...almost the same time....
I think the model used previously of successive alpha and beta
releases worked very well. We could have 1.2alpha1, 1.2alpha2, etc,
until we're sure that the API is fixed, then 1.2beta1, 1.2beta2, etc,
until it's (relatively) bug-free, then a full 1.2 release. This could
easily sit beside 1.1.4, and indeed 1.1.5 if such a thing turns out to
be necessary. Hopefully by then 1.2 should be stable enough that the
1.1 branch can be left behind.
That all makes sense to me.
A change in version control systems could take place at any point in
the above, really, if it's decided that one is necessary. Obviously it
would be helpful if there was a consensus among developers about what
was happening, but that sits hand-in-hand with what I've said
previously about decision-making structures. The important thing in my
view is clarity about what decisions have been made, and unity in
implementing decisions once they have been.
For non-irreversible decisions, letting an apparent consensus arise, and then saying something like "ok, i'll assume we'll do X unless anyone objects in the near future (e.g. 2 days)", seems best to me (given a willingness to reconsider, and toleration for individual differences); for irreversible decisions, we can hope that this same sort of process can work if there is no controversy (though it would go through more stages of certainty and take longer), and if that fails we can deal with it at the time, e.g. by begging Alex to weigh in.
I think it will become clear who's doing the work and/or keeping good track of things, and that this will be mostly a handful of people, so it's not too much of a burden to wait and see what all those people think before being reasonably certain that "a decision has been made".
When there is consensus (either on a decision, or on a set of issues and the need for a decision), it might also be useful to make a wiki page summarizing it (and to have one page for the near-future roadmap in general), though the actual discussion probably still works best within this group.
(All IMHO.)
- Bruce
iisdev
> merits of using or not-using a DVCS?
terms. Not everyone on this list has the same experience (or exposure)
as many of you do.
I would like to see some of the current issues addressed before doing
anything really disruptive. Pyglet's focus was really what attracted
me to it from pygame.