premake-users

[Premake-users] Are pull requests accepted?

[Jason M. <jmc...@gm...>]

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.

[Premake-users] Are pull requests accepted?

[Jason M. <ko...@gm...>]

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.

Re: [Premake-users] Are pull requests accepted?

[Jason P. <st...@in...>]

Sorry, you're right, I didn't answer that part—yes, pull requests are great.


On Feb 25, 2012, at 3:05 PM, Jason McKesson wrote:

> I just want to know if pull requests are an acceptable way to hand you code at all. It's not a question of "do you accept pull requests *quickly*." I just want to know if patches are the only way to provide code fixes.
> 
> On 2/25/2012 12:00 PM, Jason Perkins wrote:
>> 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.
>> 
>> Thanks for the contribution!
>> 
>> Jason
>> 
>> 
>> 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.
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> 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
>>> Pre...@li...
>>> https://lists.sourceforge.net/lists/listinfo/premake-users
>> 
> 

Re: [Premake-users] Are pull requests accepted?

[Konstantin T. <an...@ya...>]

25.02.2012, 22:18, "Jason McKesson" <ko...@gm...>:
> 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. 

I don't agree. Forking could be used just to simplify workflow, e.g. you
can create your feature branches, work on them, using BitBucket server
for synchronization.

> Rather than "patches", which are unversioned
> single-revisions

I'm pretty sure that hg has something like "git format-patch"

> which, once incorporated into the repo, would conflict
> with the changes that the person just made

Presence of conflict does not depend on the way of patch transfer.
If path is not up-to-date with target branch, it should be rebased, either
by author or by maintainer.

>, 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.

This info is not that useful. Useful is end result, i.e. "1 patch (commit)"
== "1 ready to use feature". When using git, I use "git rebase -i" to squash
commits before contributing my work somewhere - one patch is usually much
easier to review.


-- 
Regards,
Konstantin

Re: [Premake-users] Are pull requests accepted?

[Jason P. <st...@in...>]

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.

Re: [Premake-users] Are pull requests accepted?

[Jason M. <ko...@gm...>]

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.
>
>

Re: [Premake-users] Are pull requests accepted?

[Jason P. <st...@in...>]

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.