Hello devs,
FYI I've created a repository in contrib with the basis of an
experimental spatial module [1].
There is also a design document I've started working on a couple of
weeks ago on the dev wiki [2].
The basic idea in one line is to be able to store and query geometries
(points, shapes, etc.) as first class XWiki properties.
It's very early support (it actually works only on a custom branch of
the SOLR API module for now) and I will continue to work on it in the
near future. I'm posting this so that if there are other committers or
contributors interested in the topic we can start a discussion.
[1] https://github.com/xwiki-contrib/module-spatial
[2] http://dev.xwiki.org/xwiki/bin/view/Design/SpatialModule
Thanks,
Jerome.
Hi Devs,
As you might already know, I’m co-organizing a “Community Development
and Marketing” devroom [0] at FOSDEM 2013 [1]. I would like to propose a
30 minute talk for this devroom, about how we organize/centralize our
infrastructure via XWiki applications, such as the IRC bot, the SVN and
GIT applications etc, thanks to XWiki’s powerful development
capabilities. More precisely:
--------------------------------------------------------------------------------
Title:
Coping with the proliferation of tools within your community
Abstract:
Following modern practices for software development and community
management requires a plethora of tools, from source code handling to
means of communication. Every tool has its purpose, and is necessary for
things to run smoothly. Discarding any of them from the workflow is not
an option. Yet, keeping track of everything can be overwhelming,
especially for new members of your community who have to learn not just
the internals of the code, but also the chock-full of tools around it,
and the rules associated with each of them.
One of the solutions we found for our community is to implement a
“developers’ wiki”, where most of the tools are either integrated, or,
for the more simple ones, implemented directly in our wiki. In this talk
I’ll quickly explain how a development wiki works. I’ll then present our
wiki-centered infrastructure, which brings together the SCM repository,
mailing lists, issue trackers, the IRC/XMPP channels, even lower level
tools for virtual machine management and resource consumption
monitoring, and offers simple solutions for blog and forum hosting,
voting, extensions hosting, and much more. Finally, I’ll show how this
approach for infrastructure management improves the workflows within our
community and facilitates the integration of newcomers.
--------------------------------------------------------------------------------
Please let me know if you have any comments/suggestions.
Also, do consider submitting other proposals relevant for the theme of
the devroom. The deadline is this Sunday, December 23rd.
[0] https://lists.fosdem.org/pipermail/fosdem/2012-November/001656.html
[1] http://fosdem.org/2013/
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
Now that the build is back on track, Marius and I would like to propose the following:
* Skip releasing 4.4M1 since we're already late. (note: We need to verify if we have any @since 4.4M1 and replace them with @since 4.4RC1)
* Release 4.4RC1 on next Thursday (27th)
* Release 4.4Final on 3rd of Jan
I'm proposing myself for these releases.
WDYT?
Here's my +1
Thanks
-Vincent
Hi devs,
Marius and myself have been spending the week trying to improve our CI and especially making sure that mails we receive are real problems.
Here's what we've achieved:
* Configured the jenkins email to have more interesting content and make sure all jobs have the same notification configuration. Current situation:
- an email is sent on every Failure
- no email is sent on build fixed
- only the list is notified ATM
* Fixed several flickers
* XINFRA-71: Automate creation of Jenkins jobs when we create a new branch. This is a by product which will be useful when we perform releases
* XINFRA-74: Update Agents to use FF 17 + updated to Selenium 2.28
* XINFRA-72: Don't send CI emails when the problem is a CI issue. We've covered the following messages in the log (when these message appear no email is sent and the build is marked with a warning icon):
- JVM crash: ".*A fatal error has been detected by the Java Runtime Environment.*"
- VNC crash: ".*Error: cannot open display: :1.0.*"
- VNC crash: ".*java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment.*"
- Git issue: ".hudson.plugins.git.GitException: Could not fetch from any repository.*"
- Browser crash: ".*Error communicating with the remote browser. It may have died..*"
- Machine slowness: ".*Failed to start XWiki in .* seconds.*"
While we're close to a stable build it's still not fully achieved since we sill have flickers in ui-tests.
What it means is that from now one we need to pay attention to any
Outstanding tasks:
* XINFRA-75: Start VNC by the job
* XINFRA-76: Fix slow XWiki startup on CI
* XINFRA-70: Put Jenkins configuration under SCM
* XWIKI-8631: Stop XWiki process in functional tests if XWiki is already started when the test starts
* XINFRA-78: Set up Timeout Jenkins plugin to stop stuck jobs
* XINFRA-79: Link to the screenshot directory in functional test job emails when there are failures
* There are still some test failures in test-ui: http://ci.xwiki.org/view/Functional%20Tests/
Next steps:
* Continue working on the listed issues above.
If you have some other ideas not listed here please mention them.
Thanks
-Vincent
Hi devs,
I'm working on configuring jenkins email configuration for all jobs (I'm scripting it).
We need to agree on the mail sending strategy.
Here's what I propose:
* We send mail to the list when there's a build failure
* We send mail to the list when the build is fixed
* We send a special mail with a different subject to committers/culprits when there's a build failure (this is the "You broke the build! Fix it now!" email that is currently sent by platform)
* We send a special mail with yet a different subject to committers/culprits when there's a second build failure (this is the "Hurry up! The build is still failing because of you! Stop whatever you're doing and fix it!" email that is currently sent by platform)
In addition I propose the following content:
"
Check console output at $BUILD_URL to view the results.
Failed tests:
${FAILED_TESTS}
Last build logs:
${BUILD_LOG, ".*Finished at:.*", 100, 100, 0, true, null, false, null, true}
"
(this last line means to include the 100 lines around the "Finished at" message in the log).
Thanks
-Vincent
Hi devs,
I'm wondering about something following Thomas' upgrade of JGroups from 3.2.0 to 3.2.5.
I'm not sure if we should continue doing upgrades of libraries during the 2 stabilization releases (4.4 and 4.5) since an upgrade always introduces a risk.
I think the exception is when it fixes an important known issue that we have.
WDYT?
Thanks
-Vincent