bawolff <bawolff+wn(a)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.