Dist::Zilla is a great release tool, code generator, and it just plain takes the boring part of doing a release away from you.That having been said, it does, imo, horrible things to your source repository. “But, Caleb, it cleans up your source repository you can remove a lot of excess stuff you don’t really need to be storing there”. Well… I disagree, to the point that I’ve used every explicative in the book to express my displeasure. Let me explain why I disagree.First let me explain my use cases. I have only one package on CPAN, Template::ShowStartStop and it’s relatively simple to the point that Dist::Zilla is almost overkill (but I still find it nice). I also maintain a sizeable portion of CPAN on Arch Linux’s AUR. In addition to standard CPAN Packaging for my own package I created a -git package which allows me to install directly from my source repository on Github. That worked wonderfully well until I started using Dist::Zilla (note: I haven’t gotten a poorly working (read hack that’s buggy) version now).So Dist::Zilla is great for CPAN, no problem for normal downstream packages, but makes things more painful for Version Control Users. “But Caleb, it does nice things for me for version control”. Yes it does, but I think it also has some consequences that people don’t realize. If you know how Dist::Zilla works pretend that you don’t.Look at my repo What License is my code licensed under? usually this is in the COPYING file. There’s no COPYING file there. How do I install it? No README either, oh and the module isn’t complete as is things like version are stripped so Dist::Zilla can generate them for me. This list goes on and on all basically leading back to my issue. Why does Dist::Zilla have to take these things out of my source repository?The answer was… you wouldn’t store .o files in your repository would you? why would you store these generated files… oh I dunno… because someone shouldn’t have to install Dist::Zilla just to use my latest git? and they aren’t like .o files because those are binarily specific to a lot of things and won’t be useful on most other machines, unlike these files.Let’s say Dist::Zilla has a bug in what they generate for code. They fix it, I update, all is good for me. Someone else who hasn’t updated Dist::Zilla downloads the code and builds and hits the bug… they complain to me. I explain it to them, they update Dist::Zilla, they’re happy, I’m happy. But we could have avoided this, if I stored all the output in my repo they’d never have to worry about Dist::Zilla.So I’ve been told this will never be fixed because they don’t want to clobber the existing files, plus the whole… these are like .o files, thing. Ok, clobber == bad. So how could we fix it so I’m happy? and everyones happy. We should a directory src shall be the source of all non generated code. Much like when working with compiled code you have a src directory for source files and a directory for output. the lib that’s still here will be the final generated lib. All the top level files will also be generated. Only the stuff in src is what should be worked on. And the generated README will give all these wonderful instructions that will now be presented to users visiting the github repo. And when I’m writing a -git package I won’t have to include any dzil instructions because I don’t need to generate this code all the time.and you know what? if people don’t want to store generated files in there vcs they can always use something like .gitignore. So everybody should be happy.For backcompat just make it a configuration in dist.ini. We can have a [src] dir which could be . for those who want it the way it works now. and an [output] dir.Will Dist::Zilla be worth this pain? I’m not sure.– This work by Caleb Cushing is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.