The subject is already inflammatory enough, thank you. Please refrain from broadening the thread. I am not advocating forking DateTime. You want to do that, start your own thread. Don't hijack this one.
On 2010.8.3 9:21 AM, Evan Carroll wrote: >> I already have ShipIt::VC::Mercurial. There's no obvious next step. Now I >> give up. > > I've had like issues with many CPAN maintainers, and build systems. I > for one *abhor* using svn, hg, and darcs. There is no good reason to > it -- I just don't have the experience with it or need it typically. > It boils down to being a gatekeeper for a casual git users like > myself. But, I diverge. I find this to be a meta-issue of CPAN -- > which I'm quickly viewing as bad for workflow. My new MO is to fork on > gitpan (if the repo isn't natively Git). Then to publish on CPAN if I > feel like it. This only sounds offensive at first sight, but I think > it is a lesser crime then letting patches die in a dark-net because > you can't invest the time to get them upstream and the author can't > invest the time to throw you a bone. > > My goal in writing this isn't to vent, it is to convince you that > forking DateTime is not evil. It's all we have. Get over the stigma > and make all crimes lesser to letting your patch die off of CPAN. Fork > DateTime into DateTime::SanePractices. Git really has done wonders for > making code public. Anyone can fork on gitpan and apply a patch at the > very least. The mentality is even something that I'm fundamentally > more comfortable with: forking is a good thing. > > I think I have patches to a few of Dave's things that I never got > upstream for one reason or another. Many of my forks on gitpan are > used locally. > http://github.com/EvanCarroll/Fey-Loader > --
