Todd Zullinger wrote: > I just was building this locally and noticed that the patch I > submitted for install.rb to fix up the lib permissions got typo'd in > translation from the mailing list to the git repo. The patch I sent > changed the perms on the installed files, but what got committed > changed the perms on the lib directory instead. That borks the > install, as there are no permissions to change into the lib dir and > File.install tosses an exception. :( > > I'll attach a trivial patch to fix that.
Fixed and pushed out new packages. > Now, I've probably lobbed enough patches your way that I should really > setup a public repo for you to pull from. But I'm also curious what > issues there are with git am (or even git apply, followed by git > commit --author ...)? I know the git am workflow works on projects > like git itself, the linux kernel, and many others. I also know that > more than a few projects don't use it for reasons I've yet to > understand. (I don't maintain much public stuff myself, so I don't > have the experience that either of you have in this area.) > > If there are problems with git am or its documentation, I'd like to > help see those get fixed. I help maintain the git packages for Fedora > and EPEL, so I try to be attentive to what's going on in upstream git. I can't remember why we didn't use git am - I think both Luke and I had issues getting it to work. We'll have to take another look though. I don't like the non-attribution thing either. But some of the issue is the multiple places patches show up. Currently I pull from repos, cut and paste patches from emails, pull patches from attachments in tickets and emails, and as you can see occasionally fuck up manually editing small patches. This whole thing is broadly an attempt to lower the bar for commiters so we'll take patches from everywhere. This is probably not a good approach. > I think git am is a really good tool with many advantages. Keeping > everything attributed to the original author is only a small part of > the advantages (though it is a nice one, so that you can do things > like http://git-scm.com/about, and show how widely dispersed the > contributor base really is). More importantly, it keeps maintainers > from having to worry about manually editing patches and potentially > introducing typos. It also lowers the bar for new contributors, as > many folks probably resist setting up a public repo for just a few > minor patches. Agreed - we'll look again at it. > The price of using it might mean spending a little time training folks > on how to properly submit patches (and asking them to fix and resubmit > on occasion). Hopefully the benefit is well worth the cost in helping > to make it a little bit easier to get new contributors into the fold. See above about patch sources. Happy to field ideas. > > Many thanks for all the hard work you guys do! > > (If this is something that you'd rather discuss on puppet-dev, feel > free to forward my message there or let me know and I'll re-send it > there.) cc'ed the -dev list. Regards James Turnbull -- Author of: * Pro Linux Systems Administration (http://www.amazon.com/gp/product/1430219122/) * Pulling Strings with Puppet (http://www.amazon.com/gp/product/1590599780/) * Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) * Hardening Linux (http://www.amazon.com/gp/product/1590594444/)
signature.asc
Description: OpenPGP digital signature
