Last modified: 2011-12-01 14:55:51 UTC
Related to Bug 6672 ("EXIF orientation (rotation information from digital cameras) should be used in images (edit)") is marked as resolved, and they are used. However, as already noted in bug 6672, there are problems that images are effectively rotated, but the display uses the unrotated length/width, effectively strongly skewing the image. This problem is assumed to be fixed in bug 6672, but at least in 1.18alpha (r95811) it is not. Two examples uploaded: http://species-id.net/openmedia/File:Test-tagged-rotation.JPG contains an original Canon-produced EXIF rotation tag and was uploaded unmodified. It is displayed in portrait mode (YES... it is rotated...), but with the lenght/width settings in landscape mode. For comparison, the same image without a rotation tag, directly rotated with jpg lossless rotation: http://species-id.net/openmedia/File:Test-lossless-rotation.JPG The bug is critical, it breaks using 1.18 on any site that uses images containing EXIF rotation tags.
r92246 fixes this for trunk, was tagged for 1.18, and then untagged by Sam for some reason without being backported to 1.18. Sam?
(In reply to comment #1) > r92246 fixes this for trunk, was tagged for 1.18, and then untagged by Sam for > some reason without being backported to 1.18. Sam? To be honest, I have no idea. Retagged
(In reply to comment #1) > r92246 fixes this for trunk, was tagged for 1.18, and then untagged by Sam for > some reason without being backported to 1.18. Sam? http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92246#c21794 That's why. It was originally not in 1.18, but we re-branched 1.18, so it was then included in the new 1.18
If the revision tagged for 1.18 is already in 1.18 due to rebranching, then it either does not fix the bug or a regression was created later. See the examples given in the first report above. Still present in 1.18alpha (r95907).
Can confirm breakage with this image on trunk as well.
Probably caused by r92279.
Created attachment 9004 [details] Patch that fixes logic errors in normaliseParams There were some logic errors that the attached patch fixes. For some reason the unit tests were incomplete: they did not detect the errors I introduced in r92279. I strongly suggest that proper unit tests are written before this is patch is applied. I may or may not have time to do this.
I'll write some unit tests either tomorrow or over the weekend.
I made some unit tests and applied Bryan's patch in r96687.
Not yet fixed in 1.18alpha (r96692) this bug is about. Test using links in first report. Please keep open until actually in 1.18.
Bugs are closed when they're committed in trunk.
(Mounting frustration) - How to report bugs in mediawiki 1.18 then? The bug says 1.18, not 1.19alpha. Please, please, please, fix this also in 1.18...
(In reply to comment #12) > (Mounting frustration) - How to report bugs in mediawiki 1.18 then? The bug > says 1.18, not 1.19alpha. Please, please, please, fix this also in 1.18... We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki (in general. Its slightly different for 1.18 as 1.18 isn't released yet.). r96692 is currently marked for being included in 1.18 (Along with several other revisions). It will most likely be merged into 1.18 soon-ish assuming a reviewer doesn't find something wrong with it. (If you want to know when that happens, just watch the page for r96692. When it gets fixed in 1.18 there will be a follow-up revision listed in that page with a commit summary starting with MFT) Keep in mind, 1.18 hasn't been officially released yet (not even in beta form), so there's going to bugs... Re-closing as fixed, since it is fixed in trunk (1.19) (and 1.18 fairly soon).
(In reply to comment #13) > (In reply to comment #12) > > (Mounting frustration) - How to report bugs in mediawiki 1.18 then? The bug > > says 1.18, not 1.19alpha. Please, please, please, fix this also in 1.18... > > We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki (in > general. Its slightly different for 1.18 as 1.18 isn't released yet.). r96692 > is currently marked for being included in 1.18 (Along with several other > revisions). It will most likely be merged into 1.18 soon-ish assuming a > reviewer doesn't find something wrong with it. (If you want to know when that > happens, just watch the page for r96692. When it gets fixed in 1.18 there will > be a follow-up revision listed in that page with a commit summary starting with > MFT) > > Keep in mind, 1.18 hasn't been officially released yet (not even in beta form), > so there's going to bugs... > > > Re-closing as fixed, since it is fixed in trunk (1.19) (and 1.18 fairly soon). Replace every time i said r96692 with r96687
Soonish, provided it is some days, is fine. But not allowing to record bugs in 1.18alpha is not really logical. This is a generic issue, I accept the bug (against all logic: the version says 1.18 and it is broken there) as closed. > We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki Does this mean, as soon as 1.18 is released, only bugs in the then-1.18wmf will be fixed (this happens all the time for 1.17) but never for 1.18 again? Most things we found broken in 1.18alpha are the extensions, and I already received the answer that they will not be fixed at all. Searching for a usable mediawiki version is frustrating... > Keep in mind, 1.18 hasn't been officially released yet (not even in beta form), > so there's going to bugs... I know and we volunteer to help getting it tested, trying to find a usable version of mediawiki. 1.16 does not work anymore with several extensions that we need. If you want others to help you with finding bugs in 1.18, please help those trying to use it.
>Soonish, provided it is some days It would probably be in a couple days. >Does this mean, as soon as 1.18 is released, only bugs in the then-1.18wmf will >be fixed (this happens all the time for 1.17) but never for 1.18 again? Traditionally it has to be a fairly major bug for there to be a new (minor version) release. For example security issues would result in another 1.18 release. Hopefully the delay between 1.18 and 1.19 will be less to compensate for that. The generally idea of MediaWiki development is that there is one version that is continually improved, and a snapshot is made of it every once and a while that is tested and released. >I know and we volunteer to help getting it tested, trying to find a usable >version of mediawiki. 1.16 does not work anymore with several extensions that >we need. If you want others to help you with finding bugs in 1.18, please help >those trying to use it. And we're glad you are testing it and reporting bugs :) If there is stuff you think we could do to make tester's lives easier I'd love to hear/discuss. This isn't really the right place to discuss it though, but feel free to send me an email or leave a message on my talk page (or perhaps bring it to a more general forum. I'm not sure which one would be most appropriate though).
(In reply to comment #15) > Soonish, provided it is some days, is fine. But not allowing to record bugs in > 1.18alpha is not really logical. This is a generic issue, I accept the bug > (against all logic: the version says 1.18 and it is broken there) as closed. > > > We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki > > Does this mean, as soon as 1.18 is released, only bugs in the then-1.18wmf will > be fixed (this happens all the time for 1.17) but never for 1.18 again? > > Most things we found broken in 1.18alpha are the extensions, and I already > received the answer that they will not be fixed at all. Searching for a usable > mediawiki version is frustrating... > > > Keep in mind, 1.18 hasn't been officially released yet (not even in beta form), > > so there's going to bugs... > > I know and we volunteer to help getting it tested, trying to find a usable > version of mediawiki. 1.16 does not work anymore with several extensions that > we need. If you want others to help you with finding bugs in 1.18, please help > those trying to use it. I'm not sure where you get the idea that we don't fix bugs in older versions. If they are reported, and a fix is put into trunk, it will be backported. If we don't know it's broken, it can't happen. For example see http://svn.wikimedia.org/viewvc/mediawiki/branches/REL1_17/phase3/RELEASE-NOTES?revision=96559&view=markup Many changes since 1.17, not released yet, granted, but they're there. For security fixes, supported versions will be tested and the fix backported Anything fixed in 1.17wmf1, will usually have been fixed in trunk first (unless the issue doesn't exist there). Usually revisions will then come into 1.17 when appropriate, but this doesn't always happen. Ask, and someone will do it if it's percieved useful - new features won't be backported Look at the revision http://www.mediawiki.org/wiki/Special:Code/MediaWiki/96687 It's tagged to be backported to 1.18, so when it's been reviewed, it'll be triaged and very likely merged back again
> I'm not sure where you get the idea that we don't fix bugs in older versions. > If they are reported, and a fix is put into trunk, it will be backported. Many thanks for the discussion! I don't want to go on your nerves, and I probably do, but somehow I feel something is wrong. I assume what Bawolff said: "We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki [...] Its slightly different for 1.18 as 1.18 isn't released yet." is not to be taken literal, right? (I first did.) So bugs are welcome for older versions, they may be fixed, but there is no control of this, because a bug will be closed as soon as it is ok in trunk, is that it? In this example, if you close specific 1.18-bugs as soon as trunk is fixed, there cannot be any testing whether it indeed is fixed in 1.18, e.g., whether the merger worked or not. I may keep a note independent of the bug report system in my private calendar to check. Those interested in the production or soon-to-be-production, rather than development version would probably all prefer to be able to check once a bugreport is closed. But I readily admit that you probably have good reasons to do it so and that there may simply be no solution that satisfies all. I am project manager, responsible for end-user-functionality, not a developer, as you may guess. ASIDE: The question why I wondered about fixing 1.17 may be perhaps more related to extensions, while you refer to mw core. To us, the extensions are just as vital as mw core. I see many of problems that we would need having fixed are working ok on the Wikipedias, but not in the 1.17svn we tried.
(In reply to comment #18) > > I'm not sure where you get the idea that we don't fix bugs in older versions. > > If they are reported, and a fix is put into trunk, it will be backported. > > Many thanks for the discussion! I don't want to go on your nerves, and I > probably do, but somehow I feel something is wrong. I assume what Bawolff said: > "We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki [...] Its > slightly different for 1.18 as 1.18 isn't released yet." is not to be taken > literal, right? (I first did.) So bugs are welcome for older versions, they may > be fixed, but there is no control of this, because a bug will be closed as soon > as it is ok in trunk, is that it? > > In this example, if you close specific 1.18-bugs as soon as trunk is fixed, > there cannot be any testing whether it indeed is fixed in 1.18, e.g., whether > the merger worked or not. I may keep a note independent of the bug report > system in my private calendar to check. Those interested in the production or > soon-to-be-production, rather than development version would probably all > prefer to be able to check once a bugreport is closed. But I readily admit that > you probably have good reasons to do it so and that there may simply be no > solution that satisfies all. I am project manager, responsible for > end-user-functionality, not a developer, as you may guess. > > ASIDE: The question why I wondered about fixing 1.17 may be perhaps more > related to extensions, while you refer to mw core. To us, the extensions are > just as vital as mw core. I see many of problems that we would need having > fixed are working ok on the Wikipedias, but not in the 1.17svn we tried. Any extensions that are used by the WMF are actively maintained, as are a few select others. Most developers will update code in them when they go about deprecating old code and such. Usually a bug is reported against a specific version, and more often than not, it's still evident in trunk. So trunk is usually the first place it is fixed. It will then depend on the severity of the bug, and somewhat, upto the commiter, as to whether this will make it back into an older version. The comment about closing 1.18 bugs when fixed in trunk, is usual. Many places do this. Very often a simple backport will fix this in the older version aswell. Granted, this isn't always tested. If the "fix" was backported, and then it was still an issue on the branch, reopening the bug would be feasible. As 1.18 is going under stabilisation, it is very like to receive any and all applicable bugfixes, but this never happens instantly. If things aren't tagged for merging to other branches, or similar, please feel free to explicitly ask for it. Usually this will be fine, but if there is some specific reason why this cannot/will not happen, someone would then respond in kind. Asking on the actual fixing revision might be more helpful, then if it doesn't get tagged before, users reviewing it later may tag it, or just do the merges
Thanks for the discussion here. I'm going to synthesize this at [[mw:Bug management/How are bugs fixed]]
