Hello devs,
Today is BFD#144:
http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays
Our current status is:
* -49 bugs over 120 days (2 months), i.e. we need to close 49 bugs to have created bugs # = closed bugs #
* -5 bugs over 365 days (1 year).
* -51 bugs over 500 days (between 1 and 2 years)
* +13 bugs over 1600 days (4.3 years)
* -633 bugs since the beginning of XWiki
See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352
It would be great if today we could at least fix 5 bugs to be even on the 365 day period. But more generally we’ve accumulating some lag recently with -49 bugs over 120 days. So we need to start catching up a bit.
Here's the BFD#143 dashboard to follow the progress during the day:
https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13896
Happy BugFixing Day,
-Vincent
Hi xwikiers,
Eduard hard the idea of dynamically rename the files names of the
packages we publish on http://www.xwiki.org/xwiki/bin/view/Download/
page and use the refactoring to move XE features to a new platform
flavor as a good opportunity for this change.
In more details the proposal is the following:
* name "xwiki-demo-9.5.zip" or "xwiki-9.5.zip" the standard
jetty/hsqldb package (the one which let you choose the flavor you want
to install)
* name "xwiki-9.5.war" the standard war package
* name "xwiki-classic-9.5.xip" the offline package containing XWiki
Classic flavor
WDYT ? Other ideas ?
+1 with a preference for "xwiki-demo-9.5.zip" over "xwiki-9.5.zip" to
make it more clear it's not a production oriented package.
--
Thomas Mortagne
Hi everyone,
I would be working on the proposal 'Glossary Application' in the coming
days. The details of the proposal can be found on the Design Page
<http://design.xwiki.org/xwiki/bin/view/Proposal/GlossaryApplication> .
Please tell me if something is not clear. Any suggestions are welcomed. :)
I wanted to propose a UI for both the pages ('HomePage' and 'glossary page
for each item').
- For the Glossary HomePage:
- A search bar will be employed on the top of page, which would search a
glossary page(from glossary space) if a user enters the matching
words for
that glossary items. A search bar will be made using HTML/CSS.
- The search results (suggestions) will be displayed on the same page
below the search bar along with the location of the glossary
item.(considering the fact that two glossary items with the same name may
exist). I saw that there is a 'Suggest Widget' for this. Hope I
can make it
work :P .
- On clicking those links, the user will be directed to the matching
glossary page.
Is this UI ok?
- Glossary Page of each glossary item:
- It will contain two fields.
- First field will be a 'String' which will contain the name of the
glossary item.
- Second field will be a 'text area' named "Glossary". It will
contain the glossary of that item that a user will enter itself on the
page, he is on.
Is this UI ok?
After this I will update my design page and tell you about my next
steps.....!
Thanks :)
Sarthak Gupta
[sarthakg]
Dear all, an update with the activities regarding the red pen integration.
Red-pen side implementation: As of now I am unable to establish contact with
neither the community and redpen, nor with its creator, Mr. Takahito Ito.
Their community seems to be quite silent, unlike ours
Hence, I will be beginning preliminary design on the UI.
As of now I am planning to create the UI something like the FAQ page. Each
entry on the page by the user corresponds to a particular Red-Pen Validator
setting which for now would be imported into a Redpen server (As of now I
will use my localhost terminal to set up the server).
I am dealing with the import of the validators from the ui into the server
first, before incorporating the ScriptServices that will call the dependent
components which will do the proofreading.
What do you think?
P.S. Sorry for the absence over last week, by some bad coincidences I had 2
48-hour hackathons back to back.
--
View this message in context: http://xwiki.475771.n2.nabble.com/Gsoc-Update-Red-Pen-Integration-UI-tp7604…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi devs,
I wanted to share with you what’s been done and what’s next, related to the CI improvements and especially jenkins pipelines.
Done:
=====
* A) Share pipeline script is configured on ci.xwiki.org and available at https://github.com/xwiki/xwiki-jenkins-pipeline
* B) Contrib projects are using a Jenkinsfile and a Github Organization job is set up on ci.xwiki.org (automatically create and remove jobs based on branches and PRs)
* C) The share pipeline script now supports screenshot attachment to the job test report page + avoids false positives emails
Ongoing experiment:
================
* D) I started moving the commons/rendering/platform/enterprise jobs to use our pipeline script but this is not possible right now because there’s an important missing feature ATM in pipeline: the ability to have incremental maven builds (ie only rebuild the module touched by the commit and its dependencies). Without this we would rebuild the whole repo which would lead to more load on the agents and slower feedback times.
What I’m planning to work on next:
===========================
* E) Create a new pipeline script to perform releases of XE (commons + rendering + platform + enterprise). The idea is to move part of our release script into a pipeline that would get executed either at each commit (if we have enough agents) or once per day or more. The idea is that once we’re ready to cut the release we could just promote the pre-built release and win several hours on our release process. This is what’s left to do in order to be able to do this IMO:
** Set the “xwiki.compatibility.previous.version” automatically in the script if not correct (this is step 1 of the release plan)
** Move the translation script into the pipeline script and only apply translations for non bug fix releases. Note that the RM would still need to validate visually that no spam was introduced in translations at release time by reviewing the job logs.
** Create a flickering “database”, either in jira or in xwiki.org (my proposal is to use xwiki.org and have an XObject per flicker), and in the pipeline script verify automatically that any failing test is part of the flicker database or fail the release otherwise.
** Execute the release:prepare and release:perform goals in the pipeline script and release to a staging nexus repo on nexus.xwiki.org. The RM would just need to release from this repo at release time
** Have some nexus scheduled task to remove non-released staging repos, or do this using the nexus REST API inside the pipeline script if need be (or do this manually by the RM initially)
* F) Experiment using the docker pipeline feature to run XWiki functional tests inside docker. The goal is to be able to test xwiki in various setups (various DBs, with LibreOffice server, ideally clustering but that’s harder, etc).
** For this I think I’ll need to develop a new docker image that doesn’t include XWiki and map the local directory where the XWiki distribution has been created by the packager plugin into the docker image.
If you have any remarks please let me know and if someone is interested in participating let me know too :)
Thanks
-Vincent
Hi devs,
The idea today is to do a Test Day with priority to fixing long
standing flickering (integration mostly) tests.
You can find known flickering tests on
http://jira.xwiki.org/issues/?filter=14240. The goal is to really fix
them, not just add some random wait here and there ;)
If you are not confident with the area around those specific
flickering tests here are some other ideas for today:
* obviously add more tests and increase the code coverage
* move tests from enterprise to platform. Needed for the platform
flavor and removal of XE
* update jacoco covering setup (we often forget to increase it when
adding more tests)
* move more tests from JMock to Mockito
* work on new test setups and tools:
** improve docker containers for packaging XWiki (possibly several for
multiple DBs and Servlet containers).
** work on spreading Jenkins platform job into one job per maven
module so that build can be spread on various agents (groovy
scripting)
** Research/Use Jenkins 2 Pipeline plugin with the new DSL and commit
the jenkinsfile in SCM
** Test platform to run contrib extension tests on various versions of
XWiki automatically
* Speedup existing tests (research xwiki startup time, remove
unnecessary modules, etc)
When what you fix can be linked to a Jira issue (sure you can create a
jira issue for adding new tests this time :)), tag it with "testday"
(same idea as "bugfixingday" when doing BFD). If not then answer to
this mail to explain what you did.
Good Test Day !
Hi,
I have a question about tables: how can I create a table in XWiki?I want to create a table in which i can introduce data and I want to export that table (the content of the table) as a PDF document (but if is posible, in that pdf the exported content to be display as a table,to look good).How can I do that?
Thank you,Paula P.
Hi,
I created a xclass with more attributes which represent the columns of a table. I need to write data in that table and also to get data from the table such that i will can compute an average for example (with that values) and after that i want to put/write the result in the same table.
The page I have created using the xclass contains the attributes of the xclass, which I can modify, but I need the table.
So, my question is:
How can I make the table such that I will can write in it and get data from it? Also, how can I export that table as pdf document?Thank you!
| | Virus-free. www.avast.com |
GSoC Coding Part Finally starts tomorrow, so the highest time to get down
to work.
I created modest design page where I put summary of general idea of my
project:
http://design.xwiki.org/xwiki/bin/view/Proposal/Moreextensionrepositories
To start coding I need:
1. A confirmed naming pattern for the extensions that I will develop. My
suggestion is "..... Integration" e.g. "Pypi Integration" "Bintray
Integration" Imho, the names of possible repositories are popular and
verbose enough to impy that the integration is about extension repository.
What do you think?
2. Repositories on https://github.com/xwiki-contrib One per each extension
(i.e. external) repository: Bintray, Pypi, NPM. Is it enough if I ask for
it here or should I create some official request?
3. Some space somewhere in XWiki ecosystem where I would be able to
document progress and decisions made - things much more detailed and
low-level that are normally presented on design pages or
http://extensions.xwiki.org/xwiki/bin/view/Extension/ pages.
Best,
Krzysztof Płachno
Help me to decide!
TL;DR:
* I need to know if performing a query on the database for each user who
want to receive an email with all the notifications, is a scalability issue
(in a job context).
* If it's not an issue, I can implement the "naïve" solution which requires
less development.
Full message:
Status:
* notifications are displayed on the top menu when you browse the wiki.
* notifications are displayed differently for each individual user
according to their preferences (filters on event type, on locations,
etc...).
* similar notifications are grouped together into "composite notifications".
* there is only a few notifications displayed (5 by default).
Objective:
* send an email periodically (every hour, every day, every week) according
to the user preferences with ALL events that happened during the last
period of time, but still according to the user preferences.
Inspiration:
* the watchlist gets ALL events that happened during the last period of time
* then, for each user, remove the events which the user is not interested in
* Benefit: only one query to get the events from the database for all users
Problems:
* in the notifications, I have introduced a NotificationFilter role the
make possible to inject some SQL in the query to get the events according
to the user preferences. I call this "pre-filters".
** it means we generate a unique request for each individual user, so if we
send a mail to 1000 users, we will have 1000 requests to the database.
I wonder if it's a non-problem or a big scability issue. Because even if
the whole job that send emails take ~10 minutes, it does not matter. It's
not a realtime thing.
For the records, NotificationFilter have "post-filters" too, that perform
check on the event itself (for example checking the permissions, etc...).
Alternatives:
* just like the watchlist, perform a very generic query on the database to
get all the events that happened during the last period of time
* then for each user, use only the "post-filters" to remove events the user
don't care of
Problem:
* it means the pre-filters that make sense in the notification use-case
cannot be used for emails. Developers must be aware of this.
* it requires some refactoring of the code that group similar notifications.
Question:
Should I go with the "naive" solution, ie for each user get all
notifications and send a mail, or should I go with the "only 1 query to the
database for all users" version?
Thanks,
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project