https://bugzilla.wikimedia.org/show_bug.cgi?id=30640
--- Comment #19 from Reedy <[email protected]> 2011-09-10 01:16:34 UTC --- (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 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
