Open JordanRL opened 9 years ago
Could use:
@NoodlesNZ is the maintainer still active? Last commit was 2 years ago. Can't get our pull requests approved if the maintainer isn't active any more.
Also, would we be making it available via composer as part of modernizing? This could be a really interesting one. There's 5 open PR's, the newest one from 2014 and the oldest from 2010.
Not that active any more, he just left Etsy (CTO), so he probably has a bit of time now. Maybe worth pinging him on twitter (https://twitter.com/kellan)
You know, I didn't put this together to help my own projects specifically, but I'm leaning towards using Fermat for the first Jubilee. Because I'm the maintainer of the original repo, it gives us a bit more room for error on this end to work out the kinks of our first sprint.
It also has no unit tests, so those who wanted to get experience with those will get it, and it's an entirely math based library that hasn't been audited for security or bugs.
It really isn't my decision though. We should decide our projects together. Just some thoughts.
+1 for Fermat, doing the first sprint when the original maintainer is already participating makes a lot of sense.
I agree with Fermat as well. Let's start small and let's see how the team works together and move forward from that.
Well, we also should figure out how to vote. I think github is the only legit way to vote, so I'll start a thread on Friday for us to vote with the :+1: icons.
+1 for magpierss, because it's kind of a fun lib that seems really old (no composer loading, no namespaces, etc - from the description: 'Additionally this code was written when PHP 4.1.2 was the state of the art, and it shows').
+1 for fermat, +1 for phpcollection, because they seem useful.
Kint
seems to do more or less what symfony/var-dumper
does. I don't see much point in 'investing' work into this library just for the sake of contributing with something.
Indifferent cPchart, and I have no other suggestions.
EDIT: Actually, I've been thinking about it, and I don't see a way to truly refactor magpieRSS. It would require a full rewrite.
@naroga RE: Magpie, I contacted the project maintainer via twitter (he's the former CTO of Etsy) and he said he'd be fine merging pull requests, but they would have to be small. He doesn't want one big diff.
Given that there would be rewrites involved in some files, I'm not sure it's something we could do that easily. It might take two sprints.
he said he'd be fine merging pull requests, but they would have to be small. He doesn't want one big diff.
That's a weird constraint. So, I'll add composer autoloading, but I won't be able to make it load PSR4 classes, because I won't be able to break the functions (scattered over .inc
files) into classes and add namespaces to my files? I'll have to do it step-by-step, change a few things at a time?
I say this because a commit that "Changes code style to be PSR2 compliant" would literally change 100% of the project. Should I change 10% of the codebase to be PSR2 compliant while keeping the rest a mess because the owner doesn't want to review a big diff?
Just passing along what he said. :) We can use that information in our voting on which project we want to work on.
I'll rectify my vote, then.
-1 for magpierss, -1 for kint, +1 for fermat, +1 for phpcollection, abstain on cPchart.
Reply with project suggestions for us to roll through with fixes and improvements. We will vote on the projects we work on.
[Link to Project]()
Next Jubilee (Undecided Project): Starts Nov 12
Projects under consideration: