pict3d maintenance

[Jay McCarthy]

As many of you know, pict3d is awesome. If you don't know, check out Neil's RacketCon talk from last year [1] or Matthew's talk from this year [2].

Unfortunately, it has not been being maintained lately. (The last commit is from June and there are a number of important pull requests pending. Some to get it to build at all on current Racket and others to add features and other improvements.) Two of the predominant forks on github are active and used. One of these forks is on the package server.

Generally, the strategy of creating a new name on p.r-l.o and directing traffic to it is a good strategy and inline with the goals we have in mind for the package system. As mentioned in the recent leadership meeting notes, I (as pkgs curator) have had the need in the past to help package authors deal with conflicts and similar issues.

In this case, and with much trepidation, I feel that the pict3d name and brand is too important to just bitrot while attention is given to `pict3d-fork` or `xpict3d`, etc.

So, I have...

1. Created a new Github project for `pict3d`

2. Merged all the outstanding PRs on the original project

3. Added the original author and all the main PR authors as contributors to it

4. Copied the `pict3d` catalog entry to `pict3d-orig` and made it ring 2 (because it conflicts with `pict3d`)

5. Used my curator powers on p.r-l.o to add the same people as authors on the `pict3d` package

6. Changed the `pict3d` package on p.r-l.o to point to the new Github project

I view actions 5 and 6 to be controversial. I did not do them lightly, but with consultation with some of the PR authors and attempts to pursue other ways.

I intend this action to be a temporary measure until the original pict3d author has the time and inclination to maintain it more or otherwise delegate that responsibility.

I am open to step down from this usurpation if the community has great rejections and is comfortable with using `xpict3d` over `pict3d`.

Jay

1. http://con.racket-lang.org/2014/#Purely-Functional-3D-in-Typed-Racket
2. https://www.youtube.com/watch?v=ABWLveMNdzg&list=PLXr4KViVC0qJAsNuDeQzhFDjMK1gEdls8&index=7

--
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

           "Wherefore, be not weary in well-doing,
      for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
                          - D&C 64:33

[Neil Van Dyke]

No comments on this particular package, but if the package system rules
are going to change in fundamental ways (imagine this were a programming
language), then those changes must be communicated to everyone.

Also, maybe it's time to think ahead to what other package system rules
there will likely be a desire to change, and get all the rule changes
over with at once, so that we don't get into the habit of changing the
rules on people.

When we're encouraging altruistic third-party contributions through the
package system, and presenting it as open and decentralized, then we
have to be aware of centralized, proprietary behavior that might erode
trust and discourage participation. One thing third parties have to go
on, in absence of formal business relationships and contracts, is the
rules or documentation of how these open-ish systems will work.

Again, no comment on this particular package; just trying to help the
new package system find the mix of centralized and decentralized that it
seems to be looking for.

Neil V.

[Matthias Felleisen]

Neil,

I appreciate your comments very much. From where I sit, I think these “take overs” will be extremely rare but always to the benefit of the community and with ample communication with the creator of the original package. Nobody will take over anyone else’s package by force.

What the community deserves, and what the Dunstable meeting has worked out, is an announcement of when we invoke this rule on a package so that everybody else — not only the previous owner and new maintainer — but everyone knows what’s happening.

— Matthias

> --
> You received this message because you are subscribed to the Google Groups "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/5675B7F9.3010509%40neilvandyke.org.
> For more options, visit https://groups.google.com/d/optout.

[Stephen De Gabrielle]

Hi,

Would it be appropriate for package maintainers to add (voluntarily) a special collaborator (like 'racket-dep-fixer') that can be used if there is a problem?

Other package maintainers might be more comfortable with the _pull request hack_ 'Whenever somebody sends you a pull request, give them commit access to your project.' - http://felixge.de/2013/03/11/the-pull-request-hack.html

Happy holidays!

Stephen

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/744FAF31-CCDF-4FF4-8288-03A2A89B1313%40ccs.neu.edu.

[Jay McCarthy]

I think these are both good ideas.

Jay

[Jack Firth]

Would it be appropriate for package maintainers to add (voluntarily) a special collaborator (like 'racket-dep-fixer') that can be used if there is a problem?

As the author of that service and account, I'd be more than happy to give its credentials to the Racket maintainers so it can be used for this purpose. Though maybe a different account (racket-package-curators?) would be appropriate, so as not to mix concerns.