Resending, to the whole list this time: I've been focusing on getting 4.4 feature complete. That's done now so, as soon as I can get the next beta out the door, I will start focusing on bug fixes and release candidates. This process could be accelerated if more people would review patches and provide feedback.
My suggestion to submit to the patch tracker—in addition to the pull request—was to provide more visibility for the change. As far as I can tell, no one else is looking at BitBucket. Thanks for the contribution! Jason On Feb 25, 2012, at 1:17 PM, Jason McKesson wrote: > I've noticed that premake-dev on Bitbucket has a number of outstanding > pull requests. I recently added one for a bug fix. > > Some of these requests have expired due to the deletion of the original > repo, but others seem to still be active. I also noticed that you have > stated on some of them that they should be submitted as patches over on > SourceForge instead of pull requests. > > If that is the case, if you're not going to accept any pull requests, > then it might be a good idea to deactivate public forking altogether. > The whole point of the public forking system on Bitbucket is to make it > easy for someone to get the repo, make some local changes, have them > back up on Bitbucket, and then hand those changes back to you for > evaluation. Rather than "patches", which are unversioned > single-revisions which, once incorporated into the repo, would conflict > with the changes that the person just made, pull requests preserve > version history, changesets, and so forth. Thus there is a complete > paper-trail of the fix, who created it, where it came from, how many > iterations it took to make it work, how it was merged with the mainline, > etc. > > If you're not accepting pull requests, there's just no point to anyone > publicly forking from premake-dev's Bitbucket repo. That being said, I > would strongly urge you to reconsider your stance on accepting pull > requests via Bitbucket. As previously stated, it makes tracking where > changes came from much easier. Sourceforge may be more visible to some, > but distributed version control wasn't invented to fling patches around. > It was created to be able to fling changesets and repositories around. > If it needs to be tracked on SourceForge, then a bug should be filed, > referencing the Bitbucket depo and revision number containing the fixes. > That's a lot more useful in the long run than a patch request. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Premake-users mailing list Premake-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/premake-users
