I've been involved in Menu Trim module. The current maintainer David Lesieur haven't been active in a very long time. His last commit was about my material and the one before that was about month after his first commit.
I made significant changes and the last I heard from David about a review was on April 21, 2008 (#10) as you may see on #241155: Root Title, Min. Level, Limit and Dept.
Myself and a few people think that my changes should be committed in a normal version but they haven't even been committed in a development(dev) version.
I know that forking is a lot of hassle but it seems that it's the only option left to make the community benefit my improvements. Please leave you dis/approvement of the fork in this case along with suggestions and/or comments, hopefully constructive.
Comments
co-maintain (or take over) instead of forking
He seems relatively active - the last commit was April of 2008 which, while not super recent is at least in the last few months. Instead of forking why not become a co-maintainer of the module? All it takes is for him to agree and give you CVS access. If you don't have CVS account then you'll need that as well.
If it were truly unmaintained, then the abandoned project process http://drupal.org/node/251466 would be the appropriate thing to do.
--
Open Prediction Markets | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
--
Morris Animal Foundation
greggles beat me to it, but
greggles beat me to it, but you should at least exhaust these two options before forking.
@greggles for your
@greggles for your part please reread my sentence which means he didn't work by himself on the project for almost a year !
We exchanged a few emails, he won't give me CVS access. Do you think it's now ?
still not "truly unmaintained"
As long as there are commits fairly recently then it doesn't seem "unmaintained" - if he doesn't want to commit patches you've made then that is his choice as the maintainer.
However, it does seem like a long time without an update. My suggestion is to contact him again and see if you can agree to be a co-maintainer. Hopefully you saying that you plan to fork if he doesn't give you access will change his mind. If not...not.
Also, remember that co-maintaining is a form of cooperation and compromise. Perhaps there are things that he doesn't like about what you want to change and therefore you need to find alternate ways to implement them. I've found this several times with modules I co-maintain where we make something optional or move it to a separate module altogether.
There's lots of helpful information in http://groups.drupal.org/drupal-project-co-maintainers on this topic.
--
Open Prediction Markets | Drupal Dashboard | Learn more about Drupal - buy a Drupal Book
--
Morris Animal Foundation
follow-up and submittion
Following your advice from IRC, I entered created this #272704: co-maintenance formal request. *cross fingers*
Thanks for your advice.
denied
he denied
Further discussions about co-maintainership
If anyone wants to further discuss about the co-maintainership of Menu Trim, please proceed to the issue queue.
// David Lesieur // Whisky Echo Bravo // Web applications development // Montreal, Canada //
First, your work seems
First, your work seems valuable.
Now, taking a look at David response to your patch and at the patch itself, I think you had some kind of miscommunication. He asked for short single patches, each with a specific purpose. (To be fair, I don't really know if and when he would find time to process a dozen of single patches, but let's put speculation aside.)
From your side, you need at least to try to understand his response. Imagine for example that you are maintaining a working module which you are happily using in some of your projects with your clients. Someone comes along with some improvements. Fine. But suppose that the suggested improvements are almost a complete rewrite. It is natural to think that you are going to be stuck with a module which you don't understand thoroughly, and that you will need to spend considerable time to review something that was not in your priorities at the moment. You would think that practically allowing that guy to commit means giving up the module.
At the end, I think that if (a) you do not intend to submit individual patches and (b) David does not agree to give you commit permission (which practically means to give up the module) then go ahead and fork, because it is a pity for your work *and* your current enthusiasm to be lost for the community. But nobody is absolved of the "sin" (if that matters).
patches
@cog.rusty I already discussed the patches issues with David by email so I doubt this would be an issue.
I agree with you that it it a rewrite although the functionalities and algorithms remain the same. Although I already rewrote a lot of code with his suggestions so I think I do my fair share of compromise and show I'm committed to this project.
I wouldn't mind if David doesn't give me CVS permission if he'd review and partly submit what's appropriate and give me instructions to make the rest appropriate but it's not the case. For now I will follow greggles suggestion to formally request co-maintainance.
Please continue your input, it's a fresh outlook on things. Thanks !
Heh, if you ask me, I did
Heh, if you ask me, I did find myself in a position similar to David's once. Although I disliked some of the work submitted to that project, I didn't have much time to spend and rather than sticking around my nice dead horse, I gave up the community space that I was holding to the forces that be. But I can't judge just any situation.
dead horse
It looks like he's keeping the dead horse. I'm on the brink of forking ! :(
awkward
You know I don't know about you but if I worked hard on training a perfect horse and I find myself not able to anymore, I'd prefer that an awkward trainer would take my place instead that he'd stop keeping up with demand ; an awkward horse that keep up or a perfect one that won't !? For me the choice is obvious ...