12 Nov
2018
12 Nov
'18
2:44 p.m.
On 8 Nov 2018, at 17:12, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
On Fri, Sep 21, 2018 at 5:19 PM Vincent Massol <vincent(a)massol.net> wrote:
Thanks Caty for working on this. Plenty of things, probably too many :)
Would be great to have a top 5 of must urgents points and make sure to have a jiras for
them.
They could be good contenders for next year for the 11.x cycle.
Thanks
-Vincent
Thanks Caty.
See below
https://design.xwiki.org/xwiki/bin/download/Proposal/Upgrade/SimplerUpgrade…
https://design.xwiki.org/xwiki/bin/view/Proposal/Upgrade/SimplerUpgrade/Fee… On 21 Sep 2018, at 15:56, Ecaterina Moraru
(Valica) <valicac(a)gmail.com>
wrote:
Hi devs,
I've heard that the upgrade process is a complicated process and relies
on
a lot of manual operations. I haven't
investigated the technical
solutions
we have at our disposal, but I tried to image the
desired UI an
Administrator would want when upgrading:
* be notified that a new version is available:
https://design.xwiki.org/xwiki/bin/download/Proposal/Upgrade/SimplerUpgrade…
* have an upgrade section in Administration where Distribution and
Extensions can be checked for new versions and upgraded / backed:
https://design.xwiki.org/xwiki/bin/download/Proposal/Upgrade/SimplerUpgrade…
A more detailed proposal at
https://design.xwiki.org/xwiki/bin/view/Proposal/Upgrade/SimplerUpgrade/
So, what are your thoughts on this?
Some thoughts:
1) Automatic distribution upgrade would be very nice but it’s hard to do
for all packagings. We already do it for the debian one (apt-get upgrade)
and we could do it better for some others (docker, standalone). However for
the manual WAR install it’s harder and I don’t even know if it’s possible
(at least for all supported servlet containers). One idea would be to
implement it for Tomcat only for example and have a way to control the
tomcat manager (manager app) to perform the upgrade of the webapp.
1a) Would be nice to have a a distribution upgrade UI too for merging the
various configuration files (could be a separate webapp for ex - haven’t
really thought about this).
1b) For the docker upgrade we can look at the discourse upgrade process,
to see if there are some good ideas to reuse
2) We have comments about the DW being hard to understand/complex. You
haven’t addressed this. Is it because you didn’t find anything to improve?
3) We regularly see users having problems to upgrade (cf forum, irc,
mailing lists) and we’d need to list the common issues they have. Their
problems may not be related to the UI but to bugs/limitations we currently
have.
Here is a list containing feedback about upgrades from
2017 and 2018 found
in various testimonials, surveys, reported issues, top issues, user
interviews, support and forum entries.
I've listed ideal features, improvements suggestions and bugs our users
encountered during upgrades during this period, also mentioning from what
version to what version they've encountered the problem and related issues
reported regarding the problem.
Take a look at them and see what you think. There are also some suggested
action to take for the problems.
Thomas suggested that I could make design proposals for:
1. Invalid extensions step: step in DW that display the invalid extensions
and ask the user to remove them.
or
2. Environment validation step: step in the beginning of DW that validates
the configuration found locally and suggest improvements in order for the
instance to work properly.
WDYT?
Thanks,
Caty
>
> 4) A typical known issue is when the user skips/clicks “never” on the DW.
> He cannot get it to appear afterwards. We will need to fix this usability
> issue for ex.
>
> Thanks
> -Vincent
>
>
>>
>> Thanks,
>> Caty