FYI, Bitbucket will be allowing pull requests to be pulled to a different branch, for easier integration into the main development line. There's an issue following it here: https://bitbucket.org/site/master/issue/3681/allow-users-to-edit-the-destination-of-a . That should make it easier to accept pull requests and evaluate them.
On Tuesday, February 28, 2012 4:23:27 AM, Jason Perkins wrote: > To follow up on this—it would be a big help for everyone if there was a "how > to contribute" guide for Premake. Something along the lines (though perhaps > not quite so comprehensive) as what the OGRE project provides: > > > http://ogre.svn.sourceforge.net/viewvc/ogre/trunk/Docs/CodingStandards.html > http://www.ogre3d.org/docs/OGREDeveloperGuide/index.html > > It would be an even bigger help if this guide could be a little forward > looking and lay out how we *ought* to be working—I know there is a solid > consensus for moving everything to BitBucket, and I'm all for it. > > I've put this on my own to-do list, but if anyone is looking for a way to > accelerate development, this would be a great contribution (I would suggest > the premake-dev wiki as the place for it: > https://bitbucket.org/premake/premake-dev/wiki/Home > > -st. > > > On Feb 25, 2012, at 1:18 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. > > ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Premake-users mailing list Premake-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/premake-users
