Closed (fixed)
Project:
REST Client
Version:
5.x-1.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
10 Dec 2009 at 12:59 UTC
Updated:
9 Feb 2010 at 18:29 UTC
Hi dragonwize,
Seeing that this module has gotten very little attention since it was first created, and haven't been ported to D6, I would like to take over the maintainership, or at least take maintainership lead for the D6 branch and the upcoming D7 release. See: http://drupal.org/node/251466
I have a rest client for D6 here: http://github.com/hugowetterberg/rest_client/
It has pluggable authentication support and lots of other nice features that works well with the Drupal rest_server.
Cheers,
Hugo
Comments
Comment #1
dragonwize commentedHi Hugo,
I have not updated the code on this project in awhile but I have been using other implementations I have built in different ways. The main reason I have not uploaded more code lately is I have been building with, using, and in general studying approaches used by others and much of that code is not GPL compatible. However, I have been working on creating a new system from scratch with what I have learned that will be GPL compatible. The 5.x of this project was my first attempt at that long ago and one of my first Drupal modules.
I looked at your work and it looks good so far. I would love to collaborate with you in moving this project forward. A couple items that I am insistent on the system handling though is it has to have a pluggable network system (curl, sockets, streams, etc), it has to support HTTP 1.1 including proper handling of Expect 100 headers, and it has to have streaming/chunking capability among other things.
Comment #2
Hugo Wetterberg commentedGreat! I've looked at your code too, and I really liked that part of your implementation. My immediate plan is that the current RestClientRequest class should be turned into a more abstract class that then could be subclassed as RestCurlClientRequest, RestSocketClientRequest.
It would be great if we could get a 6.x-branch up and working from my current codebase, nobody would be cheated of the non-curl compatibility as the module doesn't exist yet. Does that sound good?
Cheers,
Hugo
Comment #3
dragonwize commentedHugo, I've committed your code to head so we can start patching in the queue from there.
Comment #4
Hugo Wetterberg commentedGreat, but my original issue was also about co-maintainership.
Comment #5
Hugo Wetterberg commentedAlan, I'm kind of expecting a follow-up on this issue from you.
Comment #6
voxpelli commentedUpdating the topic to make it clearer that the goal of this issue is to have Hugo Wetterberg (a colleague of mine) take over as the new maintainer - since this project obviously isn't actively maintained.
In accordance to the guidebook about Dealing with abandoned projects I want it to be clear that the aim of this issue is for REST Client to get an active maintainer. If the existing maintainer doesn't wake up before two weeks has passed then this will be moved to the webmaster queue.
Hugo has an actively developed branch of REST Client on GitHub which other people have started contributing to. A snapshot of that branch was committed to this project by the current maintainer, but since then nothing has happened.
Comment #7
dragonwize commentedAs I previously stated, I am and have been working on this as a side project and am in the process of ensuring my code as it has developed over the years is GPL compatible before making patches and/or commits of it. I committed Hugo's code as he mentioned he would like to start with it as a base but since then has not contributed any patches or filed any issues since then so his participation in this module has been as blank as everyone elses.
To Answer your question, "Can Hugo Wetterberg have maintainership of this module?"
No.
At this point, this sounds like a hostile take over than someone who wants to work together as a team. I did not originally give Hugo maintainership because it sounds like Hugo has some completely different ideas than mine and I had no indication he would be a good match for my project. After this request, it is obvious to me that I was correct in that manner. There was never any intention to work together only to completely take over my project for absolutely no reason at all.
I still like Hugo's commitment to work on something and since this last post did not come from him, I won't count it against him. As per the documented way of getting to become a co-maintainer in a project, I would like to work together with Hugo in the issue queue toward a better project and if we can work together then he will most definitely be a co-maintainer. You can quote and reference me on that.
Comment #8
voxpelli commentedThe reason for the update was because you didn't respond to any of the questions regarding the maintainership of the module even though it was repeatedly asked for - thus you gave the impression of not being very interested in it.
Dealing with abandoned projects clearly states that if a project seems to be abandoned and one would like to aid in taking over the maintainership - then such a request need to be very clear so that no misunderstanding occur. That clarity might seem hostile - but it's just to avoid any misunderstandings.
Hugo has clearly linked to his development copy and been active in this issue regarding how the project should be maintained - so I think it's unfair to say that he hasn't participated. It sounds more like there has been a lack of communication and agreement regarding the future of the module and that thus the committing of Hugo's code to the module might have been a bit premature.
I talked to Hugo about this module and since I'm aware of the procedure of handling abandoned module I added that last message to clarify the situation. My impression was that this had become an abandoned module and thus a clarification of this issue suitable for the webmasters was needed to be able to move forward. Since it is now apparent that it isn't abandoned - that last message was unnecessary.
Still - a discussion regarding the workflow and cooperation on this project seems pretty needed? I will leave this issue to you and Hugo now.
Comment #9
Hugo Wetterberg commentedAh, well. I'm sorry if this last post upset you Alan. But I've been waiting for a response on this issue from you for two months. Pelle offered to put in a properly worded update so that it would be possible to take over maintainership if you continued to ignore it. Regardless of how hostile you think that was, at least it elicited a response.
The issue at hand is a bit unique, as the 6.x version of rest_client is entirely made up of code written by me. I must say that I was a bit surprised when you just lifted the code from github and committed it without first (or at least at the same time) addressing the issue of co-maintainership or having any kind of discussion with me. Your position would be understandable if what I had done just was to port your module to Drupal 6.x, or submit a simple patch. Less so when we're dealing with a completely new codebase for a module that only existed for Drupal 5 and never has had a release. Given these circumstances I don't think that the maintainership lead on the Drupal 6 branch was a unreasonable request.
If you're not interested in having me as an active co-maintainer for the D6 branch, and feel the we don't share a common vision of how this project should be managed, I think that it would be best if you just removed my code from the rest_client project and take it in the direction that you'd like. Then I'll be free to explore other options for publishing the code on drupal.org.
Comment #10
dragonwize commentedThis issue at hand is not unique. I see these kinds of requests in modules all the time. I call them blackmail ("I will be a maintainer or I will not participate") for lack of better term and do not have any wish to work with people of that nature.
I removed your code from the project repo.