Let's not duplicate efforts

Hi there,

I apologize for being wary, but when I contacted you on October 15th, there was no Drupal 6 version of your module, and your tone was a bit different than now. Despite a request from your users as early as February 11th, an official Drupal 6 module was not released until October 17th. Furthermore, having read the email you sent, you request that I take down Pagination (Node), whereas now you are suggesting code collaboration.

To be clear, I'm not opposed to code collaboration (as I mentioned in my initial contact with you), however at this specific point in time there seem to be a number of outstanding issues with your module, as well as a difference (admittedly slight, and perhaps insignificant to the user base at large) in the interface to configuration options, not to mention a slightly different feature set. If you have been in contact with site maintainers, I'd suggest we talk to them in a more appropriate forum about how to best handle the situation, as this is the first I have heard of anyone bothered by the existence of both of these modules.

Personally, I have no problem with "competition", although I do realize that aspect of open source development can cause issues for users in an environment like Drupal, where you have thousands of modules. As you can see, I have been happy to point users in your direction, and to ask them to decide on their own as to which features/functionality best suit their needs.

In the code collaboration issue you asked permission to use paging's code for further pagination development, not for what the title meant. In my follow up I explained that those features already exist in paging in the cvs for Drupal 6. It was my mistake I didn't invited you at that time.

Regarding the Create a release for Drupal 6 issue, I agree I have been lazy with creating a release for D6, but that was due to my slow(bit too slow? comeon I have a life) development pace for the features I had planned to include in the first release (D6). If the release time was the factor, you could track the cvs code and take the responsibility after you get the cvs access.

If you find issues that you are desperately in need of a fix for, the first task is to get them fixed, or do it yourself if you are capable of doing and the maintainer is unable to. I even provided CVS access to sun and Darren Oh, when they had planned to bring in some fixes for Drupal 5.

"Competition" feeling is good, but Drupal isn't a market to compete in, clear as that. Grrrrrr.. I argue a lot. sorry man I feel hurt.

Despite all of this resistance, are you interested in collaborating? Again, forgive me because I know I do talk harsh.

Paging <3 you. ;)

@mundowen: I support Gurpartap's request for collaboration and ...

Hm. I actually wanted to write "we'd welcome you as a co-maintainer". However, upon looking at the source of pagination.module, I had hard times finding a line that adheres to Drupal's coding standards, and as you know, coding standards are the most important prerequisite for collaboration and innovation.

Also, the module

• is using some defines, which it does not really need to (also, those should be prefixed with the module's name)
• makes improper use of HTML block elements in t()
• could use drupal_map_assoc() at least in one case, but does not
• does not properly implement Form API and seems to need a #name trick because of that
• could use Drupal's menu system to reduce the burden on pages where the module does not do anything, but does not
• contains many PHP E^ALL issues
• performs "paging" at the theme level, which is not compatible to Paging at all, and a wrong approach IMHO (think cached pages)

I would definitely not want to see such code in Paging. However, if you could fix those issues and we could agree on a few Drupal standards for collaboration, then I think we would be good to go. :)

That said - no insults - but I can understand your motivation for creating this project, as I also had hard times to "catch" Gurpartap in Paging's issue queue some time ago and actually thought about forking Paging into a new module myself back then. Also, I would not (and still do not) agree with some of the latest changes in Paging, as well as Gurpartap's way of submitting/reviewing/committing own patches... However, all of those points lose priority and importance when it comes down to users searching for a module to solve their use-case. Duplication hurts not only them, but also the Drupal community at a glance. So the best we can do is to join forces and focus on getting at least one solution right. And since Paging has a large user-base already, it would be a shame to have all of them migrate to another module, which may or may not be stable and maintained in the long run.

In short: Let's join forces in Paging module if you agree!

Hi guys,

I'm honestly not sure how to respond to this, so I'll try to do it as tactfully as I can.

First thing I would suggest, is that you take a look at your own module and development processes. A lot of these coding standard issues you raise as huge concerns are prevalent in your own module. I'm not here to trade nitpicks on each other's code, but it seems entirely disingenuous to point out minor, easily correctable issues that do not affect the module's functionality, when many of those same issues exist in your own code.

Second, you say that you're not happy with how Gurpartap has been responding to the issues queue, to the extent that you even considered forking it. You go on to mention you are not happy with the development process, yet you somehow expect me to climb on board, knowing that the two co-maintainers can't even agree and adhere to their own process of development?

Thirdly, you keep saying your main interest is our collective user base, yet you seem more than willing to inconvenience the users of Pagination (Node). If you are truly interested in providing the best solution for our users, you just may have to accept the idea that your module should be folded into this one. Don't get me wrong, I'm not suggesting you do such a thing (as I've said repeatedly, I am more than happy with both of these modules existing), but if you are going to assume that I should be fine with shutting down my module, you should have considered the same for yours.

Finally, you seem to have concerns as to whether my module is "stable and [will be] maintained in the long run". Your answer should really be in both module's issue queues. Here is your quick comparison: Pagination (Node) and Paging.

As I mentioned in my initial response, I can not help but be wary of your intentions here, given the rather abrupt response I received on initial contact, the private request for me to take down my module, and now this public request for code collaboration that faintly smells of a discrete way to silence this module.

Just to clarify, as I know text isn't the best place to express oneself, and it's easy to read into emotions and subtleties that just aren't there, I have absolutely no problem with both of these modules existing. I also have absolutely no problem with code collaboration. However, I have huge potential issues with how you guys are running things over there, and the state of your module at this time, as it relates to me joining that effort.

Ultimately, if you are truly committed to providing a single module for pagination for all Drupal users, and wish for me to get on board with that, I suggest that you:

1. Figure out a development process both of you can agree with, and adhere to
2. Fix the outstanding issues in your issue queue, (preferably using your new development process) and do so in a reasonable time frame
3. Take your Drupal 6 version out of beta
4. Present to me an outline of how the modules can be merged, with minimal to zero impact on either user base

Hi mundowen,

I have worked on most of the issues in paging and have made another beta release, although I believe it's pretty good for a stable. I would love your participation before 1.0 is released, so that it lives for long. Regarding the pagination to paging upgrade, it'll be quite easy. A simple upgrade script which converts pagination's variables into paging's variable should work, and if there's any exception, we can work out on that as well.

sun has authored Best practices for co-maintaining projects book page, for what the title says. But I find it to be a bit too restrictive. I won't mind any co-maintainer committing simple patches. And bigger changes should should be introduced in issue queue as patches. Feel free to follow either of these.

I have provided you the project commit access. Sorry if I have ever been harsh at words. I *really* hope you are comfortable. Rock on!

I'd like to throw my two cents in here. I'm not a developer, but understand the need for following drupal coding standards, proper use of form api, caching of pages, etc. and would hope that both modules would do so. I make no defense of either module's quality of code. I'm a designer/UI/UX guy. Having said that, I just tried out both modules to meet a need on a site I'm building for a client. I find the pagination module exponentially easier to implement/administrate/setup than the paging module as well as far more useful. The optional TOC that's also made available as a block is highly useful for nearly any purpose I would be using the module for. If the two modules were to merge, I would certainly hope that, in terms of admin UI and how you setup the module via the UI, that paging would be borrowing from pagination, and not the other way around.