I've been upgrading the host that the auto-tester and bugzilla services run on today.  That has been and continues to be causing issues.  Bugzilla is up, or at least seems to be.  The auto-tester is currently down.  I know what needs to be done to fix it but it's going to take a little more time. Sorry for the disruption, but I decided I was so over due for updates that I'd just get it done, damn the cost. :)  It's costing a bit more down time than I'd hoped for.

I'll have everything back in good shape tonight, hopefully only another hour or two.

More when it's back in the shape where I need to hear about anything that I've overlooked.

Sorry,
Brad
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

I've just put the automated pull merging code into production and visible to everyone.  The rough details:

1) You have to be logged in and using https (should be automatic) -- note the new login link in the upper left corner.  The website is now integrated with github's oauth system and will direct you over there to accept this login.  It requires write credentials because the merge operation is performed as the person who requests the merge.  This is subject to debate.  It's possible to switch to read-only credentials and have all merges done as me, with a merge comment noting who did the commit -- but I prefer it NOT be me but rather be you guys.

2) To request that a pull be merged, head through link on the page with all the pull requests and their status (https://d.puremagic.com/test-results/pulls.ghtml?projectid=1) to the test history link (second column.. the one with the username/branch titled link).  At the top of that page, for anyone (logged in or not) is a new row labeled "Auto Merge" with a yes/no indicator.  If you're logged in you will see a Toggle link.

3) For any request which is already completely tested, it will merge right then and there (though no visual indicator on that page until a few minutes later when the system has detected the completed merge).  For any incompletely tested pull request, once it passes all 10 platforms, it will be merged in.

4) If the pull is updated to a new revision while waiting for a complete set of tests to pass, then the auto-merge state is dropped and must be re-enabled.

Two known issues:

1) the post-login step is always back at the default page rather than where you were when you logged in.

2) anyone who is logged in can toggle it.  Once the pull passes all tests, when it tries to perform the pull, it notices the requester can't and yanks the flag, not performing any merging.  Since someone who could have rightly set it will be mislead that it had been set, that's pretty ugly.

There's every possibility that there's bugs in the system, so please tread carefully and let me know if you see something acting fishy.  Future work will add more integration with github to make it easier to interact with.

Happy merging,
Brad

(yes, I realize those docs, such as they are, really belong within the website.. it's on the list)
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Brad Roberts, el 15 de November a las 00:17 me escribiste:
> I've just put the automated pull merging code into production and visible to everyone.  The rough details:
> 
> 1) You have to be logged in and using https (should be automatic) -- note the new login link in the upper left corner.  The website is now integrated with github's oauth system and will direct you over there to accept this login.  It requires write credentials because the merge operation is performed as the person who requests the merge.  This is subject to debate.  It's possible to switch to read-only credentials and have all merges done as me, with a merge comment noting who did the commit -- but I prefer it NOT be me but rather be you guys.

This is awersome!

What do you think about rebasing instead? I always hated GitHub for using merge, and specially for using --no-ff option, it makes the history unreadable as a graph (duplicating basically each bugfix commit).

The auth issues are the same though, except for the fact that if you don't rebase as the user that triggered the "merge", there is no way to say somebody else did it. But honestly, the "committer" information is so important to the point of completely screwing the repo history with tons of noise?


Anyway, really nice job!

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Every 5 minutes an area of rainforest the size of a foot ball field
Is eliminated
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 15 nov 2013, at 15:17, Leandro Lucarella <luca@llucax.com.ar> wrote:

> This is awersome!
> 
> What do you think about rebasing instead? I always hated GitHub for using merge, and specially for using --no-ff option, it makes the history unreadable as a graph (duplicating basically each bugfix commit).
> 
> The auth issues are the same though, except for the fact that if you don't rebase as the user that triggered the "merge", there is no way to say somebody else did it. But honestly, the "committer" information is so important to the point of completely screwing the repo history with tons of noise?
> 
> 
> Anyway, really nice job!


I completely agree. The default should be a fast forward then there should be an option to select non fast forward next to the merge button.

-- 
/Jacob Carlborg


_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On 11/15/13 6:17 AM, Leandro Lucarella wrote:
> Brad Roberts, el 15 de November a las 00:17 me escribiste:
>> I've just put the automated pull merging code into production and
>> visible to everyone.  The rough details:
>>
>> 1) You have to be logged in and using https (should be automatic) --
>> note the new login link in the upper left corner.  The website is
>> now integrated with github's oauth system and will direct you over
>> there to accept this login.  It requires write credentials because
>> the merge operation is performed as the person who requests the
>> merge.  This is subject to debate.  It's possible to switch to
>> read-only credentials and have all merges done as me, with a merge
>> comment noting who did the commit -- but I prefer it NOT be me but
>> rather be you guys.
>
> This is awersome!
>
> What do you think about rebasing instead? I always hated GitHub for
> using merge, and specially for using --no-ff option, it makes the
> history unreadable as a graph (duplicating basically each bugfix
> commit).

I too prefer rebase + ff merge.  However...

> The auth issues are the same though, except for the fact that if you
> don't rebase as the user that triggered the "merge", there is no way to
> say somebody else did it. But honestly, the "committer" information is
> so important to the point of completely screwing the repo history with
> tons of noise?

The auth issues are NOT the same.  I don't know that the git interface at github participates in the oauth impersonation mechanisms that the github api does.  If the oauth token is possible to use with github's git authentication it could be possible, but it expands the scope of what rights I acquire and use.  I'm not particularly comfortable with the concept of having sufficient rights to alter commits in any way.  The nefarious things that could be done are staggering.

Also, setting aside the auth issues, there's more going on behind the 'perform a merge' api than just the git interaction.  There's also all the hooks and events that are triggered.  I don't want to duplicate all the integration that github already does with bugzilla, closing the pull, updating the history of it, sending all the internal to github notifications, sending mails, etc (there's a ton of hooks, and though we only use a few, ignoring that integration is the wrong direction to head in).

IMHO, the right path here is lobbying for more control over the github merge process.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Jacob Carlborg, el 15 de November a las 18:02 me escribiste:
> On 15 nov 2013, at 15:17, Leandro Lucarella <luca@llucax.com.ar> wrote:
> 
> > This is awersome!
> > 
> > What do you think about rebasing instead? I always hated GitHub for using merge, and specially for using --no-ff option, it makes the history unreadable as a graph (duplicating basically each bugfix commit).
> > 
> > The auth issues are the same though, except for the fact that if you don't rebase as the user that triggered the "merge", there is no way to say somebody else did it. But honestly, the "committer" information is so important to the point of completely screwing the repo history with tons of noise?
> > 
> > 
> > Anyway, really nice job!
> 
> I completely agree. The default should be a fast forward then there should be an option to select non fast forward next to the merge button.

I even talk about taking it further than FF merge, just do a rebase, so you don't have merges at all, unless you are really merging long lived branches or large topic branches.

Just as a reminder, this is why I ended up building a too, to "merge" pull request by rebasing them instead of merging: https://github.com/sociomantic/git-hub


-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Se ha dicho tanto que las apariencias engañan
Por supuesto que engañarán a quien sea tan vulgar como para creerlo
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

2013/11/15 Brad Roberts <braddr@puremagic.com>

> I've just put the automated pull merging code into production and visible to everyone.  The rough details:
>
> 1) You have to be logged in and using https (should be automatic) -- note
> the new login link in the upper left corner.  The website is now integrated
> with github's oauth system and will direct you over there to accept this
> login.  It requires write credentials because the merge operation is
> performed as the person who requests the merge.  This is subject to debate.
>  It's possible to switch to read-only credentials and have all merges done
> as me, with a merge comment noting who did the commit -- but I prefer it
> NOT be me but rather be you guys.
>
> 2) To request that a pull be merged, head through link on the page with
> all the pull requests and their status (https://d.puremagic.com/test-
> results/pulls.ghtml?projectid=1) to the test history link (second
> column.. the one with the username/branch titled link).  At the top of that
> page, for anyone (logged in or not) is a new row labeled "Auto Merge" with
> a yes/no indicator.  If you're logged in you will see a Toggle link.
>
> 3) For any request which is already completely tested, it will merge right then and there (though no visual indicator on that page until a few minutes later when the system has detected the completed merge).  For any incompletely tested pull request, once it passes all 10 platforms, it will be merged in.
>
> 4) If the pull is updated to a new revision while waiting for a complete set of tests to pass, then the auto-merge state is dropped and must be re-enabled.
>
> Two known issues:
>
> 1) the post-login step is always back at the default page rather than where you were when you logged in.
>
> 2) anyone who is logged in can toggle it.  Once the pull passes all tests, when it tries to perform the pull, it notices the requester can't and yanks the flag, not performing any merging.  Since someone who could have rightly set it will be mislead that it had been set, that's pretty ugly.
>
> There's every possibility that there's bugs in the system, so please tread carefully and let me know if you see something acting fishy.  Future work will add more integration with github to make it easier to interact with.
>
> Happy merging,
> Brad
>
> (yes, I realize those docs, such as they are, really belong within the
> website.. it's on the list)
>

Awesome work! Just now I tried to use it, and it works as expected.

Kenji Hara

Brad Roberts, el 15 de November a las 09:45 me escribiste:
> On 11/15/13 6:17 AM, Leandro Lucarella wrote:
> >Brad Roberts, el 15 de November a las 00:17 me escribiste:
> >>I've just put the automated pull merging code into production and visible to everyone.  The rough details:
> >>
> >>1) You have to be logged in and using https (should be automatic) -- note the new login link in the upper left corner.  The website is now integrated with github's oauth system and will direct you over there to accept this login.  It requires write credentials because the merge operation is performed as the person who requests the merge.  This is subject to debate.  It's possible to switch to read-only credentials and have all merges done as me, with a merge comment noting who did the commit -- but I prefer it NOT be me but rather be you guys.
> >
> >This is awersome!
> >
> >What do you think about rebasing instead? I always hated GitHub for using merge, and specially for using --no-ff option, it makes the history unreadable as a graph (duplicating basically each bugfix commit).
> 
> I too prefer rebase + ff merge.  However...
> 
> >The auth issues are the same though, except for the fact that if you don't rebase as the user that triggered the "merge", there is no way to say somebody else did it. But honestly, the "committer" information is so important to the point of completely screwing the repo history with tons of noise?
> 
> The auth issues are NOT the same.  I don't know that the git interface at github participates in the oauth impersonation mechanisms that the github api does.  If the oauth token is possible to use with github's git authentication it could be possible, but it expands the scope of what rights I acquire and use.  I'm not particularly comfortable with the concept of having sufficient rights to alter commits in any way.  The nefarious things that could be done are staggering.

I don't understand this, honestly. Anyone with push rights can alter commits, just amend and push. You can create a new commit impersonating other people, just use their name and e-mail as the author.

> Also, setting aside the auth issues, there's more going on behind the 'perform a merge' api than just the git interaction.  There's also all the hooks and events that are triggered.  I don't want to duplicate all the integration that github already does with bugzilla, closing the pull, updating the history of it, sending all the internal to github notifications, sending mails, etc (there's a ton of hooks, and though we only use a few, ignoring that integration is the wrong direction to head in).

But I understand this point.

> IMHO, the right path here is lobbying for more control over the github merge process.

Yeah, that would be the ideal, but I'm not very hopeful about this...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si ella es el sol, yo soy la luna
Si ella es el mar, soy el desierto
Y estamos en eclipse total
Y estamos en eclipse total
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Jacob Carlborg <doob@me.com> schrieb:
>I completely agree. The default should be a fast forward then there should be an option to select non fast forward next to the merge button.

I don't agree. It's helpful to preserve the information that something was merged, which commits were part of the merge and most importantly a reference to the github issue in the merge request.
Another important point, with merging each commit in master adds a whole feature/fix whereas with rebasing you get all intermediate commits too.
I don't care so much about the tree graph, but the above points are important when searching regressions.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Martin Nowak, el 16 de November a las 13:10 me escribiste:
> Jacob Carlborg <doob@me.com> schrieb:
> >I completely agree. The default should be a fast forward then there should be an option to select non fast forward next to the merge button.
> 
> I don't agree. It's helpful to preserve the information that something was merged, which commits were part of the merge and most importantly a reference to the github issue in the merge request.

Why?

> Another important point, with merging each commit in master adds a whole feature/fix whereas with rebasing you get all intermediate commits too.

What do you mean, you get all the intermediate commits in both cases.

> I don't care so much about the tree graph, but the above points are important when searching regressions.

Why? When searching regressions you need to bisect.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
PITUFO ENRIQUE ATEMORIZA CATAMARCA, AMPLIAREMOS
	-- Crónica TV
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals