Is it time for a new PyPRP release?

[Christian Walther]

The last stable release of PyPRP, version 1.5.0, was published 8 months ago. A considerable amount of bugfixes and new features has accumulated in SVN since then. In the general public, as suggested by a few recent posts, development of PyPRP is perceived as stagnant, even though there is still regular activity in SVN. There even seem to be worries that the developers might be more and more just working for themselves and not caring about making their achievements available and accessible to everyone.

I have the suspicion that the reason for this situation is simply that nobody feels responsible for preparing a new release.

Do you think that a PyPRP release is due?

Who has prepared PyPRP releases in the past?

Does anyone have any concrete plans for future PyPRP releases?

If there is a consensus that a PyPRP release in the near future would be a good thing, and the previous release managers feel they don't have time or inclination to do it, I hereby volunteer to take on the job of the release manager for this one time. (To clarify, what I see as the duties of the release manager are things like organizing a discussion of what should go into the release and what shouldn't, pestering developers to write documentation, organizing testing, maintaining branches and tags in the repository, ...)

[D'Lanor]

Sounds like a good plan to me.

[Marcello]

One question though: releasing a new PyPRP (which I applaude) is not enough to be able to use new features. The Wiki should be up to date with the new features, methodes, changes, etc. too, to make a new release useful. But... having said that... maybe it is. I'm not in the position to say it is or isn't. If not... it needs attention. If yes.... yeeeeeeeh!!!

[ardent red]

A new release is a good idea. I'd be happy to help clean up the wiki, as Marcello suggested.

[Christian Walther]

Exactly, Marcello. I consider that an integral part of a release. The whole point of a public release is to take the features that have been buried in the repository - entirely publicly available, but still used only by the developers themselves and by the few bold enough to figure out their usage on their own (by trial and error, reading the source, searching random forum posts, or asking the developers) -, make sure that they work, and make the average non-technical Writers aware of them and teach them about their use.

Experience shows that the teaching part doesn't happen without some conscious effort on the part of the developers (or others who are in a position to do it), and it is no coincidence that I include "pester the developers to write documentation" in the duties of the release manager.

[Grogyan]

Yeah, there are numerous fixes in branches, that I think could be merged safely.

I gave up on figuring out what Paradox changed in the material classes for GUI support.

So perhaps small mergers and test them out before merging another branch of fixes?

[Jojon]

Thanks for volunteering,CW. I am sure it's a task anybody is more than happy to delegate. :7

[Christian Walther]

Bump!

Nobody has answered my second question yet (the bits of evidence I have point to Hoikas), and I'm still waiting for a somewhat representative vote from the active developers. Apart from D'Lanor, any opinions from Nadnerb, Paradox, GPNMilano, Lontahv, RTR, Hoikas?

This isn't going to happen without the collaboration of the developers, and I don't want to step on any toes here. To me, the problem (do we agree that there is a problem?) seems to be one of leaderlessness. I am willing to try to solve it by (temporarily) taking the lead, but not against the will of those who will have to do the majority of the work.

[Jojon]

I don't believe a lack of leadership is the-, or even *a* problem. More likely the snag connects to a degree with your third question. I'd wager a guess there is a measure of disattachement with pyprp in its current incarnation, since, with the all-sparkling new libplasma-based one on the horizon, its days are numbered -- biggest problem here is that they are numbered X, rather than N. There is, afaik, some general uncertainty related to the upcoming open source release -- why make decisions and work on stuff that you may well have to throw away a month later.

Regardless of Cyan's part and the answers their release will give to the developers, a new release of the current pyprp, will be a stop-gap thing -- even if a clear course has been set, without waiting for Cyan, I'm supposing it will mean changes to how we mere users do stuff (will alcscript remain, even?) and therefore, again, there may be a feeling of wasted effort. I don't know what has been done with pyprp2 -- I am assuming there is a separate repository for it...

Ok, I'm getting less and less coherentbut I think you get the gist of it, bye.. :P

[Christian Walther]

That's an interesting perspective, but it doesn't quite match my impression. Have you followed the development activity in SVN? Or even just the recent clashes between boblishman and GPNMilano? SVN activity is certainly not overwhelming, and obviously declining, but I do still see steady activity, well above the level of some of my own projects that I don't consider abandoned at all. And, more importantly, I see accumulation of work.

My third question that you're referring to was not meant as "Does anyone have any plans for PyPRP, or is it completely abandoned?", but rather as "Does anyone have any plans for coordinated public releases, or is everyone just working away on it according to their own agenda?"

The (subjective and so far unfounded) impression I get is that a lot of cool things are being done, or have been done, but nobody uses them, because they're only being driven to the point of being useful to an intrepid few. While I can completely relate to that with my programmer hat on, it does seem a bit of a shame from the point of view of the users. I suspect that there could be a lot of people who think that if anything was wasted effort, it was developing all that in the first place, when a comparatively small bit of additional effort could bring it to a much greater audience. But I can't really judge that, since as a programmer myself (and probably even one with a rather extreme tendence in that direction) I know full well that programming, like any creative activity, is an end in itself and does not require any intention of making anything useful to outsiders.

The way I see it, throwing stuff away is what we're doing if we never shape the current PyPRP trunk into a release. Is the prospect of a new, libPlasma-based PyPRP really reason enough to leave everything we currently have behind in an almost-finished state? I admit I haven't bothered to check, but what I've passively heard so far has seemed a bit vaporware to me. Is there any actual development on it going on?

I wonder if more people think like you, Jojon. That would certainly explain the somewhat unimpressive response to this initiative.