Pyglet 1.2 alpha1 and future

["Juan J. Martínez"]

Hello,

pyglet 1.2 alpha1 was released about one year ago. Since then there have
been a few commits and there are 160 open issues. There's also a roadmap
for 1.2:

https://code.google.com/p/pyglet/wiki/RoadMap12

(not updated in a while)

I'm quite happy with Pyglet 1.2 alpha1 and it mostly works as I expect.
I have some local patches I submitted as bug report, but it's more about
small things than actual problems. I've found some TODOs but nothing
that I really need, so it's not a big deal.

That said, I'm sending this mail to see if anybody involved in the
project can share his insights about pyglet 1.2 (I've seen 1.2 beta1 in
the changelog) and the future of pyglet in general.

Thanks in advance!

Kind regards,

Juan

[Nathan]

I know that I've been working on a big update to AVbin (version 11), which will require some significant patches to Pyglet.

I also know that the latest code from the repository has quite a few fixes that happened after alpha1, which is why I always use the repository head for my projects at the moment.

Other than that, it's been pretty dang quiet around hear release-wise.  I'm not a committer on the pyglet repo, and I'm not directly involved in the release process per se.

~ Nathan

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users...@googlegroups.com.
To post to this group, send email to pyglet...@googlegroups.com.
Visit this group at http://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Adam Bark]

On 15/07/13 21:19, Nathan wrote:

I know that I've been working on a big update to AVbin (version 11), which will require some significant patches to Pyglet.

I also know that the latest code from the repository has quite a few fixes that happened after alpha1, which is why I always use the repository head for my projects at the moment.

Other than that, it's been pretty dang quiet around hear release-wise.  I'm not a committer on the pyglet repo, and I'm not directly involved in the release process per se.

~ Nathan

On Mon, Jul 15, 2013 at 6:31 AM, "Juan J. Martínez" <j...@usebox.net> wrote:

Hello,

pyglet 1.2 alpha1 was released about one year ago. Since then there have
been a few commits and there are 160 open issues. There's also a roadmap
for 1.2:

https://code.google.com/p/pyglet/wiki/RoadMap12

(not updated in a while)

I'm quite happy with Pyglet 1.2 alpha1 and it mostly works as I expect.
I have some local patches I submitted as bug report, but it's more about
small things than actual problems. I've found some TODOs but nothing
that I really need, so it's not a big deal.

That said, I'm sending this mail to see if anybody involved in the
project can share his insights about pyglet 1.2 (I've seen 1.2 beta1 in
the changelog) and the future of pyglet in general.

Thanks in advance!

Kind regards,

Juan

You could try asking Richard Jones for commit access Nathan, he's probably around the most of the people with that ability. I have commit rights if you want help with getting patches into trunk, I suppose I can make new tags as well if nobody has any objections but I don't have access to the web server. Richard sorted out alpha1 I believe.

Adam.
P.S. I'll be away for about 3 weeks from next week.

[Richard Jones]

I'd love to see a new release made, but I'm just not in touch with the
issues that would prevent it (if there *are* any) on the various
platforms. I think for the pyglet project to move forward we really
need a platform champion on each of OSX, Windows and Linux. Someone
who can reasonably confidently indicate that the code is ready to go
on their platform, or indicate what the issues are. Just cutting a
release based on the current repository code seems a little haphazard
to me :-)

And yes, if there's anyone who would like to contribute but can't
because of commit privs, I'll do what it takes.


Richard

["Juan J. Martínez"]

On 16/07/13 01:11, Richard Jones wrote:
> [...]

>
> And yes, if there's anyone who would like to contribute but can't
> because of commit privs, I'll do what it takes.

I'd like to help!

I can triage Linux bugs (try to reproduce, then confirm or ask for info,
set OpSys, labels, etc accordingly), and I would help with patches if
someone with more experience with pyglet could review non trivial code
before it gets into the repo.

I think if we can get some love to the bug tracker, at the very least we
can release alpha2 (alpha1 with fixes) in some weeks.

Anyone wants to help with Windows and Mac?

Richard I'm sending you privately my Google Code account. Thanks!

Regards,

Juan

--
jjm's home: http://www.usebox.net/jjm/
blackshell: http://blackshell.usebox.net/

[chup]

I've also been wondering quite a bit about this lately -thanks for taking the leap Juan!

I'd like to help, although I'm primarily also a Linux man. Perhaps I could contribute in some other capacity?

Getting a nice bug trackers seem like a good start -did you have something specific in mind?

[Nathan]

I'll volunteer to be the platform champion for OS X for the time being.  I focus all my development on OS X first, which means I always run into OS X specific pyglet bugs before I see anything else.

If I can make a big push and finish up AVbin 11, I will be in a better position to actually deal with pyglet-specific issues a bit more.  (I never have tons of free time, so that's not necessarily saying much...)  :-)

~ Nathan

["Juan J. Martínez"]

On 16/07/13 19:13, Nathan wrote:
> I'll volunteer to be the platform champion for OS X for the time being.
> I focus all my development on OS X first, which means I always run into
> OS X specific pyglet bugs before I see anything else.
>
> If I can make a big push and finish up AVbin 11, I will be in a better
> position to actually deal with pyglet-specific issues a bit more. (I
> never have tons of free time, so that's not necessarily saying much...) :-)

Let me know if I can help testing AVbin 11 in Linux (I'm currently
running 11 aplpha4).

[Nathan]

You definitely can, once I get past this last hurdle.  I've run into some design flaws that necessitate an API change to fix, so I'm trying to make a better design, implement it, and update pyglet to be able to use either the old API or the new API.  All at the same time.  It's hard to keep track of.  If you are interested in hearing more about it (or helping!), lets start a new email thread so we don't overly hijack this one.  ;-)

~ Nathan

[Richard Jones]

On 16 July 2013 16:18, "Juan J. Martínez" <j...@usebox.net> wrote:
> On 16/07/13 01:11, Richard Jones wrote:
>> [...]
>>
>> And yes, if there's anyone who would like to contribute but can't
>> because of commit privs, I'll do what it takes.
>
> I'd like to help!
>
> I can triage Linux bugs (try to reproduce, then confirm or ask for info,
> set OpSys, labels, etc accordingly), and I would help with patches if
> someone with more experience with pyglet could review non trivial code
> before it gets into the repo.

Welcome aboard! I'd say that for those issues that need review you
could post something to the list. There is some testing information in
the project wiki too.

As I said privately, there's no formalised processes with this
project, mostly because there's no project lead.


Richard

["Juan J. Martínez"]

On 16/07/13 16:22, chup wrote:
> I've also been wondering quite a bit about this lately -thanks for
> taking the leap Juan!
>
> I'd like to help, although I'm primarily also a Linux man. Perhaps I
> could contribute in some other capacity?

There are several distros, different hardware, etc. I think having more
than one person testing one platform can be a good idea.

> Getting a nice bug trackers seem like a good start -did you have
> something specific in mind?

Well, we have this:

- http://www.pyglet.org/contribute.html
- http://code.google.com/p/pyglet/issues/list

It only needs some love, that's all!

["Juan J. Martínez"]

On 16/07/13 19:23, Nathan wrote:
> You definitely can, once I get past this last hurdle. I've run into
> some design flaws that necessitate an API change to fix, so I'm trying
> to make a better design, implement it, and update pyglet to be able to
> use either the old API or the new API. All at the same time. It's hard
> to keep track of. If you are interested in hearing more about it (or
> helping!), lets start a new email thread so we don't overly hijack this
> one. ;-)

Yes, feel free to start a new thread.

You could also update http://avbin.github.io/AVbin/Roadmap.html (hint, hint)

[Petr Viktorin]

On Wed, Jul 17, 2013 at 8:10 AM, "Juan J. Martínez" <j...@usebox.net> wrote:
> On 16/07/13 16:22, chup wrote:
>> I've also been wondering quite a bit about this lately -thanks for
>> taking the leap Juan!
>>
>> I'd like to help, although I'm primarily also a Linux man. Perhaps I
>> could contribute in some other capacity?
>
> There are several distros, different hardware, etc. I think having more
> than one person testing one platform can be a good idea.

Hello,
I'm packaging Pyglet for Fedora, so I'll spend some cycles testing there.

[Oktay Acikalin]

Am Mittwoch, 17. Juli 2013 08:10:15 UTC+2 schrieb Juan J. Martínez:

Well, we have this: 

 - http://www.pyglet.org/contribute.html
 - http://code.google.com/p/pyglet/issues/list

It only needs some love, that's all!

Exactly - including the wiki pages. I'm currently porting my game and framework from pygame to pyglet and it's really funny how far the code of pyglet has evolved if you compare it to the wiki, issue tracker etc..

Regards,

Oktay.

 

["Juan J. Martínez"]

On 17/07/13 00:35, Richard Jones wrote:
> [...]

> As I said privately, there's no formalised processes with this
> project, mostly because there's no project lead.
>

OK, after a quick run through the tickets and the repository:

- Most tickets refer to pyglet 1.1.x
- There are very old tickets
- Several tickets have patches (gold!)

There are 22 listed committers and, although the pace has been slow
after the release of 1.2 alpha1 (1.2 from now on), the project didn't
stop until early this year. That's good!

I know how difficult is getting things going, so here follows my proposal:

It doesn't look like 1.1.x is being maintained, so suggest we keep 1.1.4
as stable but work towards releasing 1.2 alpha2 before checking the
roadmap and start striking things out for an eventual 1.2 beta1.

To do this, I would go trough the bug list and...

- Ask bug reporters to confirm bugs with 1.2 alpha1 (it is going to be
very painful with very old tickets, so some tickets will be closed as
"deprecated").
- Fix bugs in 1.2 (default branch).
- When we get to a dead end with the bug list, release 1.2 alpha2.
- Make 1.2 easier to install (put docs online too) and encourage users
to try it (for me has been quite stable and joystick support is a big
selling point!).

Please let me know what you think. Specially I'd love comments from any
of the committers.

[Richard Jones]

I think that's a good plan!


Richard

["Juan J. Martínez"]

Hello,

Just reporting!

We're now on 137 open issues (from 160).

We had several dupes (mainly 1.1.4 MSI not working with Python 2.7),
some wiki edit requests [1], errors with pypi/pip that are fixed, small
and trivial fixes, etc. I'm still not done with the tidying/triaging,
but it's looking good!

Life is getting in the way now (I'm in the middle of a move), but I plan
to keep going and hopefully start looking at some of the issues that
include a patch.

I've seen Adam around (I think, Google Code is awful... sometimes is
hard to tell who's who), doing some tickets. That's great because I'll
need help when we get close to an eventual release of 1.2 alpha2 [2].

Regards,

Juan

[1]: http://code.google.com/p/pyglet/wiki/ProjectsUsingPyglet
[2]: https://groups.google.com/d/msg/pyglet-users/kfewNtfF_K8/3IbxIgl5tL8J

[Martin Balmaceda]

This is awesome! I'm so glad pyglet is moving forward.
Thanks for your contribution.

[Adam Bark]

Yeah I've had a look at a few issues. I'm on holiday at the minute so I won't be doing anything for a couple more weeks though. Cheers Juan.
Adam.

["Juan J. Martínez"]

Hello,

It's been long time since my last report!

I started working on pyglet about 5 months ago and although some
progress has been made (we're below the 130 issues mark, wow!), there's
a lot of work to do.

I'm happy with the idea of more people using hg tip (the repo code) as
it is where the fixes go and we're getting rid of the most
frequent/annoying issues in 1.2 alpha1.

Now that I've been working with the source code for some time I'm not as
optimistic as I was 5 months ago regarding future releases :) but I'm
still here with you!

The main reasons for my despair are:

- Documentation: the doc generation is kind of broken, docs re:
migrating from pyglet 1.1.x are missing, the programming guide is not
100% in sync with 1.2 -- this is BAD

- Missing code: there are some TODOs in the code, some of them are out
of reach for me and my current skills (I can read and apply patches from
contributors though)

- Obscure bugs: there are some bugs related to platform code (ie. audio
drivers problems in win, linux or mac) that I can't investigate or even
reproduce

We can improve the situation and, even pyglet 1.2 is not perfect (yet),
I still think it's the way forward and eventually we will get there.

I don't know when we will be ready for a new release, but I have to
tackle the doc issues before we can think of getting anywhere close to a
beta release.

Any help will be appreciated!

Regards,

Juan

[Txema Vicente]

I am willing to solve any problem or improve the generation of the documentation using sphinx.

The first thing would be to merge the changes at the "doc" folder with my repo, it is better.
https://code.google.com/r/txema-pyglet-doc

Do I send a patch, or someone with commit rights can do this?

["Juan J. Martínez"]

On 02/12/13 15:44, Txema Vicente wrote:
> I am willing to solve any problem or improve the generation of the
> documentation using sphinx.
>

> The first thing would be to mergethe changes at the "doc" folder with my

> repo, it is better.
> https://code.google.com/r/txema-pyglet-doc
>
> Do I send a patch, or someone with commit rights can do this?

I will review (to some extent) and merge your patch. Given the time :)

Regards,

Juan

[Adam Bark]

Would you mind making an issue on googlecode with your patchset so that it can be reviewed and discussed?

--

["Juan J. Martínez"]

On 03/12/13 09:58, Adam Bark wrote:
> Would you mind making an issue on googlecode with your patchset so that
> it can be reviewed and discussed?
>

Yes, I asked him to do that but I didn't reply to the list my mistake.

Sorry, my bad.

Regards,

Juan

[Jorge Cardoso Leitão]

Hi all

It seems to me that Juan has too much work in hands. I think it is of upmost importance to improve the documentation

on API documentation and how to contribute:

1. Unless there are people using pyglet, there aren't people contributing to pyglet, which means that the effort per person with project complexity increases.

2. Unless there are good standards on how to contribute, the project complexity increases too fast with project size to be bearable in long run.

I'll give you one example of what I'm referring: in this commit, I didn't contributed because there is still no clear instructions of what I should do to contribute.

Furthermore, a patch was added to the trunk without API documentation: the public API of batch changed, and that was not documented (I'm not blaming anyone; it is what it is).

What I mean with "API not documented" is that this function is now part of pyglet's API: if anyone wants to re-order groups within a Batch,

he can now use that functionality. Thus, in the Programming Guide (what I call "API docs"), this must be included as part of the code.

My suggestion is that we don't commit to the trunk (and close the issue) unless the full package is complete:

code+testing+references+API docs. This makes adding new functionalities much more time consuming, but makes Pyglet's complexity to grow much slower with project size than the current grow.

- Regarding the missing code, I think the approach here is to define priorities: what is release blocker? what is important? what is minor?

These decisions have to come from experience contributors that know the project as a whole and can make these judge calls. It is the whole point of ticket triaging. If in doubt, discuss in the mailing list. If the issue is not ready to be solved because it is too difficult, let it be there. In my perspective,

is far better to have an open issue with a patch waiting to be documented than a code full of patches with out-of-sync documentation.

The reason is that while it is a patch within a ticket, it has a very clear context (to address the ticket). When it is in the code, the context it belongs has to be fully documented, both on a lower level (References) and higher level (API docs).

- Regarding the obscure code, it is hard, especially if we don't have people with skills to tackle it. The viable (and valuable) option in some circumstances is to

consider dropping support. This again is a way of decreasing the project complexity, in this case by removing components that cannot be fixed, lack documentation or the effort to maintain is higher than the value they provide to the project.

- Finally, don't rush. If you are not sure it is ready, it is because it is not. If we release 1.2 without proper documented API, Pyglet loses credibility

and makes it more difficult to attract more users and contributors.

In the end, this boils down to make Pyglet community friendly so it can attract people to help: more API documentation means more users; more documentation on how to contribute means more users wanting to contribute, which means less work for us all, specially for Juan (or, at least, he can spend his time on matters that require senior contributors).

I can help on any of those.

Regards,

Jorge

["Juan J. Martínez"]

Wow, your mail is too long to get into details because we may end
bikeshedding, but I'd like to point a couple of things. Replying in line.

On 03/12/13 14:54, Jorge Cardoso Leit�o wrote:
> [...]

> 1. Unless there are people using pyglet, there aren't people
> contributing to pyglet, which means that the effort per person with
> project complexity increases.
> 2. Unless there are good standards on how to contribute, the project
> complexity increases too fast with project size to be bearable in long run.
>
> I'll give you one example of what I'm referring: in this commit

> <https://code.google.com/p/pyglet/source/detail?r=88a2e9928d5b>, I

> didn't contributed because there is still no clear instructions of what
> I should do to contribute.

I agree with you that the docs are important, but I don't think it's
that difficult to contribute to pyglet. In fact I've tried to not let
new patches unattended for too long to keep newcomers interested (you're
one of them, btw!).

I started to work on the tickets in July and before that the issue
tracker was kind of abandoned. That's bad and makes pyglet status look
worse than it is. Still lot of work to be done on that front.

> Furthermore, a patch was added to the trunk without API documentation:
> the public API of batch changed, and that was not documented (I'm not
> blaming anyone; it is what it is).
> What I mean with "API not documented" is that this function is now part
> of pyglet's API: if anyone wants to re-order groups within a Batch,
> he can now use that functionality. Thus, in the Programming Guide (what

> I call "API docs"), this must be included *as part of the code.*

I don't agree or (perhaps) I'm not sure if I understand you because IMHO
`it is` documented.

Pyglet has two main documentation areas:

- the programming guide
- docs extracted from the code (API docs)

When the problems generating the documentation are sorted out, that new
method that exposes an internal feature of the Batch class will be
documented.

> My suggestion is that we don't commit to the trunk (and close the issue)
> unless the full package is complete:
> code+testing+references+API docs. This makes adding new functionalities
> much more time consuming, but makes Pyglet's complexity to grow much
> slower with project size than the current grow.

It's a good idea, until you check how pyglet tests work :)

I still think we call API docs a different thing, but I see your point.

> [...]

> - Finally, don't rush. If you are not sure it is ready, it is because it
> is not. If we release 1.2 without proper documented API, Pyglet loses
> credibility
> and makes it more difficult to attract more users and contributors.

I'd be happy if we could get things moving. If you think they already
are, then... success! :)

Look, pyglet 1.2 is perfectly usable for me. It was before I started
contributing, and after putting some hours into the projects... it's a
little bit better.

As I said, any help is welcome. I'd like to get the doc generation
working, write the missing bits when needed and keep working on the bug
tracker until it shines. At some point I expect most pyglet users will
be using 1.2 -- when we are happy with it we can release a beta.

As Alex told me: do whatever tickles your fancy (not textual words, but
I like the idea).

Kind regards,

Juan

[Oktay Acikalin]

Hi guys,

I'm following you, Jorge, and especially Juan from the "beginning" now and I'm really happy about your motivation and your efforts!

Talking about what a contribution requires... I'd vote for defining a package (feature branch with code, unit tests and docs) which would then be reviewed and tested by some defined user group and optional volunteers. This is what we do in our company and it works great. I could also imagine using Jira and FeCru or similar tools. What do you think about such tools anyway?

If you define such process I would be happy to help - either by shaping and/or executing and "maintaining" it.

Also I think it's important that you keep accepting merge-incomplete patches and then shape them to be mergeable - this keeps the barrier low for contributors.

Regards,

Oktay.

 

2013/12/3 "Juan J. Martínez" <j...@usebox.net>

Wow, your mail is too long to get into details because we may end
bikeshedding, but I'd like to point a couple of things. Replying in line.

[Txema Vicente]

Hi.

I cleaned and refactored the "doc" folder, it is uploaded to my repo.

Just replace the folder and it should work. If something is wrong or the organization has to be changed, tell me.

The resulting documentation is here:
http://code.nabla.net/doc/

I wrote a new page about the documentation system. I do not explain myself very well in English, so it needs a correction.
http://code.nabla.net/doc/pyglet/internal/doc_generation.html

I've done a little trick to have the Window attributes documented,  I  replaced "BaseWindow" to "Window" In window/__init__.py.
http://code.nabla.net/doc/pyglet/api/pyglet/window/pyglet.window.Window.html#pyglet.window.Window.invalid

it is easy to do if you are going to publish the documentation.

To fix this issue, I wonder if this could be done:

if not _is_epydoc:
    # We are NOT building documentation
    BaseWindow = Window
    BaseWindow.__name__ = 'Window'
    del Window

I don't know if this would break something when using pyglet.

Regards.

["Juan J. Martínez"]

On 04/12/13 18:29, Txema Vicente wrote:
> [...]

> The resulting documentation is here:
> http://code.nabla.net/doc/

Looks good to me!

> I wrote a new page about the documentation system. I do not explain
> myself very well in English, so it needs a correction.
> http://code.nabla.net/doc/pyglet/internal/doc_generation.html
>

I'll take a look when I have some free time. I want to check your
changes and include them in pyglet's repo if everything's OK.

> [...]

> To fix this issue, I wonder if this could be done:
>
> if not _is_epydoc:
> # We are NOT building documentation
> BaseWindow = Window
> BaseWindow.__name__ = 'Window'
> del Window
>

I don't understand that part. When the docs are being generated we set
_is_epydoc to True, so we can change things for the doc generation.

So it shouldn't be necessary if the the "epydoc ready" part is OK.

Anyway, thanks a lot for your help! As I said I'll get your changes and
hopefully we'll get the doc generation sorted out!

[Txema Vicente]

I don't understand that part. When the docs are being generated we set
_is_epydoc to True, so we can change things for the doc generation.

Let me explain the idea. We want to document the Window class, not BaseWindow.

Now pyglet is doing this:

Define the BaseWindow class.
If _is_epydoc:
      Window = BaseWindow, and delete BaseWindow.
else:
      Import Window from the platform specific module.

But sphinx needs to get the source code for the attribute documentation magic to work, so this fails.

The idea is to do it the other way around, if possible:

Define the Window class.
 if _is_epydoc:
      Nothing to do.
  else:
      BaseWindow = Window, and delete Window.
      Import Window from the platform specific module.

Regards.

[Txema Vicente]

Hi.

Would you mind making an issue on googlecode with your patchset so that it can be reviewed and discussed?

https://code.google.com/p/pyglet/issues/detail?id=688

Regards.

["Juan J. Martínez"]

Thanks a lot Txema!

I've reviewed the changes and the doc generation is looking better now.
There are still some glitches (some attributes in Window class not being
documented properly), but overall is a huge improvement.

For example things like the following were missing before the change:

http://pyglet.org/doc-current/api/graphics/pyglet.graphics.Batch.html

Now the doc generation is useful again. Yes, we have some parts missing
(ie. migrating to 1.2), but we're on track.

Richard granted me access to pyglet.org so now current docs are in
pyglet.org instead of usebox.net:

http://pyglet.org/doc-current/index.html

(old docs for 1.1.x are still in /doc/)

As I said, good stuff!

Kind regards,

["Juan J. Martínez"]

On 07/12/13 20:15, "Juan J. Mart�nez" wrote:
> On 07/12/13 14:40, Txema Vicente wrote:
>>
>> Hi.
>>
>>> Would you mind making an issue on googlecode with your patchset so
>>> that it can be reviewed and discussed?
>>>
>>
>> https://code.google.com/p/pyglet/issues/detail?id=688
>
> Thanks a lot Txema!
>
> I've reviewed the changes and the doc generation is looking better now.
> There are still some glitches (some attributes in Window class not being
> documented properly), but overall is a huge improvement.
>
> For example things like the following were missing before the change:
>
> http://pyglet.org/doc-current/api/graphics/pyglet.graphics.Batch.html

I meant:

http://www.pyglet.org/doc-current/api/pyglet/graphics/pyglet.graphics.Batch.html#pyglet.graphics.Batch

Regards,

[Txema Vicente]

OK, I tested and documentation works as expected.

There are files outside "doc" folder marked as modified,  but I checked all the diffs and they are not changed.

One detail [1]. Now sphinx gives only one warning, that I didn't see because Windows:

WARNING: [autosummary] failed to import 'pyglet.font.win32query':

This is a good example of use of doc/conf.py: we can avoid this by simply adding "win32query" to skip_modules["pyglet.font"]

Thank you, Juan.

Regards.

[1] http://pyglet.org/doc-current/warnings.txt

["Juan J. Martínez"]

On 07/12/13 22:54, Txema Vicente wrote:
> [..]

>
> This is a good example of use of doc/conf.py: we can avoid this by
> simply adding "win32query" to skip_modules["pyglet.font"]

Done!

>
> [1] http://pyglet.org/doc-current/warnings.txt

That file doesn't exist anymore ;)

["Juan J. Martínez"]

Hello,

It's been a very looong time since my last report!

I'm still doing work on pyglet, mainly letting some patches in (from
Claudio, Eric, Risimi, Techno, Anatoly, Txema and others) and keeping
the bug tracker attended.

It will be soon a year since I started contributing to pyglet towards
making 1.2 the new stable. It's harder than I thought, but we're in the
right direction.

I'm going to start tagging issues as "1.2 release blocker", meaning that
when I get them closed, I think there should be a 1.2 release as the new
stable version of pyglet.

You can see current list of blockers:

https://code.google.com/p/pyglet/issues/list?q=label:1.2-release-blocker

When I have some time I'll try to go through the source code trying to
identify things that should be fixed or improved and I'll add them as
small bug reports. Anything that didn't pop out in the last 2 years as a
bug report is probably not a blocker; but still I want to be sure
there's nothing really broken.

As always, any help is very welcome!

Also Nathan will try to release an new version of AVBin (I've been
successfully using 11 alpha 4 for almost a year), and we're trying to
get Debian folks to update AVBin packages to a newer version.

Exciting times ahead :)

After 1.2 is out, perhaps we can plan pyglet's long term future
(maintenance, finish things, migrate to github, etc). Obviously I'm not
going to be here forever, so pyglet will be whatever YOU want.

[Adam Bark]

Thanks Juan,

I think a discussion about the future of pyglet is a very good idea.

Adam.

["Juan J. Martínez"]

Hello,

I haven't worked in anything pyglet related since July, although I keep
an eye on the bugtrack, it is very difficult to me to find time and the
right mood to work in the "1.2 release blockers".

I've been thinking about this and the main reason is because I started
using pyglet to make games and lately I'm actually making games, but not
with pyglet (or python, to be honest).

Basically, when I use pyglet it is much about working in pyglet and less
so about making games; and that spoils the fun a little bit (and fun is
important if you're a hobbyist!).

I still like pyglet and I really think a solid 1.2 release is possible,
but I don't have the skills nor the motivation to do it.

Richard: I may or may not work on pyglet in the future, but perhaps for
security reasons I should have my access privileges revoked.

It's been over a year since my fist commits back in July 2013; I'm happy
to see that I've helped to improve pyglet a little bit ;)

Regards,

Juan

On 31/05/14 17:46, "Juan J. Martínez" wrote:

[claudio canepa]

On Sat, Sep 27, 2014 at 4:59 AM, "Juan J. Martínez" <j...@usebox.net> wrote:

Hello,

I haven't worked in anything pyglet related since July, although I keep
an eye on the bugtrack, it is very difficult to me to find time and the
right mood to work in the "1.2 release blockers".

[...]

 

It's been over a year since my fist commits back in July 2013; I'm happy
to see that I've helped to improve pyglet a little bit ;)

Regards,

Juan

First, let me thank you for all the work you put

   - triaging the issue tracker

   - working with people on issues to help investigating the problems

   - integrating patches

   - taking bug reports, investigating and fixing them

   - care also for this list

Lots of hours and brain invested there, and yes, I think pyglet is noticeable better because of that work.

Thank you.

Second, and that directed to all pyglet users, devs and owners:

I think most of us would concur that 

   - we need a pyglet release

   - the actual codebase is good enough to release

   - not releasing discourages people to contribute to pyglet

We need a pyglet release

-------------------------------------

  - actual code supports the current Mac OS gui Cocoa, last released not

  - actual code supports much better 64 bits OS' architectures

  - people hear about pyglet, goes to pypi, get an old unmantained version, falls on issues fixed in current code base.

Lots of brain cycles and goodwill lost.

We have seen this on this list, the bug tracker, the pyweek forum and the issue tracker for software that depends on pyglet

   - software that depends on pyglet cannot  handle the pyglet dependency in a standard way, because the codebase is not on pypi

The actual code is good enough to release

-------------------------------------------------------------

    - Documentation builds

    - Distribution .tar.gz builds and installs correctly

    - No showstopper issues, ie most common uses don't find crashes or incorrect behavior

 Not releasing discourages people to contribute to pyglet

 ---------------------------------------------------------------------------------

   - Being in perpetual 'theres a release near' discourages anything that is not minor fixes, because  nobody wants to rock the boat near a release.

  - Why put much work if it will never be released ?

  - The sensation that there's something unspoken about the 'non releasing' thing.

There were at least four times when releasing a new version would have  been natural, and it did not happen:

    - after the Phillip Nguyen integration of Cocoa support

    - a previous issue tracker thinning done by Andreas Schiefer, Adam Bark,     Winston W, Anatoly Techtonik and other people, including py3 support

    - After integration of the sphinx based documentation (Txema Vicente, others)

    - Any time from March 2014 to today, ie at an advanced stage of Juan thinning of the issue tracker.

That does not inspire confidence.

So, what can be done now ?

=====================

Please, please, active devs and gatekeepers (Richard ? Alex ?) please talk and decide to make it happen.

After that, all is needed  is someone with the credentials push the buttons to make the release. It is all nearly automated now.

   - package building works

   - documentation building works

   - documentation site is uptodate (or will need refresh with last documentation build, and should not be hard, Juan done that sometimes and it did not mention problems from that side)  

   - upload to pypi is a nonissue 

   - codebase state is reasonable

Sorry for my bad english, cheers all

claudio

 

[Richard Jones]

Thanks, Juan, for everything!

And I agree, Claudio, I should just push a damn release out with the current (good) state of things!! I will look at doing that ASAP.

Does anyone dissent?

     Richard

--

You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users...@googlegroups.com.
To post to this group, send email to pyglet...@googlegroups.com.
Visit this group at http://groups.google.com/group/pyglet-users.

For more options, visit https://groups.google.com/d/optout.

[Leif Theden]

I think that proper python 3 support (six module?) would be great.  In my experiences, the 2to3 conversation process was troublesome on a few systems when I used pyglet.

On Monday, July 15, 2013 7:31:45 AM UTC-5, Juan J. Martínez wrote:

Hello,

pyglet 1.2 alpha1 was released about one year ago. Since then there have
been a few commits and there are 160 open issues. There's also a roadmap
for 1.2:

https://code.google.com/p/pyglet/wiki/RoadMap12

(not updated in a while)

I'm quite happy with Pyglet 1.2 alpha1 and it mostly works as I expect.
I have some local patches I submitted as bug report, but it's more about
small things than actual problems. I've found some TODOs but nothing
that I really need, so it's not a big deal.

That said, I'm sending this mail to see if anybody involved in the
project can share his insights about pyglet 1.2 (I've seen 1.2 beta1 in
the changelog) and the future of pyglet in general.

Thanks in advance!

Kind regards,

Juan