Re: [python-committers] Github reviews are cannibalizing BPO

[M.-A. Lemburg]

On 02.05.2017 00:32, Christian Heimes wrote:
> This brings me to my questions
> 
> 1) Should we try to move discussion back to BPO or are we fine with
> having major decisions just in Github PRs?

We've had that discussion before: discussions always should
happen on BPO, not Github PRs. PRs are just for code review,
nothing more.

AFAIK, there's no good way to enforce this except core devs
pointing people to BPO instead of commenting on PRs.

> 2) How can we retain enough information on BPO to keep it useful as
> research database for past decisions?

See above.

> 3) How can we keep module maintainers and experts in the loop? For
> example I don't have the resources to read all Github PRs, but I still
> like to keep an eye on the ssl and hashlib module.

See above :-)

I have muted all Github notifications since it became impossible
to follow them.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 02 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[M.-A. Lemburg]

On 02.05.2017 04:25, Nick Coghlan wrote:
> On 2 May 2017 at 08:32, Christian Heimes  wrote:
>> This brings me to my questions
>>
>> 1) Should we try to move discussion back to BPO or are we fine with
>> having major decisions just in Github PRs?
>>
>> 2) How can we retain enough information on BPO to keep it useful as
>> research database for past decisions?
> 
> It's OK to have the discussions on GitHub, but one of the
> responsibilities of reviewers is to ensure that significant design
> decisions are summarised on the related tracker issue for future
> reference.

I don't think that's a good idea, since the core devs then
have to check what's good discussion to have on Github PRs
and what not.

IMO, it's much easier for everyone to just always point people
to BPO for discussions and keep PRs reserved for code reviews.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 02 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[R. David Murray]

On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg"  wrote:
> On 02.05.2017 04:25, Nick Coghlan wrote:
> > On 2 May 2017 at 08:32, Christian Heimes  wrote:
> >> This brings me to my questions
> >>
> >> 1) Should we try to move discussion back to BPO or are we fine with
> >> having major decisions just in Github PRs?
> >>
> >> 2) How can we retain enough information on BPO to keep it useful as
> >> research database for past decisions?
> > 
> > It's OK to have the discussions on GitHub, but one of the
> > responsibilities of reviewers is to ensure that significant design
> > decisions are summarised on the related tracker issue for future
> > reference.
> 
> I don't think that's a good idea, since the core devs then
> have to check what's good discussion to have on Github PRs
> and what not.
> 
> IMO, it's much easier for everyone to just always point people
> to BPO for discussions and keep PRs reserved for code reviews.

I agree with Mark-Andre here.  It will take effort on our part to
make our culture be "discuss on BPO", but it will produce a much
superior history to what github PRs produce, so I think it is worth it.

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Eric V. Smith]

On 5/2/17 10:07 AM, R. David Murray wrote:

On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg"  wrote:

On 02.05.2017 04:25, Nick Coghlan wrote:

On 2 May 2017 at 08:32, Christian Heimes  wrote:

This brings me to my questions

1) Should we try to move discussion back to BPO or are we fine with
having major decisions just in Github PRs?

2) How can we retain enough information on BPO to keep it useful as
research database for past decisions?


It's OK to have the discussions on GitHub, but one of the
responsibilities of reviewers is to ensure that significant design
decisions are summarised on the related tracker issue for future
reference.


I don't think that's a good idea, since the core devs then
have to check what's good discussion to have on Github PRs
and what not.

IMO, it's much easier for everyone to just always point people
to BPO for discussions and keep PRs reserved for code reviews.


I agree with Mark-Andre here.  It will take effort on our part to
make our culture be "discuss on BPO", but it will produce a much
superior history to what github PRs produce, so I think it is worth it.


I agree with David and MAL. github PR's should replace Rietveld for code 
reviews, and should not replace BPO for discussions.


Eric.

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Guido van Rossum]

I'm not necessarily disagreeing, I'm just skeptical that we can stop this
tide. New contributors are familiar with GitHub and GitHub only, and for
them, BPO looks and feels like a legacy system. And honestly, for smaller
projects, I've found GitHub a very effective place to have discussions
(e.g. most mypy design work is done there). Though I agree that GitHub
currently doesn't scale to the size of CPython unless you work hard on
setting up filtering (which *is* possible, just done very differently).

On Tue, May 2, 2017 at 10:24 AM, Eric V. Smith  wrote:

> On 5/2/17 10:07 AM, R. David Murray wrote:
>
>> On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" 
>> wrote:
>>
>>> On 02.05.2017 04:25, Nick Coghlan wrote:
>>>
 On 2 May 2017 at 08:32, Christian Heimes  wrote:

> This brings me to my questions
>
> 1) Should we try to move discussion back to BPO or are we fine with
> having major decisions just in Github PRs?
>
> 2) How can we retain enough information on BPO to keep it useful as
> research database for past decisions?
>

 It's OK to have the discussions on GitHub, but one of the
 responsibilities of reviewers is to ensure that significant design
 decisions are summarised on the related tracker issue for future
 reference.

>>>
>>> I don't think that's a good idea, since the core devs then
>>> have to check what's good discussion to have on Github PRs
>>> and what not.
>>>
>>> IMO, it's much easier for everyone to just always point people
>>> to BPO for discussions and keep PRs reserved for code reviews.
>>>
>>
>> I agree with Mark-Andre here.  It will take effort on our part to
>> make our culture be "discuss on BPO", but it will produce a much
>> superior history to what github PRs produce, so I think it is worth it.
>>
>
> I agree with David and MAL. github PR's should replace Rietveld for code
> reviews, and should not replace BPO for discussions.
>
> Eric.
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Terry Reedy]

On 5/2/2017 10:07 AM, R. David Murray wrote:

On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg"  wrote:



IMO, it's much easier for everyone to just always point people
to BPO for discussions and keep PRs reserved for code reviews.


I agree with Mark-Andre here.  It will take effort on our part to
make our culture be "discuss on BPO", but it will produce a much
superior history to what github PRs produce, so I think it is worth it.


It would easier to move discussion to bpo if there were a clickable link 
from PR to bpo, just as there is in the opposite direction.  I believe 
that there is a workflow issue to add this, but last I knew, it was 
bogged down in where to put the link, or something.


tjr

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Christian Heimes]

On 2017-05-02 20:28, Terry Reedy wrote:
> On 5/2/2017 10:07 AM, R. David Murray wrote:
>> On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" 
>> wrote:
> 
>>> IMO, it's much easier for everyone to just always point people
>>> to BPO for discussions and keep PRs reserved for code reviews.
>>
>> I agree with Mark-Andre here.  It will take effort on our part to
>> make our culture be "discuss on BPO", but it will produce a much
>> superior history to what github PRs produce, so I think it is worth it.
> 
> It would easier to move discussion to bpo if there were a clickable link
> from PR to bpo, just as there is in the opposite direction.  I believe
> that there is a workflow issue to add this, but last I knew, it was
> bogged down in where to put the link, or something.

All recent PRs have a clickable link to BPO. It's in the box with CI
results. Click on "Details" for "bedevere/issue-number".

Christian
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Eric V. Smith]

On 5/2/17 2:13 PM, Guido van Rossum wrote:

I'm not necessarily disagreeing, I'm just skeptical that we can stop
this tide. New contributors are familiar with GitHub and GitHub only,
and for them, BPO looks and feels like a legacy system. And honestly,
for smaller projects, I've found GitHub a very effective place to have
discussions (e.g. most mypy design work is done there). Though I agree
that GitHub currently doesn't scale to the size of CPython unless you
work hard on setting up filtering (which *is* possible, just done very
differently).


I grant that it's an uphill battle. But even github has a separate issue 
tracker, we're just not using it. So even github black belts should be 
familiar with the concept of an issue tracker being used for a different 
purpose than code reviews are.


Eric.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Donald Stufft]

> On May 2, 2017, at 2:37 PM, Eric V. Smith  wrote:
> 
> On 5/2/17 2:13 PM, Guido van Rossum wrote:
>> I'm not necessarily disagreeing, I'm just skeptical that we can stop
>> this tide. New contributors are familiar with GitHub and GitHub only,
>> and for them, BPO looks and feels like a legacy system. And honestly,
>> for smaller projects, I've found GitHub a very effective place to have
>> discussions (e.g. most mypy design work is done there). Though I agree
>> that GitHub currently doesn't scale to the size of CPython unless you
>> work hard on setting up filtering (which *is* possible, just done very
>> differently).
> 
> I grant that it's an uphill battle. But even github has a separate issue 
> tracker, we're just not using it. So even github black belts should be 
> familiar with the concept of an issue tracker being used for a different 
> purpose than code reviews are.
> 


I suspect part of it may simply be that mucking around with b.p.o is far less 
streamlined then GitHub issues or PRs. One thing we might want to look at is 
making it possible to login with GitHub to b.p.o, as that is one possible 
hurdle for someone to cross when looking at making a comment on a PR/issue.

The flip side of that is even prior to using GitHub it wasn’t like all of the 
discussion was happening on b.p.o either, some of it happened in Reitveld 
(though less of it than is happening on GitHub because using Reitveld is/was 
more frustrating than a GitHub comment) and a lot of it happened in random back 
channels between individuals.

Ultimately, it’s likely to be a Sisyphean battle to stop it from happening 
unless b.p.o gets updated to have a UX on par with GitHub and the integration 
between the two of them makes it as low friction as possible.


—
Donald Stufft



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[M.-A. Lemburg]

On 02.05.2017 20:44, Donald Stufft wrote:
> 
> I suspect part of it may simply be that mucking around with b.p.o is far less 
> streamlined then GitHub issues or PRs. One thing we might want to look at is 
> making it possible to login with GitHub to b.p.o, as that is one possible 
> hurdle for someone to cross when looking at making a comment on a PR/issue.
> 
> The flip side of that is even prior to using GitHub it wasn’t like all of the 
> discussion was happening on b.p.o either, some of it happened in Reitveld 
> (though less of it than is happening on GitHub because using Reitveld is/was 
> more frustrating than a GitHub comment) and a lot of it happened in random 
> back channels between individuals.

I don't think that's a good characterization of what we used
to have. We had discussions on bpo and when we felt that things
were of a more general nature, we actively moved those discussions
to the MLs.

This resulted in a healthy approach to OSS software development,
since we had many different people take part in those discussions.

We're losing this if we move away from bpo and towards having
PR discussions. Github's notification system is simply not
geared up for the high volume Python generates.

This doesn't have much to do with UX/UI. It's mainly a questions
of culture. Github is more geared up for a culture of quick chat
style comments, whereas bpo has traditionally seen a more elaborate
in-depth discussions style.

Personally, I prefer the latter, since chats are great for getting
quick feedback or notifications, but much less so for discussions
that go into more detail.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 02 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Terry Reedy]

On 5/2/2017 2:36 PM, Christian Heimes wrote:

On 2017-05-02 20:28, Terry Reedy wrote:

On 5/2/2017 10:07 AM, R. David Murray wrote:

On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" 
wrote:



IMO, it's much easier for everyone to just always point people
to BPO for discussions and keep PRs reserved for code reviews.


I agree with Mark-Andre here.  It will take effort on our part to
make our culture be "discuss on BPO", but it will produce a much
superior history to what github PRs produce, so I think it is worth it.


It would easier to move discussion to bpo if there were a clickable link
from PR to bpo, just as there is in the opposite direction.  I believe
that there is a workflow issue to add this, but last I knew, it was
bogged down in where to put the link, or something.


All recent PRs have a clickable link to BPO. It's in the box with CI
results.


Not until one clicks 'Show all checks'.  This is rather obscure.  Who 
would know?  Thanks for the info.



Click on "Details" for "bedevere/issue-number".


Neither was it obvious to me that 'details' takes me to the issue, 
rather than revealing a clickable issue-number, so that I need to middle 
click to open a new tab.


So this is still considerable friction.

tjr
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Donald Stufft]

> On May 2, 2017, at 3:09 PM, M.-A. Lemburg  wrote:
> 
> This doesn't have much to do with UX/UI. It's mainly a questions
> of culture. Github is more geared up for a culture of quick chat
> style comments, whereas bpo has traditionally seen a more elaborate
> in-depth discussions style.


This is not really accurate to my experience using GitHub. In pip for example 
while we have distutils-sig and a pypa-dev mailing list we hardly ever use them 
for pip focused discussion. The vast bulk of our discussion (including quite 
long ones, and I think most folks who end up in a discussion with me know I can 
produce a fair amount of content in one) occur entirely within GitHub and it 
works just fine. I don’t think this is unique to pip either. Pretty much the 
only time we use anything but GitHub are when the blast radius for a change is 
larger then pip itself (e.g. something that touches pip, setuptools, and pypi) 
which we use distutils-sig for, or when something is just a notice that doesn’t 
require discussion, which we use pypa-dev for.

I agree that there are benefits to separating code review and issue tracking 
(although I’m not a purist about it, I think some PRs are too small to warrant 
an issue for instance) and I think that without some effort to automate and 
write a bot GitHub issues are not a good fit for replacing bpo. However I think 
it’s going to be a regular struggle to get people to try and primarily use bpo 
for issue discussion (vs code review) because the friction of doing so is 
fairly high. I think if you want to encourage people to utilize bpo better, 
your best bet is to do everything you can to reduce that friction.

—
Donald Stufft



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Donald Stufft]

> On May 2, 2017, at 3:42 PM, Donald Stufft  wrote:
> 
> 
>> On May 2, 2017, at 3:09 PM, M.-A. Lemburg > > wrote:
>> 
>> This doesn't have much to do with UX/UI. It's mainly a questions
>> of culture. Github is more geared up for a culture of quick chat
>> style comments, whereas bpo has traditionally seen a more elaborate
>> in-depth discussions style.
> 
> 
> This is not really accurate to my experience using GitHub. In pip for example 
> while we have distutils-sig and a pypa-dev mailing list we hardly ever use 
> them for pip focused discussion. The vast bulk of our discussion (including 
> quite long ones, and I think most folks who end up in a discussion with me 
> know I can produce a fair amount of content in one) occur entirely within 
> GitHub and it works just fine. I don’t think this is unique to pip either. 
> Pretty much the only time we use anything but GitHub are when the blast 
> radius for a change is larger then pip itself (e.g. something that touches 
> pip, setuptools, and pypi) which we use distutils-sig for, or when something 
> is just a notice that doesn’t require discussion, which we use pypa-dev for.
> 
> I agree that there are benefits to separating code review and issue tracking 
> (although I’m not a purist about it, I think some PRs are too small to 
> warrant an issue for instance) and I think that without some effort to 
> automate and write a bot GitHub issues are not a good fit for replacing bpo. 
> However I think it’s going to be a regular struggle to get people to try and 
> primarily use bpo for issue discussion (vs code review) because the friction 
> of doing so is fairly high. I think if you want to encourage people to 
> utilize bpo better, your best bet is to do everything you can to reduce that 
> friction.
> 


To touch on this a bit more, arguably GitHub is *more* suited to long form 
discussion, given that it includes the ability to format your text which is an 
incredibly important part of producing readable content more then a few 
sentences long. You can attempt to apply some of this with bpo using ASCII 
representations, but an inlined URL or a footnote to the URL is never going to 
be as good as a hyperlink, or an inlined image, or bold, italics, etc.


—
Donald Stufft



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Paul Moore]

On 2 May 2017 at 20:42, Donald Stufft  wrote:
>
> On May 2, 2017, at 3:09 PM, M.-A. Lemburg  wrote:
>
>> This doesn't have much to do with UX/UI. It's mainly a questions
>> of culture. Github is more geared up for a culture of quick chat
>> style comments, whereas bpo has traditionally seen a more elaborate
>> in-depth discussions style.
>
> This is not really accurate to my experience using GitHub. In pip for
> example while we have distutils-sig and a pypa-dev mailing list we hardly
> ever use them for pip focused discussion. The vast bulk of our discussion
> (including quite long ones, and I think most folks who end up in a
> discussion with me know I can produce a fair amount of content in one) occur
> entirely within GitHub and it works just fine. I don’t think this is unique
> to pip either. Pretty much the only time we use anything but GitHub are when
> the blast radius for a change is larger then pip itself (e.g. something that
> touches pip, setuptools, and pypi) which we use distutils-sig for, or when
> something is just a notice that doesn’t require discussion, which we use
> pypa-dev for.
>
> I agree that there are benefits to separating code review and issue tracking
> (although I’m not a purist about it, I think some PRs are too small to
> warrant an issue for instance) and I think that without some effort to
> automate and write a bot GitHub issues are not a good fit for replacing bpo.
> However I think it’s going to be a regular struggle to get people to try and
> primarily use bpo for issue discussion (vs code review) because the friction
> of doing so is fairly high. I think if you want to encourage people to
> utilize bpo better, your best bet is to do everything you can to reduce that
> friction.

I have to agree here. I'm not sufficiently involved in bpo discussions
to have a strong opinion, but my experience with pip is the same as
Donald's - it's pretty easy to have complex design decisions on
github, as well as having review style comments. I'd have to say the
new "create a review" interface in github can make conversations
harder to follow, particularly if you're reading the emails rather
than reading on the github site itself, but I tend to work by reading
emails to spot the interesting topics, then go to GH for the full
story.

One other huge win for me with github over bpo is that the former
allows formatted text. I find having to read plaintext discussions on
bpo *much* more tiring than reading github formatted content.

But the big problem for me with github discussions in Python is the
sheer volume. My normal github workflow (which works fine for pip)
collapses under the volume of Python traffic. That's not to say that
bpo is any better - I basically ignore the majority of bpo traffic
that I['m not automatically nosied on, for exactly the same reason,
that my approach doesn't scale.

To summarise:

1. The traffic for CPython is the biggest issue - expecting people
with established workflows that cope with it to rework those workflows
to work with gh rather than bpo is a big ask.
2. Having formatted text for the discussions is (IMO) a huge win.
3. Apart from familiarity, I don't think there's much difference in
the ability to have design discussions (as long as you don't hide
design comments in the GH review notes, of course, but that's just a
matter of using the tool correctly).
4. Neither interface (in my experience) does a wonderful job of making
the discussion transparent via email. But I tend to see email as a
transient notification medium - we should probably concentrate more on
the UX when interacting with the website directly.

I can't really weight these factors, so I'll leave that to the people
who interact with the trackers more often than I do.

Paul
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Github reviews are cannibalizing BPO

[Barry Warsaw]

On May 02, 2017, at 03:54 PM, Donald Stufft wrote:

>To touch on this a bit more, arguably GitHub is *more* suited to long form
>discussion, given that it includes the ability to format your text which is
>an incredibly important part of producing readable content more then a few
>sentences long. You can attempt to apply some of this with bpo using ASCII
>representations, but an inlined URL or a footnote to the URL is never going
>to be as good as a hyperlink, or an inlined image, or bold, italics, etc.

This might be true w.r.t. GH vs. bpo, but both of them are inferior IMHO to
mailing lists or other types of threaded discussions.  Personally, I find
GitLab to have a better conversational UX than GitHub, but neither is threaded
so it forces the discussions to be linear.  That's okay for many discussions,
but far inferior to more wide ranging discussions.

-Barry
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] No Travis-CI on OS X?

[Antoine Pitrou]

Hi,

Perhaps it would be possible to set up a Travis CI matrix entry for OS
X, those builds are often quite slow but at least it could be part of
the "allowed failures" suite.  That would help detect platform issues at
PR time rather than later :-)

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] No Travis-CI on OS X?

[Donald Stufft]

> On May 2, 2017, at 5:35 PM, Antoine Pitrou  wrote:
> 
> 
> Hi,
> 
> Perhaps it would be possible to set up a Travis CI matrix entry for OS
> X, those builds are often quite slow but at least it could be part of
> the "allowed failures" suite.  That would help detect platform issues at
> PR time rather than later :-)
> 


I think the only reason we don’t have them on is because the macOS builds on 
Travis are _Super_ slow and regularly get a large backlog. Fast Finish and 
Allowed Failures would help with that though.

—
Donald Stufft



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] No Travis-CI on OS X?

[Victor Stinner]

2017-05-02 23:37 GMT+02:00 Donald Stufft :
> I think the only reason we don’t have them on is because the macOS builds on
> Travis are _Super_ slow and regularly get a large backlog. Fast Finish and
> Allowed Failures would help with that though.

Maybe we can start with a small subset of tests and enlarge it later?

I may help to catch the most obvious failures.

Sadly, in my experience, on macOS, I only saw subtle failures, no
obvious bug in very common tests.

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] No Travis-CI on OS X?

[Antoine Pitrou]

Is there a way to get faster OS X builds with our connections at Travis-CI?
I agree that OS X builds are usually very slow (though it depends on
daytime, see https://www.traviscistatus.com/#week), but perhaps it's
possible to improve on that :-)

Regards

Antoine.


Le 02/05/2017 à 23:37, Donald Stufft a écrit :
> 
> 
>> On May 2, 2017, at 5:35 PM, Antoine Pitrou > > wrote:
>>
>>
>> Hi,
>>
>> Perhaps it would be possible to set up a Travis CI matrix entry for OS
>> X, those builds are often quite slow but at least it could be part of
>> the "allowed failures" suite.  That would help detect platform issues at
>> PR time rather than later :-)
>>
> 
> 
> I think the only reason we don’t have them on is because the macOS
> builds on Travis are _Super_ slow and regularly get a large backlog.
> Fast Finish and Allowed Failures would help with that though.
> 
> —
> Donald Stufft
> 
> 
> 
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] No Travis-CI on OS X?

[Alex Gaynor]

Travis's macOS builds aren't as slow as they used to be, between them
adding capacity and our queue increase.

Alex

On Tue, May 2, 2017 at 5:38 PM, Antoine Pitrou  wrote:

>
>
> Is there a way to get faster OS X builds with our connections at Travis-CI?
> I agree that OS X builds are usually very slow (though it depends on
> daytime, see https://www.traviscistatus.com/#week), but perhaps it's
> possible to improve on that :-)
>
> Regards
>
> Antoine.
>
>
> Le 02/05/2017 à 23:37, Donald Stufft a écrit :
> >
> >
> >> On May 2, 2017, at 5:35 PM, Antoine Pitrou  >> > wrote:
> >>
> >>
> >> Hi,
> >>
> >> Perhaps it would be possible to set up a Travis CI matrix entry for OS
> >> X, those builds are often quite slow but at least it could be part of
> >> the "allowed failures" suite.  That would help detect platform issues at
> >> PR time rather than later :-)
> >>
> >
> >
> > I think the only reason we don’t have them on is because the macOS
> > builds on Travis are _Super_ slow and regularly get a large backlog.
> > Fast Finish and Allowed Failures would help with that though.
> >
> > —
> > Donald Stufft
> >
> >
> >
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/