xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Proposal] Postpone the XWiki 8.3 release

by Vincent Massol

Hi devs, Today is release day for 8.3. I’d like to postpone it to tomorrow the 11th so that we can fix http://jira.xwiki.org/browse/CKEDITOR-113 which is a blocker. I started debugging over the week end. I’d need some help though since I’m far from sure I’ll be able to fix it by myself. Would be great if at least one other dev could work on trying to fix it too at the same time. WDYT? Thanks -Vincent

8 years, 3 months

[xwiki-devs] [XWiki Day] BFD#121

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#121: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 54 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#121 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13697 Happy Bug Fixing Day, Alex

8 years, 3 months

Re: [xwiki-devs] [xwiki-users] Fw : Re: Issues when I upgraded my xwiki 7.0.1 to xwiki 8.2.1: search feature

by Sergiu Dumitriu

Something like this: https://github.com/phenotips/phenotips/blob/b5fd2933480bcdeaca0194840b1c845… On 10/04/2016 05:56 AM, Vincent Massol wrote: > >> On 04 Oct 2016, at 11:54, Pascal BASTIEN <pbasnews-xwiki(a)yahoo.fr> wrote: >> >> Thanks, you are right I forgot to removed solr subdirectory before upgrade. >> >> stop + rm + start xwiki = xwiki work again like a charm >> (sorry ;-) ) > > cool > > you don’t need to be sorry. We need to improve this. Like forcing automatically the removal when we upgrade solr and there’s been some schema changes. > > -Vincent > >> Thxs >> >> --- En date de : Mar 4.10.16, Vincent Massol <vincent(a)massol.net> a écrit : >> >>> De: Vincent Massol <vincent(a)massol.net> >>> Objet: Re: [xwiki-users] Issues when I upgraded my xwiki 7.0.1 to xwiki 8.2.1: search feature >>> À: "XWiki Users" <users(a)xwiki.org> >>> Date: Mardi 4 octobre 2016, 11h36 >>> Hi, >>> >>> Try removing your solr index. >>> >>> Thanks >>> -Vincent >>> >>>> >>> On 04 Oct 2016, at 11:26, Pascal BASTIEN <pbasnews-xwiki(a)yahoo.fr> >>> wrote: >>>> >>>> Hello, >>>> >>>> After upgrading my >>> xwiki 7.0.1 to 8.2.1, i encoutered another issue: xwiki >>> search feature doesn't work anymore. >>>> I use Tomcat 8.0.33 + Postrgesqk 9.3 and >>> attachments in file system and connected with Admin >>> account. >>>> >>>> On page >>> ./bin/view/Main/Search?text=test&f_type=DOCUMENT&f_locale=fr&f_locale=&r=1 >>> , I have this ugly error message displayed: >>>> "Failed to execute the [velocity] >>> macro. Cause: [The resolver parameter doesn't contain an >>> Entity Reference of type [SPACE]]. Click on this message for >>> details." >>>> >> _______________________________________________ >> users mailing list >> users(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > users(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > -- Sergiu Dumitriu http://purl.org/net/sergiu

8 years, 3 months

[xwiki-devs] [PROPOSAL] Stabilize filesystem templates rights

by Thomas Mortagne

Hi devs, Right now (and since forever) the default behavior for templates is to be executed with the right of the current document content author (it's not really explicit, it's just how PR works when there is no sdoc). This means that unless you explicitly indicate an author for your template (possible since 7.x) you don't really have any idea which right it's going to have at runtime. It also make harder to properly execute templates outside of main rendering thread where the "current document" often don't really make much sense. I think we should make the default more stable. I can think of two possibilities: 1) with what we got right now the only real possibility is to execute the filesystem template with superadmin right (which is only an option right now). Makes it consistent with the "code is executed with the right of its author" rule we have for wiki pages 2) introduce some new virtual user (like "templateauthor" or "scripter" or whatever) which only have script right and use that as filesystem template author if we absolutely want template to not have too many rights by default (even if modifying a filesystem template require much more access than superadmin in practice) +1 for 1) -- Thomas Mortagne

8 years, 3 months

[xwiki-devs] [Brainstorming] Disable install count on exo for extensions bundled in XE?

by Vincent Massol

Hi devs, Question: do we agree to disable "show active installs" for extensions bundled in XE on e.x.o? (if I remember correctly that's why thomas introduced this checkbox but I want to make sure we have the same opinion) The idea is not to drown the install figures with bundled extensions which are not chosen by users (they get them by default). Right now we still have a few extensions that are bundled and have their install count displayed. I can fix it but I want to make sure first. Also we need to decide what to do with contrib extensions bundled in XE. For example: - Tour app - CKEditor - Templates app I think we should also disable their active install count, following the same rule, even though they can also be installed by themselves in older versions of XE. WDYT? To see it: http://extensions.xwiki.org/xwiki/bin/view/Extension/#|t=extensions&p=1&l=3… Thanks -Vincent

8 years, 3 months

[xwiki-devs] [Contrib][BatchImport] Release of batch import application version 1.2

by Anca Luca

Hello all, Alex and I have fixed a couple of issues on the batch import application (issues BATCHIMP-1,2,3,4,5,6) and I would like to release version 1.2 of this application. Functionally, these changes bring translations being properly activated when the app is installed, one more option configurable from the UI (clear names) and some support for the new format of AWM (the nested spaces one). It does not break compatibility, as I managed to write code that should work fine in all cases (nested or not). If nobody has anything against, I will release this tonight. Thanks a lot, Anca

8 years, 3 months

[xwiki-devs] [Proposal] 2 new rules for Application Best Practices

by vincent＠massol.net

Hi devs, Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… 1) New rule 1: “Code” subspace Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code” Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this. 2) New rule 2: * Technical pages without children must be terminal pages. WDYT? Thanks -Vincent

8 years, 3 months

[xwiki-devs] [XWiki Day] BFD#120

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#120: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 49 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#120 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13696 Happy Bug Fixing Day, Alex

8 years, 3 months

[xwiki-devs] [VOTE] Change the release cycle to 1 month

by Vincent Massol

Hi devs, Executive summary: * Replace our 3 month release cycle by a 1 month release cycle. Needs and advantages: * Be able to get our changes faster to our users. Importantly, bugfixes are released faster to users. Note: it’s not because we release faster that our users have to upgrade as fast. They can skip some versions if they want/need. * Be able to get more feedback more quickly from users. Right now, most (if not all) of our users are testing only final versions. They’re not testing milestones or RCs and thus we usually only know about problems after the final has been released and we incorporate the change in the next one (to be released 3 months later) or we have to do a bugfix release. * Get closer to cloud needs. Nowadays, could offerings happen more and more and operating a cloud means bringing improvements and fixes as fast as possible. Some software in the cloud are even updated/patched several times per day. We’re not there yet but we’re trying to get closer by reducing from 3 months to 1 month * This also means more marketing for the xwiki project since other site relay the new whenever a final version is released Proposal Details: * 1 month split in: 3 weeks to release a RC + 1 week to release the final version. It’s very important to keep the RC as a meeting point and ensuring all is going to be ready on time for the final release (jiras are closed or moved to the next release, CI is passing, documentation and RN are ready, etc). * Split large features into smaller chunks. It doesn’t matter if some code is released but unused for example (provided the build is passing). For larger refactoring that absolutely cannot be split into 3 weeks chunks (I’m not sure that really exists) then we can use branches (and create a CI job to ensure integration). * Less need for bugfix releases of stable versions. For LTS it’s still required though. * Note that this 1 month release strategy will not generate more releases (and thus more work) over the year since we’re already releasing every 2-3 weeks ATM (milestones, RCs, et) * Version Naming: from N.0 to N.10 where N is the cycle name. The reason for 11 releases and not 12 is to account for slippages + potential bugfix release at the end of the cycle for stabilization + holidays. We might even be able to do only 10 releases and not 11 but I’m suggesting we try with 11 for now. When: * I’m proposing to start this process with the 8.4 release (starting on the 10th of October). Since that version is already supposed to be a stabilization release (and thus a short 1 month release) it’s not going to change anything. We should also do bugfix releases after 8.4 is releases: 8.4.1, 8.4.2, etc till the end of the year * Then starting 9.0 we really start doing 1 month releases. WDYT? Here’s my +1 to try this. Thanks -Vincent

8 years, 3 months

Re: [xwiki-devs] [Proposal] Change the default logo in the XWiki Enterprise default color theme

by Benjamin Lanciaux

Hi devs, I would like to propose a new logo for the default color theme of XE. Instead of having the colored version of the XWiki logo, I propose using its white version. I see many advantages to this: * On a black banner, it is easier to see the XWiki brand compared to the colored one for which I barely see the "X". * This would also be more consistent with the other menu options that are placed on the black banner. See how it looks like now: http://imgur.com/a/ZzEOY And see how it would look like with my proposal: http://imgur.com/a/MF0r6 I'm looking forward to your feedback, Regards, Benjamin Lanciaux

8 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs