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:
If you don't have access to old mediawiki version
(whether it is group2,
your own wiki or test3wiki suggested above),
and suspects there is a regression of something that was working in the
past,
it is useful to indicate it in the bug description, and the maintainer of
that feature can check it out
(either by indications from git log with relevant commit messages, or by
restoring to older code)
You can also go over the commits log using web interface:
https://github.com/wikimedia/mediawiki/commits/master
and as Niharika said there are a lot of new changes :)
While this is static (compared to running mediawiki instance) it as its own
advantages:
You can find out who is the owner (blame), related bugs (usually "Bug: X"
in commit message) etc
On Fri, Sep 22, 2017 at 8:27 AM, Niharika Kohli <nkohli(a)wikimedia.org>
wrote:
When filing a phab task with some new bug,
you always want to know - is it really new, or I just did not pay
attention
to it before?
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
in the same time, and compare the behaviour for
this bug. And also,
compare
the console results - what exactly changed in
html, in css, in js
commands
reactions.
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:
> It can work. But another Monday. I mean, if Tue-Wed-Thu there is a
> deployment of version ....5, a day before, Mon there is a deployment of
> version ....4, so starting from tomorrow, group 0 will get a way to
see
> both version, exactly from the beginning,
but not until the end, for 6
> days, group 1 for 5 days, and group 2 for 4 days. And from Monday to
the
> deployment, 1-2-3 days, there will not be
use of this. I'll be very
glad
if
> it will be decided to do this, and if so, it will be a good thing to
add
to
> the text of how to report a bug in phabricator help, something about,
you
can check
if it is a regression, the last version "falt", by comparing
with
> this new wiki. I can thing about many dozens of tasks I wrote and read
> where this information could be useful, if added at the first place.
Hope
> you decide this indeed. Thank you very
much,
> Igal
>
>
> On Sep 22, 2017 05:17, "Chad" <innocentkiller(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:
> >
> > > I glad you say so. What about Friday?
> > > Igal
> > >
> > >
> > > On Sep 22, 2017 05:07, "Chad" <innocentkiller(a)gmail.com>
wrote:
> > >
> > > > 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:
> >
> > > 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:
> > > > > Thank you. Sorry to hear this. Is there some place I can
suggest
> this
> > > and
> > > > > explain why do I think it can be very helpful?
> > > > > Igal
> > > > >
> > > > > On Sep 21, 2017 22:12, "Brian Wolff"
<bawolff(a)gmail.com>
wrote:
> > > > >
> > > > >> On Thursday, September 21, 2017, יגאל חיטרון <
> > khitron(a)post.bgu.ac.il>
> > > > >> wrote:
> > > > >> > Hi. Sometimes after the week deployment I need to
compare
the
> > new
> > > > > version
> > > > > >> > with the previous one, in some aspect. Is there a
test
wiki
that
> > > > always
> > > > >> has
> > > > >> > one version before the current?
> > > > >> > Thank you.
> > > > >> > Igal (User:IKhitron)
> > > > >> > _______________________________________________
> > > > >> > Wikitech-l mailing list
> > > > >> > Wikitech-l(a)lists.wikimedia.org
> > > > >> >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > > >>
> > > > >> No there is not. You can of course download old versions of
the
> >
software
> > > >> and setup your own wiki but that is a lot of effort.
> > > >>
> > > >> --
> > > >> bawolff
> > > >> _______________________________________________
> > > >> Wikitech-l mailing list
> > > >> Wikitech-l(a)lists.wikimedia.org
> > > >>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > > _______________________________________________
> > > > Wikitech-l mailing list
> > > > Wikitech-l(a)lists.wikimedia.org
> > > >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > Wikitech-l(a)lists.wikimedia.org
> > >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Niharika
Software Engineer
Community Tech
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l