7 Nov
2015
7 Nov
'15
5:11 p.m.
Hi devs,
As you know our goal is to use myxwiki.org as a real life test platform to validate
releases of XWiki.
Current Situation
==================
However this is currently not working very well for 2 reasons:
1) We’re always lagging behind on the version installed on myxwiki.org. Right now it’s
7.1.2 and our last released version is 7.3M2. Thus if we notice a problem on myxwiki.org,
it’ll be fixed only in much later versions and myxwiki.org is not playing its role of
helping validate releases before we release final versions.
2) We don’t really monitor the performance of myxwiki.org.
3) We don’t really analyse issues that can happen on it because we don’t check the logs.
Thus I think we need to find a better process for benefitting from myxwiki.org.
Question
=========
Are we still interested in benefitting from myxwiki.org for testing our releases?
If not, then stop reading at this point :)
If we are, then I’m making some proposals below.
Proposal
=========
For 1):
I’d like to propose to add a step in our ReleasePlan template as the last step:
- Check the myxwiki.org upgrade roster and ping the next person to update myxwiki.org
So the idea would be to not make the RM do the upgrade since he/she already has a lot to
do to release XWiki but to make him/her responsible for pinging someone to do it. Then we
would take turn to upgrade it (in a similar fashion as we do for releasing XWiki).
Note that I believe this would also make us work on making it simpler to perform XWiki
upgrades and this would benefit our users. We would eat our own dog food basically :)
For 2):
Here are ideas of what we could monitor and receive alerts when they go beyond a given
threshold:
- the average response times users get on it,
- when a specific requests takes more than N seconds (this would also allow us to find
wiki pages written by our users and which take too much CPU thus making the farm slower
than it should be),
- its uptime
- the memory used
For 3):
I think we could set up some elastic search/kibana solution as we had set up at some point
(this makes it nice to browse and search for logs) and then send automatic mails to the
devs list or IRC when exception happen. This would have the nice benefit of making us work
on fixing the code and not generating exceptions when we have only warnings that don’t
impact the stability of the platform.
WDYT?
If we agree, then we’ll need to discuss how to setup 2 and 3.
Thanks
-Vincent
8 Nov
8 Nov
12:49 p.m.
+1
On Sat, Nov 7, 2015 at 5:11 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:
Hi devs,
As you know our goal is to use myxwiki.org as a real life test platform to validate
releases of XWiki.
Current Situation
==================
However this is currently not working very well for 2 reasons:
1) We’re always lagging behind on the version installed on myxwiki.org. Right now it’s
7.1.2 and our last released version is 7.3M2. Thus if we notice a problem on myxwiki.org,
it’ll be fixed only in much later versions and myxwiki.org is not playing its role of
helping validate releases before we release final versions.
2) We don’t really monitor the performance of myxwiki.org.
3) We don’t really analyse issues that can happen on it because we don’t check the logs.
Thus I think we need to find a better process for benefitting from myxwiki.org.
Question
=========
Are we still interested in benefitting from myxwiki.org for testing our releases?
If not, then stop reading at this point :)
If we are, then I’m making some proposals below.
Proposal
=========
For 1):
I’d like to propose to add a step in our ReleasePlan template as the last step:
- Check the myxwiki.org upgrade roster and ping the next person to update myxwiki.org
So the idea would be to not make the RM do the upgrade since he/she already has a lot to
do to release XWiki but to make him/her responsible for pinging someone to do it. Then we
would take turn to upgrade it (in a similar fashion as we do for releasing XWiki).
Note that I believe this would also make us work on making it simpler to perform XWiki
upgrades and this would benefit our users. We would eat our own dog food basically :)
For 2):
Here are ideas of what we could monitor and receive alerts when they go beyond a given
threshold:
- the average response times users get on it,
- when a specific requests takes more than N seconds (this would also allow us to find
wiki pages written by our users and which take too much CPU thus making the farm slower
than it should be),
- its uptime
- the memory used
For 3):
I think we could set up some elastic search/kibana solution as we had set up at some
point (this makes it nice to browse and search for logs) and then send automatic mails to
the devs list or IRC when exception happen. This would have the nice benefit of making us
work on fixing the code and not generating exceptions when we have only warnings that
don’t impact the stability of the platform.
WDYT?
If we agree, then we’ll need to discuss how to setup 2 and 3.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
9 Nov
9 Nov
4:14 p.m.
+1, definitely.
Thanks,
Eduard
On Sun, Nov 8, 2015 at 1:49 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
+1
On Sat, Nov 7, 2015 at 5:11 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi devs,
As you know our goal is to use myxwiki.org as a real life test platform
to
validate releases of XWiki.
Current Situation
==================
However this is currently not working very well for 2 reasons:
1) We’re always lagging behind on the version installed on myxwiki.org.
Right now
it’s 7.1.2 and our last released version is 7.3M2. Thus if we
notice a problem on myxwiki.org, it’ll be fixed only in much later
versions and myxwiki.org is not playing its role of helping validate
releases before we release final versions.
2) We don’t really monitor the performance of myxwiki.org.
3) We don’t really analyse issues that can happen on it because we don’t
check the
logs.
Thus I think we need to find a better process for benefitting from
myxwiki.org.
Question
=========
Are we still interested in benefitting from myxwiki.org for testing our
releases?
If not, then stop reading at this point :)
If we are, then I’m making some proposals below.
Proposal
=========
For 1):
I’d like to propose to add a step in our ReleasePlan template as the
last step:
- Check the myxwiki.org upgrade roster and ping
the next person to
update myxwiki.org
So the idea would be to not make the RM do the upgrade since he/she
already has a
lot to do to release XWiki but to make him/her responsible
for pinging someone to do it. Then we would take turn to upgrade it (in a
similar fashion as we do for releasing XWiki).
Note that I believe this would also make us work on making it simpler to
perform
XWiki upgrades and this would benefit our users. We would eat our
own dog food basically :)
For 2):
Here are ideas of what we could monitor and receive alerts when they go
beyond a
given threshold:
- the average response times users get on it,
- when a specific requests takes more than N seconds (this would also
allow us to
find wiki pages written by our users and which take too much
CPU thus making the farm slower than it should be),
- its uptime
- the memory used
For 3):
I think we could set up some elastic search/kibana solution as we had
set up at
some point (this makes it nice to browse and search for logs) and
then send automatic mails to the devs list or IRC when exception happen.
This would have the nice benefit of making us work on fixing the code and
not generating exceptions when we have only warnings that don’t impact the
stability of the platform.
WDYT?
If we agree, then we’ll need to discuss how to setup 2 and 3.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:17 p.m.
+1 for final versions
Thanks,
Caty
On Mon, Nov 9, 2015 at 5:14 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
+1, definitely.
Thanks,
Eduard
On Sun, Nov 8, 2015 at 1:49 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com
wrote:
> +1
> On Sat, Nov 7, 2015 at 5:11 PM,
vincent(a)massol.net <vincent(a)massol.net>
> wrote:
> > Hi devs,
> > > As you know our goal is to
use myxwiki.org as a real life test
platform
> to validate releases of XWiki.
> > > Current Situation
> > ==================
> > > However this is currently
not working very well for 2 reasons:
> > > 1) We’re always lagging
behind on the version installed on myxwiki.org
.
> Right now it’s 7.1.2 and our last released version is 7.3M2. Thus if we
> notice a problem on myxwiki.org, it’ll be fixed only in much later
> versions and myxwiki.org is not playing its role of helping validate
> releases before we release final versions.
> > > 2) We don’t really monitor
the performance of myxwiki.org.
> > > 3) We don’t really analyse
issues that can happen on it because we
don’t
> check the logs.
> > > Thus I think we need to
find a better process for benefitting from
> myxwiki.org.
> > > Question
> > =========
> > > Are we still interested in
benefitting from myxwiki.org for testing
our
> releases?
> > > If not, then stop reading
at this point :)
> > If we are, then I’m making some proposals below.
> > > Proposal
> > =========
> > > For 1):
> > > I’d like to propose to add
a step in our ReleasePlan template as the
> last step:
> > - Check the myxwiki.org upgrade roster and ping the next person to
> update myxwiki.org
> > > So the idea would be to not
make the RM do the upgrade since he/she
> already has a lot to do to release XWiki but to make him/her responsible
> for pinging someone to do it. Then we would take turn to upgrade it (in a
> similar fashion as we do for releasing XWiki).
> > > Note that I believe this
would also make us work on making it simpler
to
> perform XWiki upgrades and this would benefit our users. We would eat our
> own dog food basically :)
> > > For 2):
> > > Here are ideas of what we
could monitor and receive alerts when they go
> beyond a given threshold:
> > - the average response times users get on it,
> > - when a specific requests takes more than N seconds (this would also
> allow us to find wiki pages written by our users and which take too much
> CPU thus making the farm slower than it should be),
> > - its uptime
> > - the memory used
> > > For 3):
> > > I think we could set up
some elastic search/kibana solution as we had
> set up at some point (this makes it nice to browse and search for logs)
and
> > WDYT?
> > > If we agree, then we’ll
need to discuss how to setup 2 and 3.
> > > Thanks
> > -Vincent
> > >
_______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
then send automatic mails to the devs list or IRC
when exception happen.
This would have the nice benefit of making us work on fixing the code and
not generating exceptions when we have only warnings that don’t impact
the
> stability of the platform.
>
4:24 p.m.
+1
Thanks,
Marius
On Sat, Nov 7, 2015 at 6:11 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi devs,
As you know our goal is to use myxwiki.org as a real life test platform
to validate releases of XWiki.
Current Situation
==================
However this is currently not working very well for 2 reasons:
1) We’re always lagging behind on the version installed on myxwiki.org.
Right now it’s 7.1.2 and our last released version is 7.3M2. Thus if we
notice a problem on myxwiki.org, it’ll be fixed only in much later
versions and myxwiki.org is not playing its role of helping validate
releases before we release final versions.
2) We don’t really monitor the performance of myxwiki.org.
3) We don’t really analyse issues that can happen on it because we don’t
check the logs.
Thus I think we need to find a better process for benefitting from
myxwiki.org.
Question
=========
Are we still interested in benefitting from myxwiki.org for testing our
releases?
If not, then stop reading at this point :)
If we are, then I’m making some proposals below.
Proposal
=========
For 1):
I’d like to propose to add a step in our ReleasePlan template as the last
step:
- Check the myxwiki.org upgrade roster and ping the next person to update
myxwiki.org
So the idea would be to not make the RM do the upgrade since he/she
already has a lot to do to release XWiki but to make him/her responsible
for pinging someone to do it. Then we would take turn to upgrade it (in a
similar fashion as we do for releasing XWiki).
Note that I believe this would also make us work on making it simpler to
perform XWiki upgrades and this would benefit our users. We would eat our
own dog food basically :)
For 2):
Here are ideas of what we could monitor and receive alerts when they go
beyond a given threshold:
- the average response times users get on it,
- when a specific requests takes more than N seconds (this would also
allow us to find wiki pages written by our users and which take too much
CPU thus making the farm slower than it should be),
- its uptime
- the memory used
For 3):
I think we could set up some elastic search/kibana solution as we had set
up at some point (this makes it nice to browse and search for logs) and
then send automatic mails to the devs list or IRC when exception happen.
This would have the nice benefit of making us work on fixing the code and
not generating exceptions when we have only warnings that don’t impact the
stability of the platform.
WDYT?
If we agree, then we’ll need to discuss how to setup 2 and 3.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3661
days inactive
3663
days old
4 comments
5 participants
participants (5)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net