On Wed, Jan 25, 2017 at 11:20 AM, Chad Horohoe <[email protected]> wrote:
> - We (me, mostly) need to *drastically* cut down the time it takes to get > security releases public. Carrying non-master fixes in production should > be the exception, not the norm. This also helps us keep non-production > wikis safer (I'm looking at you, beta) > Also, third-party wikis. Getting security patches out to them can take a looong time. The patch in question (T109140) was initially deployed in March. Granted, the time security patches spend in hiding tends to be inversely proportional to their severity; even so, it is not an ideal situation. Maybe the security release process could be made more collaborative? For writing a security patch there is a good step-by-step tutorial so maintainers of the affected part of the codebase can just do it without placing the burden on security/releng; maybe something like that could be done for releases as well? - Using merges/shared git history between deployment branches instead > of patchfiles would probably simplify a lot of this, needs further thinking > through though > You can always cherry-pick the patches from the old branch which are in master but not in origin/master. The disadvantage is that it's harder to tell when a security patch was dropped deliberately vs. lost due to accident (right now the git history of /srv/patches provides a clear audit log, when it's properly maintained - that's not always the case but would be easy to enforce). - A *clear* owner for any security patches in production (without having > to dig through Phabricator). This person must be consulted on any > non-trivial > conflict, imho. > The author field in git?
_______________________________________________ QA mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/qa
