Re: [Distutils] Uploading to Warehouse

2016-06-11 Thread Maurits van Rees

Op 05/06/16 om 15:42 schreef Donald Stufft:

Hey all,

As anyone here who has uploaded anything to PyPI recently is aware of, PyPI's
uploading routine has been in a semi broken state for awhile now. It will
regularly raise a 500 error (but will often still record the release, but
sometimes only a partial release).

Well, the good news is, that Warehouse's upload routines should generally be
good enough to use now. This will be more or less the same as if you uploaded
to PyPI itself (they share a backing data store) but hitting the newer, better
code base instead of the slowly decaying legacy code base.


I had problems uploading to PyPI recently, getting an error although the 
upload seemed to have gone fine in reality.

I did 8 uploads of Plone packages today using the warehouse url.
All have gone fine.

Thanks a lot, Donald!

--
Maurits van Rees: http://maurits.vanrees.org/
Zest Software: http://zestsoftware.nl

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig


Re: [Distutils] Switch PyPA from IRC to Gitter or similar

2016-06-11 Thread Brett Cannon
On Fri, 10 Jun 2016 at 07:25 Ian Cordasco 
wrote:

> On Fri, Jun 10, 2016 at 8:22 AM, Jason R. Coombs 
> wrote:
> > In #pypa-dev, I raised the possibility of moving our PyPA support
> channels from IRC to another hosted solution that enables persistence.
> Although IRC has served us well, there are systems now with clear feature
> advantages, which are crucial to my continuous participation:
>
> I'm choosing not to read this as a threat.
>

I don't think it was a threat to begin with. For it to be a threat it would
somehow need to affect you personally. I think all Jason was trying to do
was to point out this is not some idle conversation to him, but in fact
impacts how he participates in communications regarding setuptools and PyPA.


>
> > - always-on experience; even if one’s device is suspended or otherwise
> offline.
> > - mobile support — the in-cloud experience is essential for low power
> and intermittently connected devices.
> > - push notifications allow a project leader to remain largely inactive
> in a channel, but attention raised promptly when users make a relevant
> mention.
> > - continuous, integrated logging for catching up on the conversation.
>
> So here's a question: Why are these crucial to you? You've explained
> potential benefits but not why they're crucial to you and should be
> crucial to anyone else.
>
> Why do you need an "always-on experience"? Why do you feel required to
> always be on? Do other people tell you that you need to always be on
> chat?
>
> Push notifications allow for prompt attention to mentions, but are all
> mentions push notification worthy? Do we all need to be herded to
> platforms that will spam us because someone mentioned us by nick or
> name? I personally see this as a net negative. I don't need an email
> or push notification to my phone because someone said my name in a
> channel. That's a distraction. It prevents me from working on things
> because it creates a false sense of alarm.
>

I think there's a difference between getting a push notification that rings
your phone and one that simply sits in your notification bar. For the
former that could get annoying if abused, but for the latter it could be
handy if e.g. you are working on a bug and you happen to know that Jason
could help speed things up for you by answering a question if he happens to
be available. To me there's three levels of engagement: (1) I'm willing to
be interrupted, (2) if I'm available I'll notice, else I will ignore it,
and (3) just collect all the messages and I will check the next time I
explicitly log in. You solve (1) by simply being logged into IRC all the
time, but I don't know how to get (2) or (3) to work in IRC w/o setting up
something like a reflector or something fancy (#3 can be covered by email,
and maybe #2 with the right setup).


>
> Continuous logging is on for #pypa and #pypa-dev as I understand it.
> Surely it's not "integrated" into your chat client, but it's not as if
> the logging doesn't exist.
>

For me the constant connection allows for collecting mentions into a single
notification area (#3 in the engagement level list I mentioned above). I
personally have 4 devices I connect to the internet with and none of them
short of my phone is on constantly. With some kind of constant connection I
could then have all of the mentions I have not seen collected into a single
place so I could address them no matter what device I choose to check in
with. Otherwise I have to restrict myself to only using a device which has
an IRC client that can reconcile where I left off and pick up on all the
messages that mentioned me since I last logged in.

And as for mobile access, that's just a matter of occasional convenience. I
don't think that messaging all the time from my mobile phone is the best
option, but it is one that I can do while e.g. sitting on the bus on the
way to work so that I can spend my time at home doing other things
potentially.


>
> > Both Gitter and Slack offer the experience I’m after, with Gitter
> feeling like a better fit for open-source projects (or groups of them).
>
> I've tried using Gitter several times in the past. Unless they've
> fixed their bugs related to sending me emails every day about activity
> in a channel I spoke in once and left, I think they should be
> eliminated.
>
> Slack has also had several outages lately that should also disqualify
> it (besides the fact that it's incredibly closed source and will be
> expensive to maintain logs in).
>
> > I’ve tried using IRCCloud, and it provides a similar, suitable
> experience on the same IRC infrastructure, with one big difference. While
> Gitter and Slack offer the above features for free, IRCCloud requires a
> $5/user/month subscription (otherwise, connections are dropped after two
> hours). I did reach out to them to see if they could offer some
> professional consideration for contributors, but I haven’t heard from them.
> Furthermore,