xenbits GitHub mirror?

xenbits GitHub mirror?

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 529 bytes --]

All,

Now I'll start off by saying that "no" is a perfectly acceptable answer
to this suggestion. Basically I remember at the Xen Developer Summit a
few people mentioned it being nice if people provided a git tree where
their branches were available for testing. I was just thinking it might
be easier for third parties to do that if there was an official Xen
Project mirror of the main repos on xenbits on GitHub and people could
fork that repo and make their branch available. Just a thought.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xenbits GitHub mirror?

[George Dunlap]

On Sat, Dec 19, 2015 at 8:51 PM, Doug Goldstein <cardoe@cardoe.com> wrote:
> All,
>
> Now I'll start off by saying that "no" is a perfectly acceptable answer
> to this suggestion. Basically I remember at the Xen Developer Summit a
> few people mentioned it being nice if people provided a git tree where
> their branches were available for testing. I was just thinking it might
> be easier for third parties to do that if there was an official Xen
> Project mirror of the main repos on xenbits on GitHub and people could
> fork that repo and make their branch available. Just a thought.

So I don't think there would be any objection at all to individual
contributors sending links to git repos that happened to be hosted on
github in the cover letter of a patch series posted to xen-devel.

I also don't think there would be any objection to someone
*unofficially* maintaining a xenbits mirror on github, and advertising
its availability on the wiki, as long as it was clear that it was
unofficial.

I'll let someone who feels more strongly than I do comment on the
ideological perspective of having an official mirror; but from a
practical perspective, my concern would be dealing with people who
clone it and then send pull requests.  I'm pretty sure we will never
accept pull requests made via github, and as a policy we will
therefore never look at pull requests.  Having dozens of open,
un-answered pull requests on github will look bad for the project; and
manually going through and rejecting every pull request with an
explanation of why seems like a pain that I'd rather avoid if we can
help it.

 -George

Re: xenbits GitHub mirror?

[Jon Ludlam]

On Mon, Dec 21, 2015 at 11:54:52AM +0000, George Dunlap wrote:
> On Sat, Dec 19, 2015 at 8:51 PM, Doug Goldstein <cardoe@cardoe.com> wrote:
> > All,
> >
> > Now I'll start off by saying that "no" is a perfectly acceptable answer
> > to this suggestion. Basically I remember at the Xen Developer Summit a
> > few people mentioned it being nice if people provided a git tree where
> > their branches were available for testing. I was just thinking it might
> > be easier for third parties to do that if there was an official Xen
> > Project mirror of the main repos on xenbits on GitHub and people could
> > fork that repo and make their branch available. Just a thought.
> 
> So I don't think there would be any objection at all to individual
> contributors sending links to git repos that happened to be hosted on
> github in the cover letter of a patch series posted to xen-devel.
> 
> I also don't think there would be any objection to someone
> *unofficially* maintaining a xenbits mirror on github, and advertising
> its availability on the wiki, as long as it was clear that it was
> unofficial.
>

There's an unofficial mirror maintained by the Mirage team on the
under the mirage organization: https://github.com/mirage/xen

Jon

> I'll let someone who feels more strongly than I do comment on the
> ideological perspective of having an official mirror; but from a
> practical perspective, my concern would be dealing with people who
> clone it and then send pull requests.  I'm pretty sure we will never
> accept pull requests made via github, and as a policy we will
> therefore never look at pull requests.  Having dozens of open,
> un-answered pull requests on github will look bad for the project; and
> manually going through and rejecting every pull request with an
> explanation of why seems like a pain that I'd rather avoid if we can
> help it.
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: xenbits GitHub mirror?

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 1374 bytes --]

On 12/23/15 2:53 AM, Jon Ludlam wrote:
> On Mon, Dec 21, 2015 at 11:54:52AM +0000, George Dunlap wrote:
>> On Sat, Dec 19, 2015 at 8:51 PM, Doug Goldstein <cardoe@cardoe.com> wrote:
>>> All,
>>>
>>> Now I'll start off by saying that "no" is a perfectly acceptable answer
>>> to this suggestion. Basically I remember at the Xen Developer Summit a
>>> few people mentioned it being nice if people provided a git tree where
>>> their branches were available for testing. I was just thinking it might
>>> be easier for third parties to do that if there was an official Xen
>>> Project mirror of the main repos on xenbits on GitHub and people could
>>> fork that repo and make their branch available. Just a thought.
>>
>> So I don't think there would be any objection at all to individual
>> contributors sending links to git repos that happened to be hosted on
>> github in the cover letter of a patch series posted to xen-devel.
>>
>> I also don't think there would be any objection to someone
>> *unofficially* maintaining a xenbits mirror on github, and advertising
>> its availability on the wiki, as long as it was clear that it was
>> unofficial.
>>
> 
> There's an unofficial mirror maintained by the Mirage team on the
> under the mirage organization: https://github.com/mirage/xen
> 
> Jon

How often do you sync?

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xenbits GitHub mirror?

[Ian Campbell]

On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
> All,
> 
> Now I'll start off by saying that "no" is a perfectly acceptable answer
> to this suggestion. Basically I remember at the Xen Developer Summit a
> few people mentioned it being nice if people provided a git tree where
> their branches were available for testing. I was just thinking it might
> be easier for third parties to do that if there was an official Xen
> Project mirror of the main repos on xenbits on GitHub and people could
> fork that repo and make their branch available. Just a thought.

If forking the repo significantly easier than just creating an empty one of
your own and pushing to it? Is the parent repo "important" in some way in
the GH world? (Given that, as George says, we are unlikely to accept
contributions via GH pull requests etc).

Ian.

Re: xenbits GitHub mirror?

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 1867 bytes --]

On 1/26/16 10:55 AM, Ian Campbell wrote:
> On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
>> All,
>>
>> Now I'll start off by saying that "no" is a perfectly acceptable answer
>> to this suggestion. Basically I remember at the Xen Developer Summit a
>> few people mentioned it being nice if people provided a git tree where
>> their branches were available for testing. I was just thinking it might
>> be easier for third parties to do that if there was an official Xen
>> Project mirror of the main repos on xenbits on GitHub and people could
>> fork that repo and make their branch available. Just a thought.
> 
> If forking the repo significantly easier than just creating an empty one of
> your own and pushing to it? Is the parent repo "important" in some way in
> the GH world? (Given that, as George says, we are unlikely to accept
> contributions via GH pull requests etc).
> 
> Ian.
> 

Its not easier or different. I just remembered from the Xen Developer
Summit that a few people complained that a lot of the patch series
posted to the ML really should be available as a repo because they were
quite large and hard to review. I see this comment come up over and over
on the ML myself as well so I was just trying to lower the barriers to
people doing that. I know the reason people don't isn't technical so
this isn't really a technical solution but I figured this is more a
social thing. GitHub has the ability to mark a repo as a mirror and not
allow pull requests or issues, which is what I would recommend. I'm just
looking at improving the community aspect. I could create an
organization called "xen-mirror" and get it setup and turn it over to
the Xen Project.

Again, I'm fine with an answer of "no" here. Just trying to pitch out
ideas to solve what some see as an irritation.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xenbits GitHub mirror?

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 2716 bytes --]

On 1/26/16 11:26 AM, Doug Goldstein wrote:
> On 1/26/16 10:55 AM, Ian Campbell wrote:
>> On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
>>> All,
>>>
>>> Now I'll start off by saying that "no" is a perfectly acceptable answer
>>> to this suggestion. Basically I remember at the Xen Developer Summit a
>>> few people mentioned it being nice if people provided a git tree where
>>> their branches were available for testing. I was just thinking it might
>>> be easier for third parties to do that if there was an official Xen
>>> Project mirror of the main repos on xenbits on GitHub and people could
>>> fork that repo and make their branch available. Just a thought.
>>
>> If forking the repo significantly easier than just creating an empty one of
>> your own and pushing to it? Is the parent repo "important" in some way in
>> the GH world? (Given that, as George says, we are unlikely to accept
>> contributions via GH pull requests etc).
>>
>> Ian.
>>
> 
> Its not easier or different. I just remembered from the Xen Developer
> Summit that a few people complained that a lot of the patch series
> posted to the ML really should be available as a repo because they were
> quite large and hard to review. I see this comment come up over and over
> on the ML myself as well so I was just trying to lower the barriers to
> people doing that. I know the reason people don't isn't technical so
> this isn't really a technical solution but I figured this is more a
> social thing. GitHub has the ability to mark a repo as a mirror and not
> allow pull requests or issues, which is what I would recommend. I'm just
> looking at improving the community aspect. I could create an
> organization called "xen-mirror" and get it setup and turn it over to
> the Xen Project.
> 
> Again, I'm fine with an answer of "no" here. Just trying to pitch out
> ideas to solve what some see as an irritation.
> 

Another thing to toss out there and again people can say "no". But I
slapped together a simple "build" test using Travis CI that's publicly
visible. Currently I can't build the tools because of some issues *.

I know we have osstest but I figured this could be a simple build test
of each commit to each branch. Interestingly just doing a quick test
shows that builds fail currently with clang [1].

* The VM based approach fails to find a python it can link to. The
container based approach fails due to some dependencies not being white
listed by Travis [2] [3].

[1] https://travis-ci.org/cardoe/xen
[2] https://github.com/travis-ci/apt-package-whitelist/issues/2320
[3] https://github.com/travis-ci/apt-package-whitelist/issues/2321
-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xenbits GitHub mirror?

[George Dunlap]

On Tue, Jan 26, 2016 at 5:26 PM, Doug Goldstein <cardoe@cardoe.com> wrote:
>> If forking the repo significantly easier than just creating an empty one of
>> your own and pushing to it? Is the parent repo "important" in some way in
>> the GH world? (Given that, as George says, we are unlikely to accept
>> contributions via GH pull requests etc).
>>
>> Ian.
>>
>
> Its not easier or different. I just remembered from the Xen Developer
> Summit that a few people complained that a lot of the patch series
> posted to the ML really should be available as a repo because they were
> quite large and hard to review. I see this comment come up over and over
> on the ML myself as well so I was just trying to lower the barriers to
> people doing that. I know the reason people don't isn't technical so
> this isn't really a technical solution but I figured this is more a
> social thing. GitHub has the ability to mark a repo as a mirror and not
> allow pull requests or issues, which is what I would recommend. I'm just
> looking at improving the community aspect. I could create an
> organization called "xen-mirror" and get it setup and turn it over to
> the Xen Project.

If the problem you see is that most contributors are not posting links
to git branches, I don't think having a github mirror is going to help
in any way -- particularly if you don't actually tell people that's
what you'd like. :-)

Regular contributors are eligible to have accounts on xenbits where
they can upload branches of patch series, and many do.  I do it for
particularly long or complicated patch series (or in the case that one
patch is massive and uninteresting, like removing an entire
directory); the reason I don't do it for *every* patch series though
is that it's an extra step that has to be coordinated properly.

Ian, how hard would it be to modify your xenbugs daemon to make
another webpage containing git am's of series, with the 0/N in the
title?

 -George

Re: xenbits GitHub mirror?

[Ian Campbell]

On Wed, 2016-01-27 at 09:34 +0000, George Dunlap wrote:
> Ian, how hard would it be to modify your xenbugs daemon to make
> another webpage containing git am's of series, with the 0/N in the
> title?

Someone would need to clone https://git.hellion.org.uk/?p=emesinae.git;a=su
mmary and make contrib/thread-to-mbox.pl into something which could be
deployed to CGI to get an individual thread (either formatted or as a raw
mbox).

If you wanted an index page of all the series then that would be more work
from scratch, but not outside the realms of possibility.

Both are probably not a great deal of effort, but not something I have time
for in the foreseeable future.

Individual raw messages (suitable for git am) are already available at http
://bugs.xenproject.org/xen/mid/<msgid>/raw .

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xenbits GitHub mirror?

[Ian Campbell]

On Tue, 2016-01-26 at 11:26 -0600, Doug Goldstein wrote:
> On 1/26/16 10:55 AM, Ian Campbell wrote:
> > On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
> > > All,
> > > 
> > > Now I'll start off by saying that "no" is a perfectly acceptable answer
> > > to this suggestion. Basically I remember at the Xen Developer Summit a
> > > few people mentioned it being nice if people provided a git tree where
> > > their branches were available for testing. I was just thinking it might
> > > be easier for third parties to do that if there was an official Xen
> > > Project mirror of the main repos on xenbits on GitHub and people could
> > > fork that repo and make their branch available. Just a thought.
> > 
> > If forking the repo significantly easier than just creating an empty one of
> > your own and pushing to it? Is the parent repo "important" in some way in
> > the GH world? (Given that, as George says, we are unlikely to accept
> > contributions via GH pull requests etc).
> > 
> > Ian.
> > 
> 
> Its not easier or different. I just remembered from the Xen Developer
> Summit that a few people complained that a lot of the patch series
> posted to the ML really should be available as a repo because they were
> quite large and hard to review. I see this comment come up over and over
> on the ML myself as well so I was just trying to lower the barriers to
> people doing that. I know the reason people don't isn't technical so
> this isn't really a technical solution but I figured this is more a
> social thing. GitHub has the ability to mark a repo as a mirror and not
> allow pull requests or issues, which is what I would recommend. I'm just
> looking at improving the community aspect. I could create an
> organization called "xen-mirror" and get it setup and turn it over to
> the Xen Project.
> 
> Again, I'm fine with an answer of "no" here. Just trying to pitch out
> ideas to solve what some see as an irritation.

I don't think you need anybodies permission to do this if you think it will
be valuable.

Ian.

Re: xenbits GitHub mirror?

[Andrew Cooper]

On 27/01/16 09:45, Ian Campbell wrote:
> On Tue, 2016-01-26 at 11:26 -0600, Doug Goldstein wrote:
>> On 1/26/16 10:55 AM, Ian Campbell wrote:
>>> On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
>>>> All,
>>>>
>>>> Now I'll start off by saying that "no" is a perfectly acceptable answer
>>>> to this suggestion. Basically I remember at the Xen Developer Summit a
>>>> few people mentioned it being nice if people provided a git tree where
>>>> their branches were available for testing. I was just thinking it might
>>>> be easier for third parties to do that if there was an official Xen
>>>> Project mirror of the main repos on xenbits on GitHub and people could
>>>> fork that repo and make their branch available. Just a thought.
>>> If forking the repo significantly easier than just creating an empty one of
>>> your own and pushing to it? Is the parent repo "important" in some way in
>>> the GH world? (Given that, as George says, we are unlikely to accept
>>> contributions via GH pull requests etc).
>>>
>>> Ian.
>>>
>> Its not easier or different. I just remembered from the Xen Developer
>> Summit that a few people complained that a lot of the patch series
>> posted to the ML really should be available as a repo because they were
>> quite large and hard to review. I see this comment come up over and over
>> on the ML myself as well so I was just trying to lower the barriers to
>> people doing that. I know the reason people don't isn't technical so
>> this isn't really a technical solution but I figured this is more a
>> social thing. GitHub has the ability to mark a repo as a mirror and not
>> allow pull requests or issues, which is what I would recommend. I'm just
>> looking at improving the community aspect. I could create an
>> organization called "xen-mirror" and get it setup and turn it over to
>> the Xen Project.
>>
>> Again, I'm fine with an answer of "no" here. Just trying to pitch out
>> ideas to solve what some see as an irritation.
> I don't think you need anybodies permission to do this if you think it will
> be valuable.

If there is going to be an official github mirror, then it should be
part of github.com/xen-project rather than hosted by a random developer.

FWIW, I am +1 for setting up infrastructure like this, but lets do it
properly.

Lars: Thoughts?

~Andrew

Re: xenbits GitHub mirror?

[George Dunlap]

On Wed, Jan 27, 2016 at 10:55 AM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 27/01/16 09:45, Ian Campbell wrote:
>> On Tue, 2016-01-26 at 11:26 -0600, Doug Goldstein wrote:
>>> On 1/26/16 10:55 AM, Ian Campbell wrote:
>>>> On Sat, 2015-12-19 at 14:51 -0600, Doug Goldstein wrote:
>>>>> All,
>>>>>
>>>>> Now I'll start off by saying that "no" is a perfectly acceptable answer
>>>>> to this suggestion. Basically I remember at the Xen Developer Summit a
>>>>> few people mentioned it being nice if people provided a git tree where
>>>>> their branches were available for testing. I was just thinking it might
>>>>> be easier for third parties to do that if there was an official Xen
>>>>> Project mirror of the main repos on xenbits on GitHub and people could
>>>>> fork that repo and make their branch available. Just a thought.
>>>> If forking the repo significantly easier than just creating an empty one of
>>>> your own and pushing to it? Is the parent repo "important" in some way in
>>>> the GH world? (Given that, as George says, we are unlikely to accept
>>>> contributions via GH pull requests etc).
>>>>
>>>> Ian.
>>>>
>>> Its not easier or different. I just remembered from the Xen Developer
>>> Summit that a few people complained that a lot of the patch series
>>> posted to the ML really should be available as a repo because they were
>>> quite large and hard to review. I see this comment come up over and over
>>> on the ML myself as well so I was just trying to lower the barriers to
>>> people doing that. I know the reason people don't isn't technical so
>>> this isn't really a technical solution but I figured this is more a
>>> social thing. GitHub has the ability to mark a repo as a mirror and not
>>> allow pull requests or issues, which is what I would recommend. I'm just
>>> looking at improving the community aspect. I could create an
>>> organization called "xen-mirror" and get it setup and turn it over to
>>> the Xen Project.
>>>
>>> Again, I'm fine with an answer of "no" here. Just trying to pitch out
>>> ideas to solve what some see as an irritation.
>> I don't think you need anybodies permission to do this if you think it will
>> be valuable.
>
> If there is going to be an official github mirror, then it should be
> part of github.com/xen-project rather than hosted by a random developer.

Just to be clear, I think Ian was suggesting that Doug could make an
unofficial mirror (as the mirage guys have done).

> FWIW, I am +1 for setting up infrastructure like this, but lets do it
> properly.
>
> Lars: Thoughts?

Doug says that you can mark a repo as a 'mirror', which will prevent
people from being able to send pull requests to it; so I think my
technical objection has been answered.

I think the idea is still only half-baked though, as I'm not sure how
having a github mirror will make it so that most mail has a git repo
you can pull from (which would be necessary to reach the ultimate
goal, making it straightforward to apply patches sent to the list).

 -George

Re: xenbits GitHub mirror?

[Lars Kurth]

Sorry, I have been a little bit unresponsive. Things were a little hectic
in the last 2 weeks.


On 27/01/2016 11:21, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:

>
>> FWIW, I am +1 for setting up infrastructure like this, but lets do it
>> properly.
>>
>> Lars: Thoughts?

I don't mind if we had an official github mirror. In fact, it may make the
project a little bit more accessible to the younger crowd.
 

>Doug says that you can mark a repo as a 'mirror', which will prevent
>people from being able to send pull requests to it; so I think my
>technical objection has been answered.
>
>I think the idea is still only half-baked though, as I'm not sure how
>having a github mirror will make it so that most mail has a git repo
>you can pull from (which would be necessary to reach the ultimate
>goal, making it straightforward to apply patches sent to the list).


I would be good, if we could identify any workflow issues (e.g. such as
the mailing issue raised here). Maybe some of the people who have hands-on
experience with Github and mailing lists can make a few suggestions. We
then should also consider adding this to the How to submit patches wiki
page

Lars

Re: xenbits GitHub mirror?

[Ian Campbell]

On Wed, 2016-01-27 at 15:18 +0000, Lars Kurth wrote:
> > Doug says that you can mark a repo as a 'mirror', which will prevent
> > people from being able to send pull requests to it; so I think my
> > technical objection has been answered.
> > 
> > I think the idea is still only half-baked though, as I'm not sure how
> > having a github mirror will make it so that most mail has a git repo
> > you can pull from (which would be necessary to reach the ultimate
> > goal, making it straightforward to apply patches sent to the list).
> 
> 
> I would be good, if we could identify any workflow issues (e.g. such as
> the mailing issue raised here). Maybe some of the people who have hands-on
> experience with Github and mailing lists can make a few suggestions. We
> then should also consider adding this to the How to submit patches wiki
> page

I don't think we want to encourage this for all submissions, nor dive too
deeply into the workflows (given that Doug says we can disable GH PRs for
the repo).

All Doug is trying to address is for the (infrequent) occasions when a
series is particularly big and complicated to be able to say "please stick
this in a git tree to ease review, oh and by the way if you need git
hosting you could fork $this repo on github or $that repo on gitlab".

For most patch series setting up a GH account and pushing the changes to it
etc is pure overhead (or at least optional), there is no need to encourage
it for most series, nor even necessarily to encourage people to proactively
push to a repo, we can always ask if we find the series to hard to review
as patches.

Ian.

Re: xenbits GitHub mirror?

[George Dunlap]

On 27/01/16 15:45, Ian Campbell wrote:
> On Wed, 2016-01-27 at 15:18 +0000, Lars Kurth wrote:
>>> Doug says that you can mark a repo as a 'mirror', which will prevent
>>> people from being able to send pull requests to it; so I think my
>>> technical objection has been answered.
>>>
>>> I think the idea is still only half-baked though, as I'm not sure how
>>> having a github mirror will make it so that most mail has a git repo
>>> you can pull from (which would be necessary to reach the ultimate
>>> goal, making it straightforward to apply patches sent to the list).
>>
>>
>> I would be good, if we could identify any workflow issues (e.g. such as
>> the mailing issue raised here). Maybe some of the people who have hands-on
>> experience with Github and mailing lists can make a few suggestions. We
>> then should also consider adding this to the How to submit patches wiki
>> page
> 
> I don't think we want to encourage this for all submissions, nor dive too
> deeply into the workflows (given that Doug says we can disable GH PRs for
> the repo).
> 
> All Doug is trying to address is for the (infrequent) occasions when a
> series is particularly big and complicated to be able to say "please stick
> this in a git tree to ease review, oh and by the way if you need git
> hosting you could fork $this repo on github or $that repo on gitlab".

Right -- I see how this could help contributors contribute in a useful
fashion.

> For most patch series setting up a GH account and pushing the changes to it
> etc is pure overhead (or at least optional), there is no need to encourage
> it for most series, nor even necessarily to encourage people to proactively
> push to a repo, we can always ask if we find the series to hard to review
> as patches.

It did take me a while to find a system that made it not a pain to apply
patch series from xen-devel, and the solution I have now is very
particular to the combination of e-mail tools that I happen to use; I'm
not sure how transferrable they are.

So while I've managed to get things to a point where I don't have much
pain, it's probably something that could use some work as a project in
general.  "Encouraging most people to include public git branches" is
one option to help that; "Having a mail bot that gave you git-am'able
mbox files" is another.

 -George

Re: xenbits GitHub mirror?

[Ian Campbell]

On Wed, 2016-01-27 at 16:01 +0000, George Dunlap wrote:
> On 27/01/16 15:45, Ian Campbell wrote:
> > For most patch series setting up a GH account and pushing the changes to it
> > etc is pure overhead (or at least optional), there is no need to encourage
> > it for most series, nor even necessarily to encourage people to proactively
> > push to a repo, we can always ask if we find the series to hard to review
> > as patches.
> 
> It did take me a while to find a system that made it not a pain to apply
> patch series from xen-devel, and the solution I have now is very
> particular to the combination of e-mail tools that I happen to use; I'm
> not sure how transferrable they are.

I use the script below, which apart from needing a way to see the message
id of mails is independent of any mail tools. For git send-email generated
series I use it as:

    ~/get-msgid -g '2 5' '    <    1447415999-22003-1-git-send-email-olaf@aepfle.de    >    ' | git am

(where 2 and 5 come come from the message id of the first and last patch
mails and it will apply the whole range, note that git send-email often has
patch #1 with msgid=2 due to the cover letter)

> So while I've managed to get things to a point where I don't have much
> pain, it's probably something that could use some work as a project in
> general.  "Encouraging most people to include public git branches" is
> one option to help that; "Having a mail bot that gave you git-am'able
> mbox files" is another.

Sure, but none of that is a blocker for what Doug is actually asking for
feedback on here, which really doesn't need to go off into the weeds
regarding some other future workflow which it may or may not enable, in
order to make a decision.

Ian.

#!/bin/bash

help()
{
    echo "help!" 1>&2
}

GIT=
while getopts g: OPT ; do
        case $OPT in
            g)  GIT="$OPTARG" ;;
            h)  help ; exit 1 ;;
            \?) exit 1 ;;
        esac
done
shift $(expr $OPTIND - 1)

fetch_messages()
{
    for i in $@ ; do
        echo "Fetching Message ID $i" 1>&2
        if [ -n "$X" ] ; then
            ssh celaeno cat /srv/mldrop/xen-devel/"\"$i\""
        else
            #wget -O - -q http://bugs.xenproject.org/xen/mid/"$i"/raw
            i=${i/\+/%2B}
            curl --silent http://bugs.xenproject.org/xen/mid/"$i"/raw
        fi
    done
}

if [ -z "$GIT" ] ; then
    fetch_messages $@
else
    #<1349427871-31195-4-git-send-email-anthony.perard@citrix.com>
    for i in $@ ; do
        PATTERN=$(echo "$i" | sed -e 's/^\(<[0-9]*-[0-9]*-\)[0-9]*\(-.*>\)/\1@@NR@@\2/g')
        echo "GIT pattern $PATTERN" 1>&2
        for n in $(seq $GIT) ; do
            MSG=$(echo "$PATTERN" | sed -e "s/@@NR@@/$n/")
            fetch_messages $MSG
        done
    done
fi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: xenbits GitHub mirror?

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 2062 bytes --]

On 1/27/16 9:18 AM, Lars Kurth wrote:
> 
> Sorry, I have been a little bit unresponsive. Things were a little hectic
> in the last 2 weeks.
> 
> 
> On 27/01/2016 11:21, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:
> 
>>
>>> FWIW, I am +1 for setting up infrastructure like this, but lets do it
>>> properly.
>>>
>>> Lars: Thoughts?
> 
> I don't mind if we had an official github mirror. In fact, it may make the
> project a little bit more accessible to the younger crowd.
>  
> 
>> Doug says that you can mark a repo as a 'mirror', which will prevent
>> people from being able to send pull requests to it; so I think my
>> technical objection has been answered.
>>
>> I think the idea is still only half-baked though, as I'm not sure how
>> having a github mirror will make it so that most mail has a git repo
>> you can pull from (which would be necessary to reach the ultimate
>> goal, making it straightforward to apply patches sent to the list).
> 
> 
> I would be good, if we could identify any workflow issues (e.g. such as
> the mailing issue raised here). Maybe some of the people who have hands-on
> experience with Github and mailing lists can make a few suggestions. We
> then should also consider adding this to the How to submit patches wiki
> page
> 
> Lars
> 

I've gone ahead and created https://github.com/xen-project/xen I've also
reached out to GitHub to make it an "official" mirror. I can have GitHub
setup a periodic pull from the repo (this might take some time) or we
can add a post-receive hook that pushes to that repo.(git push --mirror)

I've also reached out to Lars off list to turn over the 'xen-project'
organization over to him.

As an aside I know we've got osstest but I've like to utilize the free
service from Travis CI to run simple compile tests on each commit. This
could potentially be wired into osstest as well. (In my organization we
use Travis CI for simple tests on commits and when those pass we kick
off our more in depth tests).

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel