Thanks Denis for the feedback.
Done, it’s now deleted :)
The official image is now the first one… Come on xwiki users, let’s get this pull number increased now! (7 pulls already)
https://hub.docker.com/search/?isAutomated=0&isOfficial=0&page=1&pullCount=…
Thanks
-Vincent
> On 9 Feb 2017, at 13:48, Denis GERMAIN <dt.germain(a)gmail.com> wrote:
>
> Agreed,
>
> The longer you leave it, the longer people might use it instead of the
> official. As of today, the official isn't even the first to appear in the
> list when you search for xwiki in dockerhub (but I suspect this will soon
> change as people start pulling it).
>
> And people who already have pulled it won't be affected aside from the fact
> that they won't get updates, so no impact for them.
>
> Regards,
> Denis
>
> 2017-02-09 11:40 GMT+01:00 Vincent Massol <vincent(a)massol.net>:
>
>> Ok so now that we have an official xwiki image on dockerhub at
>> https://hub.docker.com/_/xwiki/ we need to decide what we do with
>> https://hub.docker.com/r/xwiki/xwiki-mysql-tomcat/
>>
>> I think we should remove it to avoid confusion.
>>
>> Anyone having any issue with me removing it now? WDYT?
>>
>> Thanks
>> -Vincent
>>
>>> On 16 Jan 2017, at 18:37, Vincent Massol <vincent(a)massol.net> wrote:
>>>
>>> Hi everyone,
>>>
>>> I’ve started a first version of a XWiki docker packaging at
>> https://github.com/xwiki-contrib/docker-xwiki and I’ve created an
>> automated build on DockerHub at https://hub.docker.com/u/xwiki/. The goal
>> is to provide an official packaging done by the XWiki dev team.
>>>
>>> Since I’m a recent user of Docker I’m sure I’ve made plenty of mistakes
>> and not following some best practices, even though I’ve tried my best to do
>> that ;)
>>>
>>> So it would be great if:
>>> * Some users could try it out and let me know how it works
>>> * Users could tell me what they’d expect in term of setup from a docker
>> distribution.
>>> * Some Docker experts review my code and let me know what I should
>> improve!
>>>
>>> After I receive some confirmation that it works well-enough, my goal is
>> to document it as an official way of installing xwiki on xwiki.org.
>>>
>>> Feel free to create jiras for ideas and bugs at
>> http://jira.xwiki.org/browse/XDOCKER.
>>>
>>> Thanks a lot!
>>> -Vincent
>>>
>>> PS: Note that I’m sure some will want a different DB, such as postgreSQL
>> for example. That should be easy to do. Pull request accepted! :)
>>>
>>
>>
Hi devs,
We have a unintended regression in the standard import: if what you
import is identical to what is already in the database (including the
author) it won't add a new version (if you use the default option "Add
a new version to the existing page").
What happen in practice is that if you keep calling XWikiDocument#set*
methods with the same data it won't update the metadata or content
dirty flags. This flags are what hibernate store look at to know if it
should add a new version or not.
You can reproduce the same behavior with a simple script which load a
document, always set the same content and save. You will notice that
the history of that document does not change.
So the question is do we force metadata dirty to true all the time in
the instance output filter or do we keep this feature (in which case
we should optimize it a bit to not do the useless XWiki#saveDocument
but that's another subject).
WDYT ?
It could be seen as a nice feature but in practice my first reaction
was WTF and you often want to be sure the import actually did
something so I'm +1 to force metadata dirty. But I'm +0 to keep the
current behavior if there is a majority for it.
--
Thomas Mortagne
Hi devs,
Right now we’ve started acknowledging the committers in the Release notes.
I’d like to propose to extend that try to ack everyone who participates in one way or another to a release, and not just developers.
I can think of 3 more items to add:
A) All the JIRA issue reporters that have had an issue fixed for the release (bug, improvement, new feature, etc). They took the time to report an issue and thus they’ve helped the committers to improve the quality of the release and thus they should be acknowledged. This allows us to also ack QA. We could decide to exclude the reporters who’ve also been committers or leave them in.
B) The people who’ve contributed translations done after the start of the release development.
Ideally we would also ack:
C) The people who’ve helped on the list for the release
D) The people who’ve helped on the Design and made proposals that made it to the release. I’m thinking of Caty for example. Luckily Caty also commits some code and often she’s recognised through commits.
The problem with C) and D) is that they’re hard to gather. But we could do it on an ad-hoc basis by adding them to the RN during the development (when they help) instead of doing it at the end.
In any case I’d like to focus on A) and B) FTM and I’m proposing to add them to the Release Plan since they’re easy to find out.
WDYT?
Thanks
-Vincent
Hi everyone,
I’ve started a first version of a XWiki docker packaging at https://github.com/xwiki-contrib/docker-xwiki and I’ve created an automated build on DockerHub at https://hub.docker.com/u/xwiki/. The goal is to provide an official packaging done by the XWiki dev team.
Since I’m a recent user of Docker I’m sure I’ve made plenty of mistakes and not following some best practices, even though I’ve tried my best to do that ;)
So it would be great if:
* Some users could try it out and let me know how it works
* Users could tell me what they’d expect in term of setup from a docker distribution.
* Some Docker experts review my code and let me know what I should improve!
After I receive some confirmation that it works well-enough, my goal is to document it as an official way of installing xwiki on xwiki.org.
Feel free to create jiras for ideas and bugs at http://jira.xwiki.org/browse/XDOCKER.
Thanks a lot!
-Vincent
PS: Note that I’m sure some will want a different DB, such as postgreSQL for example. That should be easy to do. Pull request accepted! :)
Hello,
Can someone please create the repository and the Jira project for the Tooltip
Macro <http://extensions.xwiki.org/xwiki/bin/view/Extension/Tooltip+Macro>
extention ? At this point, it can't be installed with EM and we need to do
some adjustments to this macro.
Repository name : macro-tooltip
Jira project name : MTOOLTIP
Thank you,
Raluca.
Hi devs,
I’ve started setting up GitHub organization jobs on ci.xwiki.org. One is already set up for xwiki contrib:
http://ci.xwiki.org/job/XWiki%20Contrib/
What it means:
* Whenever a contrib project commits a Jenkinsfile (see example: https://github.com/xwiki-contrib/syntax-markdown/blob/master/Jenkinsfile) then automatically this project gets built by jenkins
* It works for all branches and is removed when branches are removed
Now, I’m working on creating some shared pipeline libraries (see https://github.com/jenkinsci/workflow-cps-global-lib-plugin) so that we can avoid duplications in Jenkinsfile. So I need an SCM location for it and it seems that it cannot be in a directory of an existing repo and it needs to be in the root of a repo.
Thus I’m proposing https://github.com/xwiki/xwiki-jenkins
WDYT?
Note: we could also use xwiki-contrib but it would be a bit weird to use that for building xwiki org repos and my plan is to move to Jenkinsfile also for repos in the xwiki GitHub org (commons, rendering, etc).
Thanks
-Vincent
Hi,
Reminder: According to the timeline https://developers.google.com/
open-source/gsoc/timeline
February 9 16:00 UTC is the Mentoring organization application deadline.
Because of the differences in stipends for students around the world that
were introduced thi year, see https://developers.google.
com/open-source/gsoc/help/student-stipends
I will not be this year a mentor or an org administrator. I find the
segregation offensive and contrary to the principles I was promoting as
part of the GSOC program.
I ask someone else to continue with the registration process, in case we
want to attend. You can find all the documents needed at
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/
OrganizationAdministratorGuide
We also need proposals so mentors should revive proposals from previous
years or propose new ideas for this year.
Thanks,
Ecaterina Moraru
Eduard Moraru
Hi devs,
Here’s a proposal of topics to cover for XE 9.0-9.2 (i.e. Jan-Mar 2017). This proposal is proposed by XWiki SAS and was discussed with XWiki committers who work for XWiki SAS.
If you also want to propose some other items, please do so. Ofc if you have some problems or questions with the proposed roadmap let me know in reply.
* Distribution Manager Command Line Upgrade (aka Unattended Upgrades) - Thomas
* Polish CKEditor - Marius
* Auto-ajust column size on PDF export, to get different column lengths - Guillaume
* Extension manager improvements to allow cleaner upgrades (XWIKI-12705 and XWIKI-13747) - Thomas
* More Ease of Use - Marius
* Default product pages should not be easily deleted - Guillaume
* Move from XE to KB Flavor (up to the distribution) - Thomas
* In-Product Tours and Documentation - Marius
* Notification System - Guillaume
@Devs: if you’re assigned to some tasks above please make sure you create JIRAs for XWiki 9.0-9.2 ASAP and assign yourself.
Thanks
-Vincent