From rdmurray at bitdance.com  Tue Aug  2 10:24:16 2016
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 02 Aug 2016 10:24:16 -0400
Subject: [core-workflow] GitHub reviews comments on b.p.o
In-Reply-To: <CALC2N4aUynX=P3XrVShz90Wc23QT0oaZ3mzA5TQnEJN4EuKEBg@mail.gmail.com>
References: <CAOqj4aW06O3JEuzVTAYQgD5Xo9+RrseAd4iabNCNZTfyyTLfFQ@mail.gmail.com>
 <CAPOVWOSeKNSSiw+xwHKiDfvaLD+JAh0QJCp+iwH12e6yPJGRxw@mail.gmail.com>
 <20160727215716.738FCB14027@webabinitio.net>
 <CAPOVWOSJFwbitRKSSs+uD9VFdfk6yBaZeVEqjxDn8xMr9ujZRw@mail.gmail.com>
 <20160728144857.DB1ACB14027@webabinitio.net>
 <CAPOVWOSgmdsOB74GQ-kgii0ZeXhf2gFSc91C6Fa3XTwZ6X4E=A@mail.gmail.com>
 <83a9e1d3-0de6-f8ef-6c95-7129ab1d6dcc@gmail.com>
 <CAP1=2W7tSo_rMqBV8BtGeQiB5XZPdjn-JbJ9djEu5eBUMRKg0g@mail.gmail.com>
 <CALC2N4aUynX=P3XrVShz90Wc23QT0oaZ3mzA5TQnEJN4EuKEBg@mail.gmail.com>
Message-ID: <20160802142417.E24EEB14023@webabinitio.net>

On Sat, 30 Jul 2016 23:21:07 +0200, Maciej Szulik <soltysh at gmail.com> wrote:
> I'm leaning towards just adding an information who left the comment
> and a link to the PR. I agree with Senthil that gh comments,
> especially those coming from reviews have code context, which will get
> lost when copying over. Besides the amount does not matter in that
> case, whoever is interested in looking or answering into the patch
> will have to go to GitHub and see what exactly it's about. I'm aware
> there are cases you just want to read the comment and don't do
> anything yet, but these are rare cases we can initially ignore. Let's
> start simple and we can always get back to this topic.

If github comment threading were more sensible I think I'd prefer to see
the comments reflected.  But since it *isn't* (it is pretty much useless
outside of the web UI, and even in the web UI it is often awkward),
I think linking to the PR is indeed probably better.

Just to confirm, we are talking about a new link summarizing the comment
activity for the past N minutes, whenever commenting activity happens,
right?  It would be nice to link directly to the new comments, but somehow
I doubt that is going to be possible (at least if we batch them), so we'll
probably have to settle for just linking the summary to the PR as a whole.

--David

From alexander.belopolsky at gmail.com  Fri Aug  5 11:19:33 2016
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 5 Aug 2016 11:19:33 -0400
Subject: [core-workflow] Choosing a CI service
Message-ID: <CAP7h-xbzbkbUSH=T4L_J-3g8_PzBB9_qgp+VyOrjAa8WT56LZg@mail.gmail.com>

I have recently set up several CI services in my cpython fork on
Github: <https://github.com/abalkin/cpython/tree/ci>.

I am not ready to make any recommendations, but feel free to click on
the build badges at the top of the README file and see the results for
yourself.  I activated the following services:

* Travis CI
* CodeCov
* CodeShip
* AppVeyor  (windows)

From rymg19 at gmail.com  Fri Aug  5 16:39:13 2016
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Fri, 5 Aug 2016 15:39:13 -0500
Subject: [core-workflow] Choosing a CI service
In-Reply-To: <CAP7h-xbzbkbUSH=T4L_J-3g8_PzBB9_qgp+VyOrjAa8WT56LZg@mail.gmail.com>
References: <CAP7h-xbzbkbUSH=T4L_J-3g8_PzBB9_qgp+VyOrjAa8WT56LZg@mail.gmail.com>
Message-ID: <CAO41-mO3NuPscJooMp5UY2pemvGJiyapANs=KSyZ0-_LVebLoQ@mail.gmail.com>

FWIW, you said they're "CI services":

- CodeCov isn't actually a CI.
- AFAIK CodeShip doesn't work on Windows, so, for Windows CI, there isn't
really a choice *other* than AppVeyor.
- CodeShip seems to require an account just to view the build status.
- They're all failing. :(

On Fri, Aug 5, 2016 at 10:19 AM, Alexander Belopolsky <
alexander.belopolsky at gmail.com> wrote:

> I have recently set up several CI services in my cpython fork on
> Github: <https://github.com/abalkin/cpython/tree/ci>.
>
> I am not ready to make any recommendations, but feel free to click on
> the build badges at the top of the README file and see the results for
> yourself.  I activated the following services:
>
> * Travis CI
> * CodeCov
> * CodeShip
> * AppVeyor  (windows)
> _______________________________________________
> core-workflow mailing list
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
>



-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something?s wrong.
http://kirbyfan64.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160805/31f43089/attachment.html>

From alexander.belopolsky at gmail.com  Fri Aug  5 17:51:58 2016
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 5 Aug 2016 17:51:58 -0400
Subject: [core-workflow] Choosing a CI service
In-Reply-To: <CAO41-mO3NuPscJooMp5UY2pemvGJiyapANs=KSyZ0-_LVebLoQ@mail.gmail.com>
References: <CAP7h-xbzbkbUSH=T4L_J-3g8_PzBB9_qgp+VyOrjAa8WT56LZg@mail.gmail.com>
 <CAO41-mO3NuPscJooMp5UY2pemvGJiyapANs=KSyZ0-_LVebLoQ@mail.gmail.com>
Message-ID: <CAP7h-xZrTXqrxqxxTpgxaDagbJaNG+S-cDjJv-X3m0x2w8uoQA@mail.gmail.com>

On Fri, Aug 5, 2016 at 4:39 PM, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> FWIW, you said they're "CI services":
>
> - CodeCov isn't actually a CI.

It is a "service." It is related to CI.  It's not s stretch to call it
a "CI service."  It is a component that can be added to most CI
providers.

> - AFAIK CodeShip doesn't work on Windows, so, for Windows CI, there isn't
> really a choice other than AppVeyor.

I think you are right.

> - CodeShip seems to require an account just to view the build status.
> - They're all failing. :(

Making the test run green is not a priority.  Seeing failure reports
is probably even more educational than seeing green badges.

FWIW, I've added Circle CI to the mix and so far I like it the most.

>> Github: <https://github.com/abalkin/cpython/tree/ci>.

From senthil at uthcode.com  Fri Aug  5 18:21:27 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Fri, 5 Aug 2016 15:21:27 -0700
Subject: [core-workflow] Choosing a CI service
In-Reply-To: <CAP7h-xZrTXqrxqxxTpgxaDagbJaNG+S-cDjJv-X3m0x2w8uoQA@mail.gmail.com>
References: <CAP7h-xbzbkbUSH=T4L_J-3g8_PzBB9_qgp+VyOrjAa8WT56LZg@mail.gmail.com>
 <CAO41-mO3NuPscJooMp5UY2pemvGJiyapANs=KSyZ0-_LVebLoQ@mail.gmail.com>
 <CAP7h-xZrTXqrxqxxTpgxaDagbJaNG+S-cDjJv-X3m0x2w8uoQA@mail.gmail.com>
Message-ID: <CAPOVWOSh2XLmQ_4-anfByvivdDRydHt0mPeNcQgRmSXuKUC+5w@mail.gmail.com>

On Fri, Aug 5, 2016 at 2:51 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
>
> FWIW, I've added Circle CI to the mix and so far I like it the most.

If you are in this exercise, I would also suggest trying with a hosted
version of TeamCity.
that seems extremely feature rich.

From alexander.belopolsky at gmail.com  Fri Aug  5 18:48:39 2016
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Fri, 5 Aug 2016 18:48:39 -0400
Subject: [core-workflow] Choosing a CI service
In-Reply-To: <CAPOVWOSh2XLmQ_4-anfByvivdDRydHt0mPeNcQgRmSXuKUC+5w@mail.gmail.com>
References: <CAP7h-xbzbkbUSH=T4L_J-3g8_PzBB9_qgp+VyOrjAa8WT56LZg@mail.gmail.com>
 <CAO41-mO3NuPscJooMp5UY2pemvGJiyapANs=KSyZ0-_LVebLoQ@mail.gmail.com>
 <CAP7h-xZrTXqrxqxxTpgxaDagbJaNG+S-cDjJv-X3m0x2w8uoQA@mail.gmail.com>
 <CAPOVWOSh2XLmQ_4-anfByvivdDRydHt0mPeNcQgRmSXuKUC+5w@mail.gmail.com>
Message-ID: <CAP7h-xaCyWKZ7MOiXsB3yCrm-_fNp0wedHwYEPM+g1+bGuv1RQ@mail.gmail.com>

On Fri, Aug 5, 2016 at 6:21 PM, Senthil Kumaran <senthil at uthcode.com> wrote:
> If you are in this exercise, I would also suggest trying with a hosted
> version of TeamCity.

I'd love to, but the only free provider I could find was
<http://teamcity.codebetter.com/> and they seem to require a
pre-approval.  Do you know any other providers?

From senthil at uthcode.com  Fri Aug  5 19:21:42 2016
From: senthil at uthcode.com (Senthil Kumaran)
Date: Fri, 5 Aug 2016 16:21:42 -0700
Subject: [core-workflow] Choosing a CI service
In-Reply-To: <CAP7h-xaCyWKZ7MOiXsB3yCrm-_fNp0wedHwYEPM+g1+bGuv1RQ@mail.gmail.com>
References: <CAP7h-xbzbkbUSH=T4L_J-3g8_PzBB9_qgp+VyOrjAa8WT56LZg@mail.gmail.com>
 <CAO41-mO3NuPscJooMp5UY2pemvGJiyapANs=KSyZ0-_LVebLoQ@mail.gmail.com>
 <CAP7h-xZrTXqrxqxxTpgxaDagbJaNG+S-cDjJv-X3m0x2w8uoQA@mail.gmail.com>
 <CAPOVWOSh2XLmQ_4-anfByvivdDRydHt0mPeNcQgRmSXuKUC+5w@mail.gmail.com>
 <CAP7h-xaCyWKZ7MOiXsB3yCrm-_fNp0wedHwYEPM+g1+bGuv1RQ@mail.gmail.com>
Message-ID: <CAPOVWOSa63p7Sji5F-VX_Mkrewu8OODDQVzOOwJZTxDOBbmiKw@mail.gmail.com>

On Fri, Aug 5, 2016 at 3:48 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> Do you know any other providers?

Unfortunately, No. Requesting codebetter.com for a trial seems ok.
Otherwise, downloading the teamcity jar and running it locally is an
option (just for trial).

-- 
Senthil

From rymg19 at gmail.com  Fri Aug  5 20:08:51 2016
From: rymg19 at gmail.com (Ryan Gonzalez)
Date: Fri, 5 Aug 2016 19:08:51 -0500
Subject: [core-workflow] Choosing a CI service
In-Reply-To: <CAP7h-xZrTXqrxqxxTpgxaDagbJaNG+S-cDjJv-X3m0x2w8uoQA@mail.gmail.com>
References: <CAP7h-xbzbkbUSH=T4L_J-3g8_PzBB9_qgp+VyOrjAa8WT56LZg@mail.gmail.com>
 <CAO41-mO3NuPscJooMp5UY2pemvGJiyapANs=KSyZ0-_LVebLoQ@mail.gmail.com>
 <CAP7h-xZrTXqrxqxxTpgxaDagbJaNG+S-cDjJv-X3m0x2w8uoQA@mail.gmail.com>
Message-ID: <CAO41-mO-c1an=1GqWPtwXmVGmwpiOPr9SW7w_L5Bt5tCHsf2KQ@mail.gmail.com>

Hmmm...maybe you'll find this interesting:

https://strongloop.com/strongblog/node-js-travis-circle-codeship-compare/

--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something?s wrong.
http://kirbyfan64.github.io/
On Aug 5, 2016 4:51 PM, "Alexander Belopolsky" <
alexander.belopolsky at gmail.com> wrote:

> On Fri, Aug 5, 2016 at 4:39 PM, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> > FWIW, you said they're "CI services":
> >
> > - CodeCov isn't actually a CI.
>
> It is a "service." It is related to CI.  It's not s stretch to call it
> a "CI service."  It is a component that can be added to most CI
> providers.
>
> > - AFAIK CodeShip doesn't work on Windows, so, for Windows CI, there isn't
> > really a choice other than AppVeyor.
>
> I think you are right.
>
> > - CodeShip seems to require an account just to view the build status.
> > - They're all failing. :(
>
> Making the test run green is not a priority.  Seeing failure reports
> is probably even more educational than seeing green badges.
>
> FWIW, I've added Circle CI to the mix and so far I like it the most.
>
> >> Github: <https://github.com/abalkin/cpython/tree/ci>.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160805/3cc276d4/attachment-0001.html>

From solipsis at pitrou.net  Mon Aug  8 06:13:49 2016
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Mon, 8 Aug 2016 12:13:49 +0200
Subject: [core-workflow] Choosing a CI service
References: <CAP7h-xbzbkbUSH=T4L_J-3g8_PzBB9_qgp+VyOrjAa8WT56LZg@mail.gmail.com>
 <CAO41-mO3NuPscJooMp5UY2pemvGJiyapANs=KSyZ0-_LVebLoQ@mail.gmail.com>
 <CAP7h-xZrTXqrxqxxTpgxaDagbJaNG+S-cDjJv-X3m0x2w8uoQA@mail.gmail.com>
Message-ID: <20160808121349.1209d11a@fsol>

On Fri, 5 Aug 2016 17:51:58 -0400
Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> 
> FWIW, I've added Circle CI to the mix and so far I like it the most.

Can you elaborate why you like it the most?

Regards

Antoine.



From alexander.belopolsky at gmail.com  Mon Aug  8 10:00:38 2016
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Mon, 8 Aug 2016 10:00:38 -0400
Subject: [core-workflow] Choosing a CI service
In-Reply-To: <20160808121349.1209d11a@fsol>
References: <CAP7h-xbzbkbUSH=T4L_J-3g8_PzBB9_qgp+VyOrjAa8WT56LZg@mail.gmail.com>
 <CAO41-mO3NuPscJooMp5UY2pemvGJiyapANs=KSyZ0-_LVebLoQ@mail.gmail.com>
 <CAP7h-xZrTXqrxqxxTpgxaDagbJaNG+S-cDjJv-X3m0x2w8uoQA@mail.gmail.com>
 <20160808121349.1209d11a@fsol>
Message-ID: <07C2268E-F292-43F1-95A1-BACFFF80A44C@gmail.com>


On Aug 8, 2016, at 6:13 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

>> 
>> FWIW, I've added Circle CI to the mix and so far I like it the most.
> 
> Can you elaborate why you like it the most?

For me, the killer feature was ssh access to the build container.  Circle CI simply adds your Github public key to the container instance and gives you an IP address to connect to. 

Overall, I agree with the authors of this blog post: <https://mediocre.com/forum/topics/a-tale-of-two-ci-tools-differentiating-travis-and-circleci>. 


From soltysh at gmail.com  Thu Aug 11 16:09:33 2016
From: soltysh at gmail.com (Maciej Szulik)
Date: Thu, 11 Aug 2016 22:09:33 +0200
Subject: [core-workflow] GitHub reviews comments on b.p.o
In-Reply-To: <20160802142417.E24EEB14023@webabinitio.net>
References: <CAOqj4aW06O3JEuzVTAYQgD5Xo9+RrseAd4iabNCNZTfyyTLfFQ@mail.gmail.com>
 <CAPOVWOSeKNSSiw+xwHKiDfvaLD+JAh0QJCp+iwH12e6yPJGRxw@mail.gmail.com>
 <20160727215716.738FCB14027@webabinitio.net>
 <CAPOVWOSJFwbitRKSSs+uD9VFdfk6yBaZeVEqjxDn8xMr9ujZRw@mail.gmail.com>
 <20160728144857.DB1ACB14027@webabinitio.net>
 <CAPOVWOSgmdsOB74GQ-kgii0ZeXhf2gFSc91C6Fa3XTwZ6X4E=A@mail.gmail.com>
 <83a9e1d3-0de6-f8ef-6c95-7129ab1d6dcc@gmail.com>
 <CAP1=2W7tSo_rMqBV8BtGeQiB5XZPdjn-JbJ9djEu5eBUMRKg0g@mail.gmail.com>
 <CALC2N4aUynX=P3XrVShz90Wc23QT0oaZ3mzA5TQnEJN4EuKEBg@mail.gmail.com>
 <20160802142417.E24EEB14023@webabinitio.net>
Message-ID: <CALC2N4bSeW3g+KC_e2w7MV5Qwj0Q-T6J1iCpFNkE13c4W1LJ7g@mail.gmail.com>

On Tue, Aug 2, 2016 at 4:24 PM, R. David Murray <rdmurray at bitdance.com>
wrote:

> On Sat, 30 Jul 2016 23:21:07 +0200, Maciej Szulik <soltysh at gmail.com>
> wrote:
> > I'm leaning towards just adding an information who left the comment
> > and a link to the PR. I agree with Senthil that gh comments,
> > especially those coming from reviews have code context, which will get
> > lost when copying over. Besides the amount does not matter in that
> > case, whoever is interested in looking or answering into the patch
> > will have to go to GitHub and see what exactly it's about. I'm aware
> > there are cases you just want to read the comment and don't do
> > anything yet, but these are rare cases we can initially ignore. Let's
> > start simple and we can always get back to this topic.
>
> If github comment threading were more sensible I think I'd prefer to see
> the comments reflected.  But since it *isn't* (it is pretty much useless
> outside of the web UI, and even in the web UI it is often awkward),
> I think linking to the PR is indeed probably better.
>
> Just to confirm, we are talking about a new link summarizing the comment
> activity for the past N minutes, whenever commenting activity happens,
> right?  It would be nice to link directly to the new comments, but somehow
> I doubt that is going to be possible (at least if we batch them), so we'll
> probably have to settle for just linking the summary to the PR as a whole.
>
>
Correct. The links to separate comments might be of no use after a rebase
to a PR, since they will point to hidden comments, that's why having a
single
global link is much better, because going to the PR will give you the
current
state of it.

Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160811/94c86cb2/attachment.html>

From rdmurray at bitdance.com  Fri Aug 12 16:38:44 2016
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 12 Aug 2016 16:38:44 -0400
Subject: [core-workflow] GitHub reviews comments on b.p.o
In-Reply-To: <CALC2N4bSeW3g+KC_e2w7MV5Qwj0Q-T6J1iCpFNkE13c4W1LJ7g@mail.gmail.com>
References: <CAOqj4aW06O3JEuzVTAYQgD5Xo9+RrseAd4iabNCNZTfyyTLfFQ@mail.gmail.com>
 <CAPOVWOSeKNSSiw+xwHKiDfvaLD+JAh0QJCp+iwH12e6yPJGRxw@mail.gmail.com>
 <20160727215716.738FCB14027@webabinitio.net>
 <CAPOVWOSJFwbitRKSSs+uD9VFdfk6yBaZeVEqjxDn8xMr9ujZRw@mail.gmail.com>
 <20160728144857.DB1ACB14027@webabinitio.net>
 <CAPOVWOSgmdsOB74GQ-kgii0ZeXhf2gFSc91C6Fa3XTwZ6X4E=A@mail.gmail.com>
 <83a9e1d3-0de6-f8ef-6c95-7129ab1d6dcc@gmail.com>
 <CAP1=2W7tSo_rMqBV8BtGeQiB5XZPdjn-JbJ9djEu5eBUMRKg0g@mail.gmail.com>
 <CALC2N4aUynX=P3XrVShz90Wc23QT0oaZ3mzA5TQnEJN4EuKEBg@mail.gmail.com>
 <20160802142417.E24EEB14023@webabinitio.net>
 <CALC2N4bSeW3g+KC_e2w7MV5Qwj0Q-T6J1iCpFNkE13c4W1LJ7g@mail.gmail.com>
Message-ID: <20160812203845.4E5FDB14023@webabinitio.net>

On Thu, 11 Aug 2016 22:09:33 +0200, Maciej Szulik <soltysh at gmail.com> wrote:
> On Tue, Aug 2, 2016 at 4:24 PM, R. David Murray <rdmurray at bitdance.com>
> wrote:
> 
> > On Sat, 30 Jul 2016 23:21:07 +0200, Maciej Szulik <soltysh at gmail.com>
> > wrote:
> > > I'm leaning towards just adding an information who left the comment
> > > and a link to the PR. I agree with Senthil that gh comments,
> > > especially those coming from reviews have code context, which will get
> > > lost when copying over. Besides the amount does not matter in that
> > > case, whoever is interested in looking or answering into the patch
> > > will have to go to GitHub and see what exactly it's about. I'm aware
> > > there are cases you just want to read the comment and don't do
> > > anything yet, but these are rare cases we can initially ignore. Let's
> > > start simple and we can always get back to this topic.
> >
> > If github comment threading were more sensible I think I'd prefer to see
> > the comments reflected.  But since it *isn't* (it is pretty much useless
> > outside of the web UI, and even in the web UI it is often awkward),
> > I think linking to the PR is indeed probably better.
> >
> > Just to confirm, we are talking about a new link summarizing the comment
> > activity for the past N minutes, whenever commenting activity happens,
> > right?  It would be nice to link directly to the new comments, but somehow
> > I doubt that is going to be possible (at least if we batch them), so we'll
> > probably have to settle for just linking the summary to the PR as a whole.
> >
> >
> Correct. The links to separate comments might be of no use after a
> rebase to a PR, since they will point to hidden comments, that's why
> having a single global link is much better, because going to the PR
> will give you the current state of it.

Yeah, that's one of the things that makes even using it through the
web UI problematic.  Oh well :)

--David

From barry at python.org  Mon Aug 22 15:19:01 2016
From: barry at python.org (Barry Warsaw)
Date: Mon, 22 Aug 2016 15:19:01 -0400
Subject: [core-workflow] GitLab 8.11
Message-ID: <20160822151901.0e9ec580@anarchist.wooz.org>

Just FYI, there are some really cool new features in GitLab 8.11 announced
today.  I haven't played with them yet, but the ones I'm excited about are:

* Kanban-like issue boards.  Automatically generated from issue labels.

* Thru-the-web merge conflict resolution.

* Resolve discussions

* Online IDE integration.

More details:

http://tinyurl.com/jqzvzwr

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160822/7ec5fb99/attachment.sig>

From ncoghlan at gmail.com  Mon Aug 22 23:22:24 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 23 Aug 2016 13:22:24 +1000
Subject: [core-workflow] GitLab 8.11
In-Reply-To: <20160822151901.0e9ec580@anarchist.wooz.org>
References: <20160822151901.0e9ec580@anarchist.wooz.org>
Message-ID: <CADiSq7ca1oZL++1zpqooC6-GZMcMk2kWGKG12Uqc45VOZrYrDw@mail.gmail.com>

On 23 August 2016 at 05:19, Barry Warsaw <barry at python.org> wrote:
> Just FYI, there are some really cool new features in GitLab 8.11 announced
> today.

You noticed that, too, huh? :)

While the update makes me even more keen to move some of our work
projects away from GitHub and back to GitLab (which we were already
considering for reasons related to GitHub's limited access control
management options for private repos), I didn't see anything that made
me go "Yes, we absolutely need this for CPython".

After all, GitLab's "migrate away from GitHub" features are hardly
going to get *worse* over time, so the risk of CPython actually
getting *stuck* on GitHub is very low.  That means the main persistent
workflow changes in the current migration are moving code review away
from the issue tracker and into the repository management system,
enabling bots to handle certain mundane review tasks (checking for CLA
signatures, running the tests) and switching to self-service
management of SSH keys for client authentication.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From barry at python.org  Tue Aug 23 18:44:47 2016
From: barry at python.org (Barry Warsaw)
Date: Tue, 23 Aug 2016 18:44:47 -0400
Subject: [core-workflow] GitLab 8.11
In-Reply-To: <CADiSq7ca1oZL++1zpqooC6-GZMcMk2kWGKG12Uqc45VOZrYrDw@mail.gmail.com>
References: <20160822151901.0e9ec580@anarchist.wooz.org>
 <CADiSq7ca1oZL++1zpqooC6-GZMcMk2kWGKG12Uqc45VOZrYrDw@mail.gmail.com>
Message-ID: <20160823184447.28fa4af0@anarchist.wooz.org>

On Aug 23, 2016, at 01:22 PM, Nick Coghlan wrote:

>You noticed that, too, huh? :)

Oh yes!  Mailman 3 is hosted on GitLab, and I host almost all my personal
projects there, so I also get their newsletter.

>While the update makes me even more keen to move some of our work projects
>away from GitHub and back to GitLab (which we were already considering for
>reasons related to GitHub's limited access control management options for
>private repos), I didn't see anything that made me go "Yes, we absolutely
>need this for CPython".

Agreed, for now.  Of course, friendly competition is always good, and I use
GitHub for plenty of things, but I do really like GitLab.  Some things are
better/easier on one or the other hosting platform, but for CPython, I think
much more important to get us in git soon, and we can fairly easily migrate to
a different hosting platform later if we want.  We already have a python-devs
group and a python unofficial mirror, which I think we should keep up-to-date
as we complete the move to GitHub.

>After all, GitLab's "migrate away from GitHub" features are hardly going to
>get *worse* over time, so the risk of CPython actually getting *stuck* on
>GitHub is very low.  That means the main persistent workflow changes in the
>current migration are moving code review away from the issue tracker and into
>the repository management system, enabling bots to handle certain mundane
>review tasks (checking for CLA signatures, running the tests) and switching
>to self-service management of SSH keys for client authentication.

+1 of course.  It'll be a huge, good change for our workflow.  I know that
switching to git will make *me* more motivated to start contributing again.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160823/ed07477e/attachment.sig>

From soltysh at gmail.com  Mon Aug 29 16:02:20 2016
From: soltysh at gmail.com (Maciej Szulik)
Date: Mon, 29 Aug 2016 22:02:20 +0200
Subject: [core-workflow] GitLab 8.11
In-Reply-To: <20160823184447.28fa4af0@anarchist.wooz.org>
References: <20160822151901.0e9ec580@anarchist.wooz.org>
 <CADiSq7ca1oZL++1zpqooC6-GZMcMk2kWGKG12Uqc45VOZrYrDw@mail.gmail.com>
 <20160823184447.28fa4af0@anarchist.wooz.org>
Message-ID: <CALC2N4Y-jo+iO4wh+NLsU_O8ZVQUBEhNfWnDBgdet1dUDQw-gg@mail.gmail.com>

On Wed, Aug 24, 2016 at 12:44 AM, Barry Warsaw <barry at python.org> wrote:

> On Aug 23, 2016, at 01:22 PM, Nick Coghlan wrote:
>
> >You noticed that, too, huh? :)
>
> Oh yes!  Mailman 3 is hosted on GitLab, and I host almost all my personal
> projects there, so I also get their newsletter.
>
> >While the update makes me even more keen to move some of our work projects
> >away from GitHub and back to GitLab (which we were already considering for
> >reasons related to GitHub's limited access control management options for
> >private repos), I didn't see anything that made me go "Yes, we absolutely
> >need this for CPython".
>
> Agreed, for now.  Of course, friendly competition is always good, and I use
> GitHub for plenty of things, but I do really like GitLab.  Some things are
> better/easier on one or the other hosting platform, but for CPython, I
> think
> much more important to get us in git soon, and we can fairly easily
> migrate to
> a different hosting platform later if we want.  We already have a
> python-devs
> group and a python unofficial mirror, which I think we should keep
> up-to-date
> as we complete the move to GitHub.
>
> >After all, GitLab's "migrate away from GitHub" features are hardly going
> to
> >get *worse* over time, so the risk of CPython actually getting *stuck* on
> >GitHub is very low.  That means the main persistent workflow changes in
> the
> >current migration are moving code review away from the issue tracker and
> into
> >the repository management system, enabling bots to handle certain mundane
> >review tasks (checking for CLA signatures, running the tests) and
> switching
> >to self-service management of SSH keys for client authentication.
>
> +1 of course.  It'll be a huge, good change for our workflow.  I know that
> switching to git will make *me* more motivated to start contributing again.
>
>
I guess you're not the only one. And most importantly, this should
hopefully get us
more keen folks working and contributing to CPython. Once this step is done
I agree
that switching from one hosting platform to another will be much simpler
than the
current work Brett is doing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160829/f4de2826/attachment.html>

From shah.anish07 at gmail.com  Tue Aug 30 15:31:26 2016
From: shah.anish07 at gmail.com (Anish Shah)
Date: Wed, 31 Aug 2016 01:01:26 +0530
Subject: [core-workflow] GitHub Integration
Message-ID: <CAOqj4aUrZf-0r5BHMhSvhh79Vh7ZaroaS0OggZiHH+t7JzL8kA@mail.gmail.com>

Hello everyone,

as you all know, I was working on integrating GitHub into b.p.o under GSoC.
This email is a summary of my work.

Github PRs will be presented in a similar manner as mercurial repos, the
preview is available here
<https://raw.githubusercontent.com/AnishShah/GSoC/master/new.png>.

There will be three ways of linking GitHub PR to an issue on b.p.o

*1. Manually submit a link to GitHub PR on b.p.o*: Paste the link to the
new pull request in the newly-added field "GitHub PR" on issue page. Here
<https://github.com/AnishShah/GSoC/raw/master/manual.png> is how the new
field looks like.

*2. Automatically link GitHub PR using keywords*: If keywords like "fixes"
followed by issue number are used in PR title/body, then it is
automatically linked to that issue on b.p.o. For example, "fixes bpo123"
will link PR to issue 123 on http://bugs.python.org

*3. Auto conversion of a patch file to GitHub PR*: Submit a patch file like
same old way and it will be converted to a GitHub PR automatically.

The detailed description of all the patches I've submitted during my GSoC
can be viewed here
<https://github.com/AnishShah/GSoC/wiki/Google-Summer-of-Code-2016---Work-Product-Submission---Python-Software-Foundation>.
:)
Thank you, everyone. It was great to work on this project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160831/60b18124/attachment.html>

From ncoghlan at gmail.com  Tue Aug 30 23:30:57 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 31 Aug 2016 13:30:57 +1000
Subject: [core-workflow] GitHub Integration
In-Reply-To: <CAOqj4aUrZf-0r5BHMhSvhh79Vh7ZaroaS0OggZiHH+t7JzL8kA@mail.gmail.com>
References: <CAOqj4aUrZf-0r5BHMhSvhh79Vh7ZaroaS0OggZiHH+t7JzL8kA@mail.gmail.com>
Message-ID: <CADiSq7dkkbDJZJ9ZnsGL2uyZ2kgjCriQ8+Cxh==3ozj2Nyfn6g@mail.gmail.com>

On 31 August 2016 at 05:31, Anish Shah <shah.anish07 at gmail.com> wrote:
> Hello everyone,
>
> as you all know, I was working on integrating GitHub into b.p.o under GSoC.
> This email is a summary of my work.

Very cool - thank you for your work!

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From brett at python.org  Wed Aug 31 13:15:16 2016
From: brett at python.org (Brett Cannon)
Date: Wed, 31 Aug 2016 17:15:16 +0000
Subject: [core-workflow] GitHub Integration
In-Reply-To: <CADiSq7dkkbDJZJ9ZnsGL2uyZ2kgjCriQ8+Cxh==3ozj2Nyfn6g@mail.gmail.com>
References: <CAOqj4aUrZf-0r5BHMhSvhh79Vh7ZaroaS0OggZiHH+t7JzL8kA@mail.gmail.com>
 <CADiSq7dkkbDJZJ9ZnsGL2uyZ2kgjCriQ8+Cxh==3ozj2Nyfn6g@mail.gmail.com>
Message-ID: <CAP1=2W52UdoxpCRVA7LLOFLMnYSpm7=Q4u+9SYQkJqk=rkwOhQ@mail.gmail.com>

On Tue, 30 Aug 2016 at 20:31 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 31 August 2016 at 05:31, Anish Shah <shah.anish07 at gmail.com> wrote:
> > Hello everyone,
> >
> > as you all know, I was working on integrating GitHub into b.p.o under
> GSoC.
> > This email is a summary of my work.
>
> Very cool - thank you for your work!
>

Yes, thanks for everything you have done to help move this project forward!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160831/342a0ae7/attachment.html>