Open Stack

On 09/29/2014 04:48 PM, Dolph Mathews wrote:
> 
> 
> On Mon, Sep 29, 2014 at 6:01 AM, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
> 
>     On 09/29/2014 05:06 AM, Thierry Carrez wrote:
>     > Sean Dague wrote:
>     >> Setuptools 6.0 was released Friday night. (Side note: as a service to
>     >> others releasing major software bumps on critical python software on a
>     >> Friday night should be avoided.)
>     >
>     > Since it's hard to prevent upstream from releasing over the weekends,
>     > could we somehow freeze our PyPI mirrors from Friday noon to Monday noon
>     > infra-team time ?
> 
>     Honestly, I'm not sure that would be very helpful. There tend to be
>     people with one eye open on things over the weekend (like I was this
>     weekend), and the fact that it was fixed then meant most people never
>     saw the break. If we did a giant requirements release every monday
>     morning it would also be *far* more difficult to figure out just based
>     on release dates which upstream dependency probably just killed us.
> 
> 
> What about a continuous delay? Like:
> 
> - never mirror a package until it's at least 72 hours old
> - never mirror a package if it's not the latest release
> 
> If a broken release is produced upstream, developers might be able to
> detect it before the gate consumes it. Further, if upstream produces a
> fixed release within 72 hours, the second rule would mean that infra
> doesn't consume the broken one, and will wait until the new one is 72
> hours old (and we don't have to blacklist it in requirements.txt just
> for our own sake).

Does our mirroring software support this (we are using upstream
mirroring software)? Would this hold true for stackforge libraries? (so
people would have to wait 3 days after their release to test with us).
How about when fixes land?

Honestly, I know it's painful, but the realities are that most people
don't find the bugs we find. They just don't test enough.

There are ideas about getting out ahead of these kinds of things, but
sniff testing upstream source trees before their release, however that's
a bunch of work that no one has signed up for. If someone wants to sign
up to do that work, I'm happy to point you in the right directions.

	-Sean

-- 
Sean Dague
http://dague.net