After some discussion on IRC, the current plan for releasing 4.1-rc-1 and 4.1 has been determined
to be unworkable. The specific part at issue is the calling of a VOTE to release what is currently
in the staging repository and waiting 72 hours for it to be verified. While this provides the best
quality assurance, each blocker means another failed vote and another 72 hours + the time to fix
the issue and stage another release.
Proposal:
Stage the release 2 days before the official release date allowing blockers to be found and fixed.
Fix the issues and release the resulting build without any guaranteed testing window, hoping that
the patches to the earlier issues didn't introduce any regressions.
I don't like it much but it seems that it sucks less than all of the alternatives so +0 for me.
Caleb
Hi devs,
It seems we're loosing the race against bug reports:
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10000#Created-vs-R…
For the past 365 days there are have been 780 bugs reported and 692 resolved (gap of 88 bugs). The graph seems to indicate that the gap is increasing.
Should we organize a bug fixing day?
Any other idea?
Thanks
-Vincent
Hi devs,
Following Anca's comments on http://jira.xwiki.org/browse/XWIKI-6058 I
realized that the current document and the current wiki (database) are
completely independent: you can have "someWiki" as the current wiki
(context.setDatabase("someWiki")) and otherWiki:Space.Page as the
current document (document.setAsContextDoc(context)). This means that
it's not enough to set the current document if you want relative
references to be resolved relative to that document. You also need to
set the current wiki,
Is this the desired behaviour? Should setAsContextDoc also set the
current wiki? WDYT?
Thanks,
Marius
In order to try meet a release date, I would like to use the process as documented here:
http://dev.xwiki.org/xwiki/bin/view/Community/ReleasePlans#H4.1RC1
Synopsis:
June 4th:
* send 2 day warning mail, ask if anyone needs to block the release.
* branch stable-4.1.x to allow 4.2 development to continue.
June 6th:
* build staged release.
* send out call for testing.
* do release on jira with release post-dated to the 11th.
June 11th:
* release from staging.
* publish release.
I know this is a tight schedule but realistically we need 2 days for warning/stabilization
and 2 (working) days for testing.
WDYT?
Caleb
Hi devs,
Most of the devs know about the new xwiki-rendering engine which
provides the support for the new xwiki/2.x syntaxes, and the old
Radeox-based rendering engine which provides support for the xwiki/1.0
syntax, but I wonder who knows about the Oro-based wikiwiki engine that
provides support for an even older undocumented wiki syntax? That one
has been in the oldcore sources before I came in contact with XWiki, and
it has been disabled for a very long time.
One thing that we still use from that basic rendering engine is the
support for {pre}{/pre} code escaping, and that one will have to be
preserved even if we remove all the rest.
The advantages of removing it include:
- less ancient, unused, buggy code
-- thus slightly less PermGen memory required and faster startup
- one less Oro dependency (a long term goal is to remove Oro and ECS
from our dependencies)
- fewer WTFs from people stumbling over that code
Does anybody know of any users of that syntax? Is anybody still running
0.1.x versions?
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hello fellow developers,
it occurred to us that using a number followed by a dot then a tab character actually renders with a nested list and the word "null" is displayed.
Is this something known?
I could not find this on the bug base, we have opened:
http://jira.xwiki.org/browse/CURRIKI-5815
I'm fearing, as anything syntax 1.0 that fixing that is going to be quite delicate.
thanks for hints.
Paul