Making your case here is probably best. The release engineering team are the people you probably have to convince, although of course anyone could potentially create such a wiki, in an unofficial way. Keep in mind that keeping an older version of the software running does introduce a maintinance burden, so you will probably have to convince people that it would be regularly useful and not just useful this one time. -- bawolff On Thursday, September 21, 2017, יגאל חיטרון <khitron(a)gmail.com> wrote: version

On Thu, Sep 21, 2017 at 2:52 PM, יגאל חיטרון <khitron(a)gmail.com> wrote: This use case is exactly the reason that group0 (testwiki, test2wiki, testwikidatawiki, medaiwikiwiki) and group1 (non-wikipedia wikis) get code before group2 (all wikipedias). The order of operations is just reversed from what you are asking for. Group0 gets new release on Tuesday, then group1 on Wednesday, and finally group2 on Thursday. Why in this order? We want people to test and find bugs *before* they hit the larger wikis. Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Manager, Cloud Services Boise, ID USA irc: bd808 v:415.839.6885 x6855

It wouldn't be hard to do at all, technically. I imagine it'd be something like a test3wiki. Main thing to know is when do we cycle off of the old version? When the version goes out on Tuesdays? That day's already pretty loaded for software moving about... -Chad On Thu, Sep 21, 2017 at 1:25 PM Brian Wolff <bawolff(a)gmail.com> wrote:

No non-emergency deployments on Fridays, Saturdays or Sundays. Monday could work. -Chad ‪On Thu, Sep 21, 2017 at 7:15 PM ‫יגאל חיטרון‬‎ <khitron(a)gmail.com> wrote:‬

What's the purpose of this information? If it's a bug, new or not, a ticket needs to be filed. And when I do know it's a new bug, I can open both versions I agree that information will save some developer time but at the same time this information is not so easy to gather. This is helpful when the users have some working knowledge of how developer tools work and how to compare file changes. Usually in each version there are a lot of new changes. Often it's not easy for developers even to find out what could be causing the bug. I can easily imagine such a wiki quickly falling into disuse. On Thu, Sep 21, 2017 at 7:29 PM, יגאל חיטרון <khitron(a)gmail.com> wrote: -- Niharika Software Engineer Community Tech Wikimedia Foundation

The purpose is to say to developers if it's a new problem, or isn't. I can think about six benefits: 1) It can save them the time for checking this. 2) It can be made better by task filer than by developer, because the first knows better the problem. 3) It can save the time needed to them or other to find duplicate task, because there are less tasks to check, only from the last week. 4) There are many cases when the filer have no way to give an instruction to reproduce the bug, does not succeed to create such an instruction, or the developer does not succeed to reproduce it. If the developer will know that the bug is new, it will be much easier to they to recognize the problem, or find the right way for reproduction. 5) Groups 0-1-2 are done (also) exactly for this. New wiki will just give 5 times more time to see the bugs, which not always come in the first day only. 6) If there is some new bug that wasn't found on groups 0-1, but was found, say, by enwiki user - and most of not tech users is there - they have not another day to compare, as previous groups do. About logs - I don't talk about extremally techs users, almost developers, that can do all the research work by themselves, but about the most of them. Igal On Sep 22, 2017 11:34, "Eran Rosenthal" <eranroz89(a)gmail.com> wrote:

Hi, Moriel. Well, I see your point, but I still think it should be done. You spoke about do this, do that, and I told, in one of the paragraphs, about the case it isn't possible to reproduce the bug. So that what I suggest. Let's decide that my proposition isn't rejected yet, but just stalled. I'll search for a good example or examples, in a day or a year, and then answer again in this thread. Maybe that will convince you. Or me. Thank you very much for now, Igal On Sep 24, 2017 12:10, "Moriel Schottlender" <moriel(a)gmail.com> wrote: I see your idea here, Igal, but I don't think it's necessary. Developers usually have pretty good tools to see where a bug came from (for example, we have a tool called "git bisect"[1] that allows us to analyze not just which release the bug was introduced in, but a specific commit to "blame" for the change. We use it rarely, though, because usually a ticket with good information about the bug is enough. If you report a bug telling us what browser you've used, what you did, precisely (clicked on X, opened Y, looked at feature Z, typed A, etc etc) and where (what page, what wiki, etc) then we usually are pretty good at pinpointing the issue, and if we're not, we tend to know what to look for and ask the user for more information. When we run into trouble understanding a bug, it is rarely due to knowing whether it is the new release or not. It's usually other factors that are (usually) a lot more important for us to know, like any gadgets that a user has, or some browser extension, or some edge case we need to figure out how to reach. From my experience (and I think, from the comments on the thread, from other devs experiences too) the "which release this came from" is less of an issue. I think having another wiki to maintain versions for (there's still a cost for this in terms of maintenance and time, etc) is unnecessary for these points you raise... Did you encounter specific times where a developer couldn't figure out a bug because they didn't know whether it was old or new? It might be that the issue has a different cause, and we can tackle this challenge differently for a good solution. [1] https://git-scm.com/docs/git-bisect On Fri, Sep 22, 2017 at 5:29 AM, יגאל חיטרון <khitron(a)gmail.com> wrote: first 5 found, of X" the about, -- No trees were harmed in the creation of this post. But billions of electrons, photons, and electromagnetic waves were terribly inconvenienced during its transmission! _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l