No More Excuses
Occasionally I find a bug in someone's module and post a patch or a bug report. About half the time, the bug is fixed and the new module is released in less than a week. Could be better, but not too shabby. However, about the other half of the time the bug either goes unanswered, or I hear back from the module author that the patch needs to wait until some big release that they are waiting on. I hereby declare bullshit on that. Dist::Zilla makes it so ridiculously easy to push out a release that there is no longer a reason to wait on pushing a bugfix release immediately.
I've been using Dist::Zilla for over a year. And lots of people have been blogging about it lately. Ricardo has managed a masterpiece with Dist::Zilla. What used to be a pain in the ass to package up a module and test it for the release process is now a 30 second operation.
Recently a colleague of mine submitted a patch for [REDACTED so not to embarass the author] and was told that the maintainer couldn't put out a release for a month or so because of some other stuff he'd like to get into the next release. Another friend of mine submitted a patch to another module author 5 months ago, and has emailed him personally several times there-in, and didn't even get the courtesy of an email response. In the past week I've gotten bug report, 1 documentation patch, and 1 request for enhancement. I was able to put out a new version of each of those 3 modules the same day it was requested. Granted, I happened to have the few minutes needed to resolve the request in each case, but Dist::Zilla is the real reason I was able to achieve it.
If you are a module maintainer, and you're lucky enough to get someone to send you a patch, take them up on it. Sure you have to vet it, and sure it may not be up to your standards, but they put in the effort understand your module enough to fix one of your bugs, or add a feature for you, so you can put in the effort to apply the patch and type "dzil release".
Everybody has lives, and nobody has enough round tuits. All I'm saying is that if you switch your module to using Dist::Zilla, it only takes 1/4 of a tuit to put out a new release. Then you have no more excuses for not accepting patches in a reasonable amount of time.
My little part in the greater Perl world.
Releasing is only one part of the problem. Dzil certainly helps, but it takes a fair bit of work to grok it and get started with using it.
However, the other problem is repository management. If you're neck deep in major refactoring, and someone sends you a patch against the last version, it's somewhat annoying to go back in history, apply the patch, and then forward port it.
This can be made easier by doing all such changes in a branch, but I doubt most module authors maintain that sort of discipline except when the distro has multiple authors (like Moose or Catalyst).
It's easy to make a release (my own Module::Release was making it easier before dzil was around). That is, once all the files have the content you'd like them to have, it's easy to package it and send it to CPAN.
However, getting the content right in all the files is the tricky part. Often the patches I get are band-aids that don't solve the real problem or solve it in a way that causes problems for other parts. Usually the patches I get don't come with tests or documentation. These little bumps mean I need to wait to deal with it until I have time to see what's going on and verify that the new code isn't going to cause problems for other people.
You say that they took the time to "understand your module enough", but I often find that is not the case. They understand enough to fix their particular issue, but that's often not the real, more general issue that causes the problem.
In reality, my most often response to patches are "Can you put this in RT", followed by "Can you send me a pull request in github?" Patches reported to my personal email get dealt with like all of my other personal email, which is the worst way to do anything.
I don't think dzil helps to solve any of this in any way. It's just a tool.
Autarch and Brian,
I understand that the actual time it takes to accept a patch can be substantial, but most patches aren't. Only once have I ever received a patch with so much substance that it took me more than an hour to grok it, and either apply it or import it. And in that case I was lucky and was able to just give the module over to the guy who clearly wanted to do more with it than I did.
Everybody is busy. If you're going to put your module out on the CPAN, then deal with patches/bugs quickly. If not, either say that you're not maintaining it in the POD, or don't put it out. Don't make excuses about how substantial an effort it is to accept someone's patch. Most of the time its not.
s/import/fix/
Well, JT, I don't think you have enough information to say "most of the time", or to judge the patches I get, or to even assume that I'm not releasing modules based on patches I get. Don't generalize your experience to the experience of other people. Don't mistakes reasons for excuses.
If I can apply the patch and release, I do. If it takes more work, things get held up. Release tools do not fix that. I call bullshit on making this a black-and-white issue, and setting dzil up as a strawman.
You can say that dzil has helped you, but it doesn't follow that dzil solves every other problem.
Fair enough. I've never submitted a patch to you. I also never said that "Brian D Foy" is a lazy bitch who never puts out any releases or accepts any patches. What I said was the majority of the patches me, my friends, and my colleagues have been offering up are getting delayed by excuses. Therefore you should also not overgeneralize and say that it's not the majority.
I and people like me have submitted a lot of patches to a lot of people in the Perl community and had this problem. Enough that this is a serious problem that needs to be addressed. And Dist::Zilla can address that problem, at least when the excuse for not publishing a module is "I don't have time to make a release", which is what we have been hearing from dev after dev over the past year.
In fact I'm at a conference today, and out of 10 people that I asked about this problem, 7 of them said that they have experienced this problem in the past year. Small sample, but 7 out of 10 is a majority.
I don't have time to upload several dozen repositories to Github in one swoop, much less convert their build systems to dzil. With that said, those repos which I have migrated are substantially easier to manage for small patches like you suggest.
I think dzil goes further than other release systems have in automating away everything that can possibly be automated, but in a well-compartmentalized, re-usable way.
My experience echoes JT's. Pretty much every loose end or rough bit that might convince me to procrastinate cutting a release is gone. Bump version numbers? Automated. Update Pod with version? Automated. Timestamp the Changes file? Automated. Check everything into git? Automated. Run t/ tests? Run xt/ tests? Automated. Push tags? Automated. Upload? Automated.
All I have to focus on is the code. Yes, other tools do some or even all of this, but never as smoothly as I've found dzil to be. It doesn't remove technical barriers, it removes psychological barriers.
Of course patches sent against older commit points are a pain, but letting them sit longer makes the problem worse. And patches without docs or tests should get thrown back to the submitter for revisions.
I took JT's article as a call to authors to not let poor release management practices stand in the way of applying patches and releasing them. It doesn't really matter if you prefer dzil or Module::Release or your own tools. But there are enough good options now that doing it manually is not the way to go.
-- dagolden
In the next release iteration of BioPerl we will be modularizing the monolithic core distribution (which is anything but 'core' at 800+ modules), something that's been waaaay overdue. So, having a more automated way of releasing code to CPAN, either via Dist::Zilla, ShipIt, or otherwise, is definitely in our future.
I also agree with many of the dissents, particularly autarch and brian d foy. Simply put, every ecosystem is different: simple generalizations won't work. But your main point is valid: the tools now exist to ease the pain of making a release quite drastically.
Now what we need is a good comparison article of all the various tools: Dist::Zilla, ShipIt, Module::Release, etc.
@pyrimidine: +1. I've only used Dist::Zilla and would like to see some article doing detailed comparison of release management tools.
I have also been wondering how far Dist::Zilla is affecting the frequency of CPAN releases (Does it make releases more often? Does it make each release containing fewer changes? Does it increase module's kwalitee/some other criteria?) And compare that to ShipIt/whatever.
Many people believe that publishing to CPAN should not oblige them to do anything, horses mouth etc. While I don't really agree with that view - I think it is impossible to get to any consensus as to where is the limit (as the recent conversations at the http://www.xenoterracide.com/ blog show).
First, off let me say that I'm part of the problem--I know that many people who read the post will not ever get past that statement, but for those that do here goes...
I've been writing perl code since early v3, I've got a PAUSE id , but you'll notice there's nothing posted there--hence part of the problem. The majority of the code that I've produced is for customers or employers so there's copyright issues involved, so that's some of the reasons my PAUSE account stands empty. But that's only part of it, the other part is the stress that's involved, not release stress, because as you pointed out the tooling is there to support that stress. It is the religous wars that occur over things like this issue.
Is CPAN a place to altrusitically put code that I've developed that someone else might find useful, or is it a commitment to maintain this code for every use case that consumers of it might later decide to use it for. By uploading my code am I then obliged to maintain it in perpatuity as a 2nd unpaid job?
I can see both sides of the argument. As a user of some of the modules on CPAN, I do get annoyed when people intentionally make non-portable platform choices, because they don't like a particular platform--but then I stop myself and say--isn't that his/her right?? I haven't paid of their services, what right do I have to make demands on their choices. Especially since they've, generally, given me permission to take there code an modify it to do as I see fit. I don't like there design choices I can copy it and fork off my own new module set to do as I see fit.
Back to the original issue of patch deployment... If I create something and put it out there for the world to use, what is my olbigation to maintain it. If someone sents me a patch, and doesn't get an release immediately does that make me a horrible person? I can see JT's point about, how he's trying to assist the original creator with making a better product for the communitee at large, but does that assistance come with a implied responsibility for the original creator
Does releasing a module to CPAN give the community at large a say in the way the module maintainer prioritizes mainiting the creation vs. everything else going on in his/her life?
What is the implied contract here? Or is CPAN simply a place to put some code that you developed that you think someone else might someday find useful...
-W
I think you're right, that it shouldn't necessarily be true that you're willing to support your code on any specific time table just because you put it up on CPAN. However, I think lots of people that use modules prescribe to the idea that patches will be accepted or rejected quickly. I know I'm one of those. Maybe one solution to this would be to add a "TERMS" or "SUPPORT" section to the POD that describes how you accept patches, how quickly to expect some sort of a response, or whether you support the code at all.
I totally don't mind forking a module to fix it, but I don't want to do that if the original author intends to maintain it. If I knew in advance that the module author isn't interested in patches, or that it's not a priority for them, then I wouldn't bother them. I'd simply solve the problem another way, including but not limited to forking the module and releasing my fork to CPAN.
Beside forking there is also the possibility that the original author would be happy to pass the maintenance of the module to the patch author. I, for one, am willing to pass the maintenance for all modules that I don't currently use any more. That also does not need to be binary - there are many modules that are maintained cooperatively.
If you feel the author is not responsive enough - how about taking over the burden of the maintenance from him.
People get busy, interest shifts, modules get unmaintained.
I think modules that have more than one maintainers have a better chance on the long run. Unfortunatelly there are relatively few examples for this and I think the current culture of the Perl community rewards a new module more than taking over and maintaining an old one. I wish we were more actively encouraging co-developing modules.
I wonder if META.yml had a field listing all the authors (or PAUSE ids of authors) and if search.cpan.org supported that. Would that encourage more people to share the burden of maintenance?
I don't understand what you want. META.yml already supports a list of authors (really just contacts) rather than a single one. Even mailing lists can be put under 'authors' as the place to go for support. By design, it's not just "CPAN author IDs".
PAUSE already is the place to manage "co-maintainer" permissions. The list of module permissions is available as /modules/06perms.txt on any CPAN mirror.
All the underlying mechanisms and information you seem to want is already out there.