Jeff,
one last thing ...
could you please make sure you (since you have write access to
ompi-release) can assign an issue to me (since i do not have write
access to ompi-release *but* i am part of the open-mpi organization)
/* i think we already validated this on a sandbox, but i would like to
b
Sounds perfect.
On Oct 7, 2014, at 9:49 AM, Gilles Gouaillardet
wrote:
> Jeff,
>
> that should not be an issue since github provides the infrastructure to
> filter bozo requests (requests are sha1 signed with a shared secret)
> https://developer.github.com/webhooks/securing/
>
> Cheers,
>
>
Jeff,
that should not be an issue since github provides the infrastructure to
filter bozo requests (requests are sha1 signed with a shared secret)
https://developer.github.com/webhooks/securing/
Cheers,
Gilles
On Tue, Oct 7, 2014 at 9:46 PM, Jeff Squyres (jsquyres)
wrote:
> On Oct 7, 2014, at
On Oct 7, 2014, at 6:57 AM, Gilles Gouaillardet
wrote:
> so far, using webhooks looks really simple :-)
Good!
> a public web server (apache+php) that can
> a) process json requests
> b) issue curl requests
> is required strictly speaking.
My only request would be to ensure that appropriate se
On Oct 5, 2014, at 10:55 PM, Gilles Gouaillardet
wrote:
> i gave it a little thoughts and that does not seem to hard to achieve.
Great.
> ghi https://github.com/stephencelis/ghi is a cli to manage (among other
> things) labels, milestones and assignee
>
> the elegant way would be to use webho
Jeff,
here is a quick update :
so far, using webhooks looks really simple :-)
a public web server (apache+php) that can
a) process json requests
b) issue curl requests
is required strictly speaking.
i will keep working on a proof of concept
Cheers,
Gilles
On 2014/10/06 11:55, Gilles Gouailla
Jeff,
i gave it a little thoughts and that does not seem to hard to achieve.
ghi https://github.com/stephencelis/ghi is a cli to manage (among other
things) labels, milestones and assignee
the elegant way would be to use webhooks and act accordingly
(short version: github issue a json request ea
On 10/03/2014 01:23 PM, Jeff Squyres (jsquyres) wrote:
On Oct 3, 2014, at 7:11 AM, Gilles Gouaillardet
wrote:
I think you're suggesting "git log | grep SVN rxxx", right?
i do not think this returns the git commit id, does it ?
what i had in mind is :
git log master
and then /r
and manu
will do !
Gilles
"Jeff Squyres (jsquyres)" wrote:
>That's a possibility. IU could probably host this for us.
>
>Would you mind looking into how hard this would be?
>
>
>On Oct 3, 2014, at 8:41 AM, Gilles Gouaillardet
> wrote:
>
>> Jeff,
>>
>> What about a bot using github's rich REST api that
That's a possibility. IU could probably host this for us.
Would you mind looking into how hard this would be?
On Oct 3, 2014, at 8:41 AM, Gilles Gouaillardet
wrote:
> Jeff,
>
> What about a bot using github's rich REST api that parses PR and
> automatically sets label/milestone/assignee wh
Jeff,
What about a bot using github's rich REST api that parses PR and automatically
sets label/milestone/assignee when a keyword is found ?
for example :
PR:milestone=v1.8.4:assignee=jsquyres:label=bug
or
#milestone=v1.8.4 #assignee=@jsquyres #label=bug
i can investigate this way if needed
Ch
Gah.
I just did some experimentation and confirmed this behavior:
1. If you do not belong to a repo, you can file issues/pull requests and
comment on them.
2. If you have *read* access to a repo, you can do everything from #1, but
you're also eligible for @mention auto-complete, and issues/pul
On Oct 3, 2014, at 7:11 AM, Gilles Gouaillardet
wrote:
> > I think you're suggesting "git log | grep SVN rxxx", right?
>
> i do not think this returns the git commit id, does it ?
>
> what i had in mind is :
> git log master
> and then /r
> and manually retrieve the git commit id a few lin
On Fri, Oct 3, 2014 at 7:29 PM, Jeff Squyres (jsquyres)
wrote:
> On Oct 2, 2014, at 11:33 PM, Gilles Gouaillardet <
> gilles.gouaillar...@iferc.org> wrote:
>
> > the most painful part is probably to manually retrieve the git commit id
> > of a given svn commit id
> >
> > git log master, and then
Jeff,
my point is that label, milestone and assignee are *not* clickable for me
(see attached snapshot, "settings" icons are missing
Cheers,
Gilles
On Fri, Oct 3, 2014 at 7:36 PM, Jeff Squyres (jsquyres)
wrote:
> You can only assign a label and milestone, and assign the PR to someone,
> *aft
Ralph --
I lied, sorry.
You can assign the PR to someone (and assign a milestone and labels) *after*
you create it. This is different than Trac where you could set the title,
body, and all those values and *then* create the ticket.
See https://github.com/open-mpi/ompi/wiki/SubmittingBugs for
You can only assign a label and milestone, and assign the PR to someone,
*after* you create the PR (same with creating issues).
See https://github.com/open-mpi/ompi/wiki/SubmittingBugs for details:
[cid:41E9C244-C34D-4E68-89F9-6CE6DFE8B729@cisco.com]
On Oct 2, 2014, at 11:37 PM, Gilles Gouai
On Oct 2, 2014, at 11:33 PM, Gilles Gouaillardet
wrote:
> the most painful part is probably to manually retrieve the git commit id
> of a given svn commit id
>
> git log master, and then search r
> /* each commit log has a line like :
> This commit was SVN rx
> */
I think you're sugges
Jeff,
i could not find how to apply a label to a PR via the web interface (and
i am not sure i can even do that since authority might be required)
any idea (maybe a special keyword in the comment ...) ?
Cheers,
Gilles
On 2014/10/03 1:53, Jeff Squyres (jsquyres) wrote:
> On Oct 2, 2014, at 12:4
Ralph,
what about cherry-pick ?
the most painful part is probably to manually retrieve the git commit id
of a given svn commit id
git log master, and then search r
/* each commit log has a line like :
This commit was SVN rx
*/
and once you got (all) the git commits id of a given CMR, yo
On Oct 2, 2014, at 11:47 AM, Ralph Castain wrote:
>
> On Oct 2, 2014, at 9:43 AM, Jeff Squyres (jsquyres)
> wrote:
>
>> On Oct 2, 2014, at 12:37 PM, Ralph Castain wrote:
>>
>>> Sonow that I've fought thru and created a pull request, I find that I
>>> cannot assign it to anyone for revi
On Oct 2, 2014, at 12:47 PM, Ralph Castain wrote:
> How are they going to review it, given they don't have authority to do
> anything on that branch? Can they still comment? Can they reassign them when
> done?
Yes, they can comment.
The idea was that they would apply the "reviewed" label when
On Oct 2, 2014, at 9:43 AM, Jeff Squyres (jsquyres) wrote:
> On Oct 2, 2014, at 12:37 PM, Ralph Castain wrote:
>
>> Sonow that I've fought thru and created a pull request, I find that I
>> cannot assign it to anyone for review. The only users on the ompi-release
>> branch are myself and
On Oct 2, 2014, at 12:37 PM, Ralph Castain wrote:
> Sonow that I've fought thru and created a pull request, I find that I
> cannot assign it to anyone for review. The only users on the ompi-release
> branch are myself and Jeff (plus the ompiteam admin).
>
> So how do we assign someone to r
On Oct 2, 2014, at 9:37 AM, Jeff Squyres (jsquyres) wrote:
> On Oct 2, 2014, at 12:25 PM, Ralph Castain wrote:
>
>> No. Getting all the right patches (one at a time) from svn is slow,
>> and then it doesn't necessarily apply cleanly, so you go back to svn to
>> figure out what is mis
On Oct 2, 2014, at 12:25 PM, Ralph Castain wrote:
> No. Getting all the right patches (one at a time) from svn is slow,
> and then it doesn't necessarily apply cleanly, so you go back to svn to
> figure out what is missing, get another set of patches (one at a time), try
> again from s
Sonow that I've fought thru and created a pull request, I find that I
cannot assign it to anyone for review. The only users on the ompi-release
branch are myself and Jeff (plus the ompiteam admin).
So how do we assign someone to review it?
On Oct 2, 2014, at 9:25 AM, Ralph Castain wrote:
On Oct 2, 2014, at 9:21 AM, Jeff Squyres (jsquyres) wrote:
> On Oct 2, 2014, at 12:16 PM, Ralph Castain wrote:
>
>> FWIW: I've been trying that and it really, really doesn't work very well -
>> at least, not on the one I'm trying to do. People should expect this to be
>> extremely painful fo
On Oct 2, 2014, at 12:16 PM, Ralph Castain wrote:
> FWIW: I've been trying that and it really, really doesn't work very well - at
> least, not on the one I'm trying to do. People should expect this to be
> extremely painful for the transition.
Yes, I think people will have to be watch out for
On Oct 2, 2014, at 9:14 AM, Jeff Squyres (jsquyres) wrote:
> On Oct 2, 2014, at 11:51 AM, Ralph Castain wrote:
>
>> Do I just download the changeset(s) from Trac and patch them in? I guess
>> that will work if we don't have an alternative method.
>
> Yes, that's what I was planning to do for
On Oct 2, 2014, at 11:51 AM, Ralph Castain wrote:
> Do I just download the changeset(s) from Trac and patch them in? I guess that
> will work if we don't have an alternative method.
Yes, that's what I was planning to do for my CMRs (i.e., generate patches from
SVN and apply them git tree).
Pe
I agree that someone needs to do it. However, what isn't clear is *how* to do
it. I get the mechanics:
* clone the ompi-release 1.8 branch
* apply the required change
* issue a pull request
It's the second step that isn't clear. How the heck do I (a) find the change
that was originally applied,
According to Github, you haven't accepted your invitation yet:
[cid:34B7E99E-FBB8-4B2D-974A-6FAF2CC15E82@cisco.com]
On Oct 2, 2014, at 9:35 AM, Vasily Filipov
mailto:vas...@dev.mellanox.co.il>> wrote:
Hi Jeff,
I didn't get any "OMPI GitHub invite email ", I opened GitHub account
(vasilyMellan
Hi Jeff,
I didn't get any "OMPI GitHub invite email ", I opened GitHub account
(vasilyMellanox) and set a "Watch" state for :
https://github.com/open-mpi/ompi
https://github.com/open-mpi/ompi-release
Am I supposed to do something additional ?
Thank you,
Vasily.
On 02-Oct-14 13:24, Je
Fair enough.
*Someone* needs to re-file those CMRs as pull requests; probably in some cases
it's the reporter, probably in some cases it's the owner. :-)
On Oct 2, 2014, at 6:33 AM, Gilles Gouaillardet
wrote:
> Hi Jeff,
>
> thumbs up for the migration !
>
> the names here are the CMR owne
Hi Jeff,
thumbs up for the migration !
the names here are the CMR owners ('Owned by' field in TRAC)
should it be the duty of the creators ('Reported by' field in TRAC) to
re-create the CMR instead?
/* if not, and from a git log point of view, that means the commiter
will be the reviewer and not
(sorry for the delay in receiving this mail; there was a problem with the devel
mailing list last night, unrelated to the Github migration)
Short version
=
The Github conversion is complete. All OMPI activity is now at Github. Please
read the wiki, particularly the first few pages
37 matches
Mail list logo
