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
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
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/
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
> 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
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
> 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
+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
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.
> 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
> 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
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
> 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
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
> 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
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
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
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
A decision making process would be nice. We could easily hold such
votes in a invitation only group managed by all the committers....
....
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.
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." :)
> * 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
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.
> * 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.
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.