Another 66 relations bite the dust

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Another 66 relations bite the dust

Richard Fairhurst
Someone seems to have decided to answer the question about "how should
we tag the National Byway" by deleting it. :(

In http://www.openstreetmap.org/browse/changeset/4653538 , a vast number
of relations have been deleted - 66 or so. Among these are a bunch of
cycle routes - the National Byway (id 9327, previously with 893 relation
members), NCN route 74, the Caledonian Cycleway - plus some railway
routes and the usual NAPTaN gubbins. I restored the National Byway
before noticing the rest of them; now, I guess, it would be helpful to
rollback the rest of the changeset.

The user has done lots of really good edits so I'm 100% sure that this
isn't vandalism.

The created_by is JOSM 1.5 (3094 en). This roughly echoes:
   http://lists.openstreetmap.org/pipermail/josm-dev/2010-March/004228.html
   http://lists.openstreetmap.org/pipermail/josm-dev/2010-April/004276.html

although, in this case, the relations have been deleted rather than
'blanked'. I think all of the relations in question passed through

As per the first cited message, I don't want to get into an editor
argument here, but I do know from bitter experience that if Potlatch let
you do this without realising, there would have been people screaming
for my head for months now.

Deleting a relation with 900ish members is almost always going to be an
error. Obviously we don't yet know what's happened here, but I think we
can safely assume that the user wasn't presented with a dialogue reading
"Are you really really sure you want to delete an entire chuffing cycle
route along 900 roads?" and a button "HELL YES!".

Could I entreat the JOSM developers to put some serious effort into
identifying and fixing this at the very earliest opportunity?

cheers
Richard

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Dirk Stöcker
On Mon, 10 May 2010, Richard Fairhurst wrote:

> The created_by is JOSM 1.5 (3094 en). This roughly echoes:

JOSM 3094 is no longer current. It's 2 months old. Newer tested versions
with many bugfixes are 3 weeks old. This is plenty of time for updating.

I'm pretty sure we fixed that bug, but as it is not reproducable anymore
we can't be sure.

> Deleting a relation with 900ish members is almost always going to be an
> error. Obviously we don't yet know what's happened here, but I think we
> can safely assume that the user wasn't presented with a dialogue reading
> "Are you really really sure you want to delete an entire chuffing cycle
> route along 900 roads?" and a button "HELL YES!".

We display a "this is what you do" before each upload. Separated in
add/modify/delete sections. Especially the delete section should always
be inspected critical. Lots of efforts have been put into presenting this
information in a way, so that users have a good chance to understand it.

> As per the first cited message, I don't want to get into an editor
> argument here, but I do know from bitter experience that if Potlatch let
> you do this without realising, there would have been people screaming
> for my head for months now.

Well, Potlatch deleted every German name in Saxonia for one user when he
entered the Sorbian names. Was a lot of work to fix this as well (as he
did do multiple changesets). I still found two missing ones yesterday,
after nearly half a year.

This was probably as well an error which was fixed inbetween and never
reported. These things happen.

> Could I entreat the JOSM developers to put some serious effort into
> identifying and fixing this at the very earliest opportunity?

I don't see any sense in trying to fix an unreproducable and very likely
already fixed issue.

I can't force people to use newer josm version. We have still a large
number of old version (6 to 12 months old) floating around.

If this is really an issue, then maybe the API should block older versions
known to cause trouble as it already did in the past.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Richard Fairhurst
In reply to this post by Richard Fairhurst
Dirk Stöcker wrote:
> If this is really an issue, then maybe the API should block older versions
> known to cause trouble as it already did in the past.

Yes, maybe it should.

But as a first resort, I'd encourage you to look at improving your
presentation. I have JOSM 3094 and all that it tells me about upgrading
is this (as the third item on the splash screen):

"Active version '3094' should be updated! The current stable snapshot is
3208 and 3227 is the unstable development version."

...which is a really obscure statement likely to elicit "meh, whatever"
from most non-developer users. What's an "Active version '3094'" when
it's at home? What's a "stable snapshot" - a photograph of a horse? (And
why the passive voice? Computer says it "should be updated". Well, jolly
good, Mr Computer, go and update it then.)

If, instead, it said as the _first_ thing on the page:

"You are using an old version of JOSM with known bugs. Click here to
download the latest version. This old version will stop working in five
days."

then maybe we would get somewhere. But the fact that you say "We still
have a large number of old version (6 to 12 months old) floating around"
shows that the current approach isn't working.



> Well, Potlatch deleted every German name in Saxonia for one user when he
> entered the Sorbian names. Was a lot of work to fix this as well (as he
> did do multiple changesets). I still found two missing ones yesterday,
> after nearly half a year.

If you can cite changeset/object ids I'll look into it.

cheers
Richard

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Sebastian Klein
In reply to this post by Richard Fairhurst
Richard Fairhurst wrote:
> ...
> I don't want to get into an editor argument here

Right, don't start a fight you can't win. :)

> In http://www.openstreetmap.org/browse/changeset/4653538 , a vast
> number of relations have been deleted - 66 or so.

In potlatch I didn't manage to delete a _single_ relation, so this
clearly is a big plus for JOSM.

> , but I do know from bitter experience that if Potlatch let you do
> this without realising, there would have been people screaming for my
>  head for months now.

For some reason it's quite popular to pick on potlatch (especially in
Germany), don't take it personal...

> Could I entreat the JOSM developers to put some serious effort into
> identifying and fixing this at the very earliest opportunity?

Have you talked to the user? If he remembers how it happened there might
be a tiny chance to identify the cause but otherwise there really isn't
much one can do about it. If we had more reports of this kind, it would
be a different matter.


Sebastian

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Richard Fairhurst
In reply to this post by Richard Fairhurst
Sebastian Klein wrote:
> Richard Fairhurst wrote:
>> I don't want to get into an editor argument here
>
> Right, don't start a fight you can't win. :)

:)

> Have you talked to the user? If he remembers how it happened there
> might be a tiny chance to identify the cause but otherwise there
> really isn't much one can do about it. If we had more reports of this
> kind, it would be a different matter.

I've mailed him, yes: no reply as yet but then it's early days.

But it appears to be a similar issue to these postings which posit
possible causes:
   http://lists.openstreetmap.org/pipermail/josm-dev/2010-April/004276.html
 
http://lists.openstreetmap.org/pipermail/talk-gb/2010-February/005359.html
 
http://lists.openstreetmap.org/pipermail/talk-gb/2010-February/005363.html
 
http://lists.openstreetmap.org/pipermail/talk-gb/2010-February/005368.html

FWIW I suspect it isn't a _bug_ as such, but rather that the UI is
unclear (at least to novice users) such that it is too easy for the user
to mistakenly delete/blank the relations. Again, deleting many (66)
relations that you haven't intentionally touched, or entirely deleting
large (893-member) relations, is likely to be an error in most
circumstances: the user should be made aware of what they're doing in
terms they are likely to understand.

cheers
Richard

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Dirk Stöcker
In reply to this post by Richard Fairhurst
On Mon, 10 May 2010, Richard Fairhurst wrote:

> But as a first resort, I'd encourage you to look at improving your
> presentation. I have JOSM 3094 and all that it tells me about upgrading
> is this (as the third item on the splash screen):
>
> "Active version '3094' should be updated! The current stable snapshot is
> 3208 and 3227 is the unstable development version."
>
> ...which is a really obscure statement likely to elicit "meh, whatever"
> from most non-developer users. What's an "Active version '3094'" when
> it's at home? What's a "stable snapshot" - a photograph of a horse? (And
> why the passive voice? Computer says it "should be updated". Well, jolly
> good, Mr Computer, go and update it then.)
>
> If, instead, it said as the _first_ thing on the page:
>
> "You are using an old version of JOSM with known bugs. Click here to
> download the latest version. This old version will stop working in five
> days."

I added a secondary more visible version check notice like you suggested.

Have a look at the start page yourself:

http://josm.openstreetmap.de/wiki/StartupPageSource

Improvements and suggestions welcome, it is a wiki.

> then maybe we would get somewhere. But the fact that you say "We still
> have a large number of old version (6 to 12 months old) floating around"
> shows that the current approach isn't working.

Nah. It suggests, that JOSM really is stable. The pressure to install new
versions is low, as old versions work really good (usually :-)

>> Well, Potlatch deleted every German name in Saxonia for one user when he
>> entered the Sorbian names. Was a lot of work to fix this as well (as he
>> did do multiple changesets). I still found two missing ones yesterday,
>> after nearly half a year.
>
> If you can cite changeset/object ids I'll look into it.

http://www.openstreetmap.org/browse/changeset/3349249

But as neither I nor the original author could reproduce it, I think it
was already fixed.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Dirk Stöcker
In reply to this post by Richard Fairhurst
On Mon, 10 May 2010, Richard Fairhurst wrote:

> FWIW I suspect it isn't a _bug_ as such, but rather that the UI is
> unclear (at least to novice users) such that it is too easy for the user
> to mistakenly delete/blank the relations. Again, deleting many (66)
> relations that you haven't intentionally touched, or entirely deleting
> large (893-member) relations, is likely to be an error in most
> circumstances: the user should be made aware of what they're doing in
> terms they are likely to understand.

Very likely. But we need a hint what the users do wrong. It's like the
"You moved xxx nodes at once, do you really want this". But we need a hint
where to add such a question (if it is still an issue with most recent).

JOSM has no old-state --> new-state possibility. We don't store the
original state of the database. Thus bigger changes can be the result of
some reworks and it may be hard to detect the valid and the invalid
cases, as you always only see the individual steps.

In the far future we have have something like this to reduce the number
of useless deleted objects and newly created objects (e.g. splitting a
way and deleting a part resulting in deleting old way and creating new
one) and to better keep history in database. But I don't expect anything
like this very soon.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Sebastian Klein
In reply to this post by Richard Fairhurst
Richard Fairhurst wrote:
> But it appears to be a similar issue to these postings which posit
> possible causes:
>    http://lists.openstreetmap.org/pipermail/josm-dev/2010-April/004276.html
>  
> http://lists.openstreetmap.org/pipermail/talk-gb/2010-February/005359.html

The first two links refer to the problem that a conflict on relations
can easily lead to removal of all members, so I guess it's a different
topic.

> http://lists.openstreetmap.org/pipermail/talk-gb/2010-February/005363.html
>  
> http://lists.openstreetmap.org/pipermail/talk-gb/2010-February/005368.html

These posts describe a well known problem [1], but no one came up with a
solution for it so far. With the current API it seems to be practically
impossible to have a complete list of referrers for all the objects in
the data set. This causes holes in route relations, but it shouldn't be
a 'relation killer'.

> FWIW I suspect it isn't a _bug_ as such, but rather that the UI is
> unclear (at least to novice users) such that it is too easy for the user
> to mistakenly delete/blank the relations. Again, deleting many (66)
> relations that you haven't intentionally touched, or entirely deleting
> large (893-member) relations, is likely to be an error in most
> circumstances: the user should be made aware of what they're doing in
> terms they are likely to understand.

Without good user feedback it's not easy to remove these traps.

But anyway, it shouldn't hurt to add some heuristics that detect unusual
pattern (like deleting a whole bunch of large relations) and give a
second warning before upload.


Sebastian

[1] http://trac.openstreetmap.org/ticket/2652

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Dirk Stöcker
On Mon, 10 May 2010, Sebastian Klein wrote:

> Without good user feedback it's not easy to remove these traps.
>
> But anyway, it shouldn't hurt to add some heuristics that detect unusual
> pattern (like deleting a whole bunch of large relations) and give a
> second warning before upload.

The problem is, that without a good idea what happend we will add
heuristics at wrong place and annoy users with useless warnings.

Whatever we think is strange, there will be people, who exactly use this
every day.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Roland Olbricht
In reply to this post by Sebastian Klein
> [1] http://trac.openstreetmap.org/ticket/2652

You can get an approximate solution:
http://78.46.81.38/api/rels-extended?id=34631
This points to the OSM3S server and returns the desired relation-ids for the
given relation id.

It's compressed XML at the moment, but I can change that to are more
appropriate format if the format is the problem. The second drawback is that
the server is some hours behind the main database, but most of the relations
mentioned here are days old or even older and would have been found by this
API call.

But still this would be a great step from deleting relations accidentally.

Incidentally, the server is down this evening from 22h15 to 12h00 tomorrow
because the server provider (Hetzner) is moving inside Germany.

Cheers,

Roland

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Richard Fairhurst
In reply to this post by Richard Fairhurst
I received a friendly reply from the mapper in question, who said:

> I think the problem was caused because as I going through the process
> of adding a new road, I had assumed that the relations shown in the
> JOSM editor were being applied to the new road. However, as the road
> was not part of NCN route 74, I deleted the data. Clearly, I
> shouldn't have done this and I'm very sorry for the problems I have
> now caused.

I can sort of see where he's coming from. So, again, it's (as so often
with OSM) probably more a problem of documentation and UI than anything
else... which I think really emphasises Sebastian's point about "it
shouldn't hurt to add some heuristics that detect unusual pattern (like
deleting a whole bunch of large relations) and give a second warning
before upload".

I see your point, Dirk, about annoying users with useless warnings, but
you can usually get round this either with a "Don't show this again"
check-box, or by providing an advanced pref to disable the warning.

Thanks for all the helpful replies. :)

cheers
Richard

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Sebastian Klein
Richard Fairhurst wrote:
> I received a friendly reply from the mapper in question, who said:
>
>> I think the problem was caused because as I going through the process
>> of adding a new road, I had assumed that the relations shown in the
>> JOSM editor were being applied to the new road. However, as the road
>> was not part of NCN route 74, I deleted the data. Clearly, I
>> shouldn't have done this and I'm very sorry for the problems I have
>> now caused.

Ah, I see, thanks for asking him.

> I see your point, Dirk, about annoying users with useless warnings,...

Yes, the annoying users are the main problem here... ;)


Sebastian

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Sebastian Klein
In reply to this post by Roland Olbricht
Roland Olbricht wrote:
>> [1] http://trac.openstreetmap.org/ticket/2652
>
> You can get an approximate solution:
> http://78.46.81.38/api/rels-extended?id=34631 This points to the
> OSM3S server and returns the desired relation-ids for the given
> relation id.


> But still this would be a great step from deleting relations
> accidentally.

No, this particular problem generally does *not* cause accidental
deletion of relations!

The worst that can happen is someone splits a way and does not add the
new part into the relation (because he does not know about it). Then a
multipolygon is no longer closed and does not render ... something like
that.

Also, if the user operates inside the downloaded bbox, everything is
fine. The issue comes into play when editing boundaries and other large
scale objects.

Then, I'm not so sure if one of the main editors should depend on a
private third party server, to operate properly. (It may also generate a
lot of traffic for that person).

Another drawback is the delay. JOSM users are used to getting their data
in real time. It is a little hard to communicate: "You will always see
all parent relations in the list, *but* the object and the relation have
to be a couple of days old (and a certain server has to be accessible)".

So from my point of view it would be great to have a plugin that uses
this service, but for JOSM core we should try to get this working
working with the main server.


Sebastian

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Alan Mintz
In reply to this post by Dirk Stöcker
At 2010-05-10 06:02, =?ISO-8859-15?Q?Dirk_St=F6cker?= wrote:

>On Mon, 10 May 2010, Richard Fairhurst wrote:
>
> > Deleting a relation with 900ish members is almost always going to be an
> > error. Obviously we don't yet know what's happened here, but I think we
> > can safely assume that the user wasn't presented with a dialogue reading
> > "Are you really really sure you want to delete an entire chuffing cycle
> > route along 900 roads?" and a button "HELL YES!".
>
>We display a "this is what you do" before each upload. Separated in
>add/modify/delete sections. Especially the delete section should always
>be inspected critical. Lots of efforts have been put into presenting this
>information in a way, so that users have a good chance to understand it.

Unfortunately, I think the same people that are more likely to accidentally
delete something big are the same people who will not pay attention to this
large dialog the way it is presented currently (i.e. it only helps the
people who don't need it).

Much like the warning dialog that pops up when you attempt to move a way
with more than x nodes, I think it would be helpful to ask for confirmation
before deleting or applying an edit to selections containing more than x
primitives.

I almost never correctly move an entire way, so when I see that warning
message, I pay attention to it (and usually undo).

OT: This is the kind of safety net that should be, but isn't, required on
trading systems in the US :(

--
Alan Mintz <[hidden email]>


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Frederik Ramm
Hi,

Alan Mintz wrote:
> OT: This is the kind of safety net that should be, but isn't, required on
> trading systems in the US :(

"Are you sure you want to bet the gross domestic product of a
medium-sized country on this?

[OK] [Cancel] [ ] Don't show this again, I am Richard S. Fuld"

Bye
Frederik

--
Frederik Ramm  ##  eMail [hidden email]  ##  N49°00'09" E008°23'33"

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Matthias Julius
In reply to this post by Sebastian Klein
Sebastian Klein <[hidden email]> writes:

> Roland Olbricht wrote:
>>> [1] http://trac.openstreetmap.org/ticket/2652
>>
>> You can get an approximate solution:
>> http://78.46.81.38/api/rels-extended?id=34631 This points to the
>> OSM3S server and returns the desired relation-ids for the given
>> relation id.
>
>> But still this would be a great step from deleting relations
>> accidentally.
>
> No, this particular problem generally does *not* cause accidental
> deletion of relations!
>
> The worst that can happen is someone splits a way and does not add the
> new part into the relation (because he does not know about it). Then a
> multipolygon is no longer closed and does not render ... something like
> that.
>
> Also, if the user operates inside the downloaded bbox, everything is
> fine. The issue comes into play when editing boundaries and other large
> scale objects.

A while ago I was toying with the idea of having JOSM track for each
primitive whether or not it knows about its parents.  AFAICT it should
only know with some certainty if the primitive was downloaded inside the
bounding box of a map call or if it has asked the API explicitly.  Then
it could show a message like:

This object might have parents that have not been downloaded from the
server and that might be affected by this operation. How do you want to
proceed?

<Cancel>  <Ignore>  <Download parents>

Optionally JOSM could also check the server automatically for parents.

Matthias

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Frederik Ramm
In reply to this post by Sebastian Klein
Hi,

Sebastian Klein wrote:
> But anyway, it shouldn't hurt to add some heuristics that detect unusual
> pattern (like deleting a whole bunch of large relations) and give a
> second warning before upload.

sub upload()
{
    applyHeuristics();
    if (unusualPatternDetected)
    {
       userAgent = "Potlatch";
    }
    proceedWithUpload();
}

Bye
Frederik


_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Sebastian Klein
In reply to this post by Matthias Julius
Matthias Julius wrote:

> Sebastian Klein <[hidden email]> writes:
>
>> Roland Olbricht wrote:
>>>> [1] http://trac.openstreetmap.org/ticket/2652
>>> You can get an approximate solution:
>>> http://78.46.81.38/api/rels-extended?id=34631 This points to the
>>> OSM3S server and returns the desired relation-ids for the given
>>> relation id.
>>> But still this would be a great step from deleting relations
>>> accidentally.
>> No, this particular problem generally does *not* cause accidental
>> deletion of relations!
>>
>> The worst that can happen is someone splits a way and does not add the
>> new part into the relation (because he does not know about it). Then a
>> multipolygon is no longer closed and does not render ... something like
>> that.
>>
>> Also, if the user operates inside the downloaded bbox, everything is
>> fine. The issue comes into play when editing boundaries and other large
>> scale objects.
>
> A while ago I was toying with the idea of having JOSM track for each
> primitive whether or not it knows about its parents.  AFAICT it should
> only know with some certainty if the primitive was downloaded inside the
> bounding box of a map call or if it has asked the API explicitly.  Then
> it could show a message like:
>
> This object might have parents that have not been downloaded from the
> server and that might be affected by this operation. How do you want to
> proceed?
>
> <Cancel>  <Ignore>  <Download parents>
>
> Optionally JOSM could also check the server automatically for parents.

Good idea, maybe it suffices to add a line in the bottom part of the
properties side dialogue. Something like "(possibly more)" in italics.
On click or right click it would offer to load the parents.

Sebastian

_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev
Reply | Threaded
Open this post in threaded view
|

Re: Another 66 relations bite the dust

Dirk Stöcker
In reply to this post by Dirk Stöcker
On Mon, 10 May 2010, Dirk Stöcker wrote:

> On Mon, 10 May 2010, Richard Fairhurst wrote:
>
>> But as a first resort, I'd encourage you to look at improving your
>> presentation. I have JOSM 3094 and all that it tells me about upgrading
>> is this (as the third item on the splash screen):
>>
>> "Active version '3094' should be updated! The current stable snapshot is
>> 3208 and 3227 is the unstable development version."
>>
>> ...which is a really obscure statement likely to elicit "meh, whatever"
>> from most non-developer users. What's an "Active version '3094'" when
>> it's at home? What's a "stable snapshot" - a photograph of a horse? (And
>> why the passive voice? Computer says it "should be updated". Well, jolly
>> good, Mr Computer, go and update it then.)
>>
>> If, instead, it said as the _first_ thing on the page:
>>
>> "You are using an old version of JOSM with known bugs. Click here to
>> download the latest version. This old version will stop working in five
>> days."
>
> I added a secondary more visible version check notice like you suggested.
Seems it helps. Very shortly after a new release we are already at 45%
newest tested, 27% last tested and approx 10% previous tested versions.
The old versions vanish step-by-step. Seems the large "UPDATE!" was
required. Probably we should increase text size to improve results :-)

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
josm-dev mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/josm-dev