Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for the Perforce VCS client via the "p4" tool #136
referenced this pull request
Sep 18, 2013
referenced this pull request
Nov 24, 2013
@ferd I don't know what that question means. How committed are you? Maybe I'm being overly sensitive, but I find it much more discouraging for you all to kick this around in a circle while shrugging than if you just said "rejected, we don't think anyone cares about Perforce."
This code works for me, for one project with one dependency inside one Perforce repository. If a bunch of people found it useful, I'd expect them to run into some problems, complain, and I'd improve it. But the vital element here is at least one person besides me who uses the patch.
Anyway, since I'm not hearing anyone else care about this, I'll keep it to myself. If someone comes along in the future and wants it, they can always look at my fork for a starting-point.
@waisbrot the question there is that I don't have perforce, I don't have any project using it, but I'm a collaborator to rebar (since a couple of weeks ago) and therefore directly or indirectly responsible for maintaining the code and fixing bugs in it.
Therefore, this is a feature I know I personally cannot maintain. I am not closed to the idea of having perforce support in rebar, but we shouldn't be adding features we can't reasonably keep improving. If you say you're willing to fix bugs that may show up with this, then that's fine and it should be included.
If this is a feature that is being 'dumped' on us -- sorry for the lack of better terms, I mean a pull request that is sent our way and then forgotten about by its creator -- then I am not one to want to commit to maintaining it.
Does this make more sense?
@ferd I think I was unclear and combined several unrelated statements into one blob. Let me try again (sorry about this getting a little long and dramatic):
Feedback about the pull-request process
I think you all do a generally excellent job of making Rebar a community project. Pull requests get dealt with quickly and the project generally feels well-loved. That's why I felt comfortable putting some significant effort into a pull request that I didn't think would necessarily get accepted.
In this case, I'm guessing that everyone thought "more VCS support is better" but nobody wanted to actually push the button for a VCS that they'd never touched. That's reasonable, but in my opinion it's disheartening to be stuck in the middle spot and I'd have preferred a snap decision one way or the other.
I don't think this is any systematic problem with how you're handling pull requests. Just a data-point for the future.
Level of commitment
I am a little defensive about this. I think that if the time I spent writing two alternate versions of this and discussing it isn't sufficient evidence that I'd try to maintain it, then me making some kind of written promise to do so certainly shouldn't be sufficient. If you feel you have to ask, just say no.
Should it be accepted? (no)
You say you can't maintain it. I assume that's true of the rest of the maintainers, too. I think that's a problem for this commit because even if I swear a blood-oath to maintain it, it's just one person away from bit-rot.
The other problem is that this has been hanging around for a while and I don't see anybody wanting it. I could add a 'base-64-enc-tarball-in-postgres-table' dependency type for Rebar, and even if it was awesome code the right thing to do would be to reject it because nobody will ever use that. The conclusion I've come to is that a Perforce dependency is in the same category.
There's an additional level of zaniness that tarball in a postgres table would have that p4 doesn't (I was happy to see hg eventually making it in, so p4 would be nice for their users). I'll take a note to try and build this, check a few things, and merge it when possible. I know I'm currently in a rush at work and low on time, but I'll try to merge it in.
The status for this one is: mergeable, should be merged (bar a few checks I want to make as I'll be the one to merge it in all likelihood), why wasn't it merged before (who knows).
Sorry for the long wait. I think @tsloughter and myself were added to the Rebar project in an attempt to help prevent this from happening in the future, and we're trying our best.