bawolff bawolff+wn@gmail.com writes:
I disagree having "all" visible changes listed would be useful. The majority of all changes result in some visible change (however minor).
Sure. I don't want to be dogmatic. I really just want to make sure stuff is seen sooner rather than later.
People who are interested in every change generally would already read the RELEASE-NOTES. If we make a list of changes of roughly the same scope as the release notes, it will probably have the same number of readers as the RELEASE-NOTES (Which isn't a whole lot when it comes to your average Wikimedia).
So I will make sure that I look over the RELEASE-NOTES, but I'm worried I'll miss something that a regular editor or commons contributor would notice.
I agree that the 1.18 page like https://www.mediawiki.org/wiki/MediaWiki_1.18 would be best for the actual release. But, as the person who is going to have to manage incoming bug reports, I don't want to problems popping up later ... I'd like to get them tested now.
With that said, it would be great if we could catch everything before deployment, but sometimes things will get through.
Agreed. Things will get through.
We need to be ready both before actual deployment and after deployment to deal with issues. I'm trying to front-load the problem reports.
A message on the commons village pump whenever rsvg is updated would be a good idea imho (since they are generally the folks who deal with svgs and should know if something potentially changed, and people like knowing when things change).
Absolutely!
While it would be awesome to only deploy bug-free software, that isn't going to happen.
But we can get better at responding to the people who use the software in ways we weren't able to predict. This is only the first step.
Mark.