Today we're in a 24-hour brownout period to help folks find places they might have forgotten which rely on unencrypted git:// protocol. The date where this will go away permanently is still March 15, 2022.
(I'm the product manager for Git Systems at GitHub.)
It seems like the brownout should be publicized on the front page of github.com - or at least githubstatus.com ?
(Although I'm not an active git/github user, so maybe there's an even more more obvious place a naive user having issues would go to figure out what their problem is. Hopefully there's a helpful commandline error explaining the situation.)
Our CI system broke as a result - I really like this "brownout" idea to help us find it before it turns off for good, but a 24-hour period for us to be broken or scramble to fix is kind of a PITA.
I imagine it would be much more technical effort, but a way for us to opt certain repos out of a brownout would be really nice, so that once it happens, we could easily disable the brownout for our repo & schedule working on a fix, while letting us continue working with the existing infra.
One way to opt out of the brownout would have been to switch to new Auth back in September of last year. Or November of last year after the first brown out.
Because the next brownout is permanent - and that will be an even bigger PITA.
I think it's extraordinarily powerful to have these brownouts for organizations that don't make the change when they should have (which was last year).
> One way to opt out of the brownout would have been to switch to new Auth back in September of last year. Or November of last year after the first brown out.
The point of the brown out is to help people find cases where they’ve missed this. So “opt out by doing it beforehand” isn’t a viable solution.
The last brownout was a quarter ago. A lot of new things can get introduced in that time that still do it wrong.
I think the idea is that once you know what is going on you can opt out, so that you can put fixing it on your next sprint instead of having to drop everything and fix it right now so you don't lose 24 hours of productivity.
I 100% understand that - The point I'm trying to make is- the next "brown out" is permanent - so instead of 24 hours, next time you will have a permanent loss of productivity. I.E. Why are there devices being deployed that are still broken? Because in a few months, they are never coming back until they are fixed.
The idea is to make brownouts increasingly painful - just letting them be a short period of time, or let people "Opt. Out" doesn't service the purpose here - which is to make it absolutely clear that the service is going away.
An interesting additional benefit here, is that rather than a brownout, you could just have a "soft cutover", where people can reenable the old protocols for two months. There's good reason for this:
- People who aren't using the old methods can turn them off now and leave them off, benefiting from the new security change sooner.
- People who need to fix something can temporarily repair their workflow at the time of their choosing.
- People who need more than 24 hours to fix their workflow can re-disable the old methods to test that they are now good, at a time of their leisure, between today and March.
Well, feature removals do. Deprecations are just declaring that a feature should not be used and either will or may be removed in the future, which causes no operational problems (and in fact is done specifically to help avoid the operational problems of feature removals.)
I'm not impacted, but I wonder if doing a brownout that is ran on odd hours for a week and then a brownout that is ran on even hours for a week would catch more situations and allow people to fix systems without as much fanfare.
Degrading a service/feature or having intermittent failures rather than just immediately knocking a service/feature offline. In this case, intentionally induced and used as a strong nudge to downstream users to stop using this particular feature.
Comes from terminology used for the electric grid, where a brownout is a milder form of a blackout. Instead of electricity being entirely shut off and everything goes "black," the voltage drops and lights dim, i.e. go "brown."
Usually 'brownout' refers to a situation where an electrical grid is failing to provide sufficient power but is still providing some. It's not quite a blackout, but its also not functioning properly.
In this context it's referring to a transitory period where a feature is in a state of flux and may only partially work.
(I'm the product manager for Git Systems at GitHub.)