Hi devs,
I think we are now satisfied with our experimentation with the "users"
mailing list on discourse. I propose you to move the "dev" ML too.
My main point is that it allows advanced formatting (which is good when you
have complex proposals), meanwhile the formatting is lost with our
archiving tool like markmail (it's plain text).
Here is my +1.
Thanks,
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi everyone,
I was checking our list of flickering tests in JIRA
(https://jira.xwiki.org/issues/?jql=labels%20%3D%20flickering%20AND%20status…)
and I noticed that we had somehow old flickering test issue concerning
test that I've never seen failing.
So I propose we close some of them as inactive: the ones that we don't
remember having seen for a while. The ideal would be to have a mechanism
to update the issue when the CI fails on a flicker, but it takes time to
do properly and it's not a priority.
On the contrary I propose to trust our memory: if we're wrong because we
have closed a flicker that is still happening, it will allow us to
remind that we have this flicker to fix and we can easily reopen the issue.
As Thomas mentioned on the chat, we should also update the release plan
to include the inactive flickers in the list of issue to check.
So for now I propose to close the following list of issues as inactive:
* XWIKI-14399: AddRemoveTagsTest#addAndDeleteTagFromTagPage is
flickering (https://jira.xwiki.org/browse/XWIKI-14399)
* XWIKI-14396: AnnotationsTest#addAndDeleteAnnotations is flickering
(https://jira.xwiki.org/browse/XWIKI-14396)
* XWIKI-14394: SectionTest.testSectionEditInWikiEditorWhenSyntax2x
(xwiki-enterprise-test-ui) is flaky
(https://jira.xwiki.org/browse/XWIKI-14394)
* XWIKI-14386: appwithinminutes.AppsLiveTableTest.testEditApplication
is possibly flaky (https://jira.xwiki.org/browse/XWIKI-14386)
* XWIKI-14835:
DeletePageTest#deletePageIsImpossibleWhenNoDeleteRights is flickering
(https://jira.xwiki.org/browse/XWIKI-14835)
* XWIKI-14860: LoginTest#testDataIsPreservedAfterLogin is flickering
(https://jira.xwiki.org/browse/XWIKI-14860)
And I propose in general to close the flickers we don't remember having
seen after a cycle as inactive.
WDYT?
Simon
--
Simon Urli
Software Engineer at XWiki SAS
simon.urli(a)xwiki.com
More about us at http://www.xwiki.com
Hi devs,
tomcat9 package is now available in Debian repositories so I would
like to start providing xwiki-tomcat9-* Debian packages of XWiki.
Nothing complex so far but it if we provide an official tomcat 9
oriented package it would also make more sense to add Tomcat 9 in
https://dev.xwiki.org/xwiki/bin/view/Community/SupportStrategy/ServletConta…
(only Tomcat 8 right now).
Another argument is that it's the current recommended stable version
from Tomcat point of view so people will use it more and more.
WDYT ?
Here is my +1
--
Thomas Mortagne
Hi devs,
We currently have https://dev.xwiki.org/xwiki/bin/view/Community/DatabaseSupportStrategy
However, it doesn’t say explicitly which versions we officially support:
* For HSQLDB it says 2.3.3 which is wrong since the latest version is 2.4.1
* For MySQL it says 5.x but doesn’t specify which specific version(s)
* Same for other DBs
We cannot really support every versions since supporting means testing too.
So what I propose:
Question 1: definition
* We say we support the latest stable version of the databases for a given version cycle
** For MySQL, it’s the latest of the 5.x cycle, which is 5.7.24 as of today (see https://hub.docker.com/_/mysql/)
** For PostgreSQL, it’s the latest of the 9.x cycle, which is 9.6.10 as of today (see https://hub.docker.com/_/postgres/)
** For Oracle, it’s the latest of the 11.x cycle, which is 11.2.0.4.0 as of today (see https://www.oracle.com/technetwork/database/enterprise-edition/downloads/in…)
Question 2: review what we support
* For MySQL I think we could also start supporting MySQL 8.x (ie the latest version of that cycle). We have an issue open for it currently: https://jira.xwiki.org/browse/XWIKI-15215
* For PostgreSQL we could also start supporting versions 11.x (ie the latest version of that cycle)
* For Oracle, we could also start supporting versions 12.x (ie the latest version of that cycle)
Question 3: decide if we drop some support
* Is there any cycle that we should support for? Right now I think that MySQL 5.x is still heavily used, same for postgreSQL 9.x I guess. Don’t know for Oracle.
* Any idea?
So WDYT about the 3 questions?
Thanks
-Vincent
Hi devs,
Context
=======
It’s been since we’ve deviated from the original purpose of the Release Notes by also adding developer-oriented release notes.
The goal of the Release Notes was to **highlight** important novelties for our **users**, because looking at the JIRA list is too technical (otherwise we could simply use the Release feature of JIRA! :)).
So you may ask why we do have a “Developer” Category in the RN app. These were not for pure developers but for XWiki users who are more advanced and can write scripts in wiki pages. And when it’s the case we **must** add examples, otherwise, it’s completely useless.
For example this morning I saw this RN added:
https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/11.0/Change004/
This is typically something that has very little value to me:
* It’s for pure developers (java devs)
* It’s not understandable by anyone except the person who coded it or participated to the dev mailing list discussion about it
* It doesn’t say more than what’s in the JIRA issue so what’s the point?
* There are no examples at all in it!
* Real developers can simply look at the reference documentation or can read the JIRAs. We always link the JIRA issues in the RN anyway (it was for this reason that we’re listing them).
* It takes time to write RN items and thus it needs to have high value
Proposal
========
* Go back to the original idea and only list developer RN items when they are for scripting users and not APIs. For example, document some new script service or some additions to existing script services. Of course Groovy would allow you to call any API so being able to use it from Groovy is not a good criteria. I’d say that the criteria should be whether the Release Note Change is useful for Velocity users.
* Rename “Developers” into “Scripters” or or “Advanced Users” (any better name?)
* Always put an example when writing a “developer” change and take the time to explain properly what it’s about.
WDYT?
Thanks
-Vincent
Hi devs,
This is a proposal for the content we would have if we were to create an
OpenCollective account for XWiki.
Take a look at
https://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOpenCollective
The issues we need to solve / validate are:
A. Decide on the URL name (xwiki is already taken by XWiki SAS)
B. See if XWiki SAS can act like our Fiscal host
C. Validate the tiers and content
https://design.xwiki.org/xwiki/bin/view/Proposal/XWikiOpenCollective#HTiers
(we might need more details on how the "Bug Fixer" works in case we agree
to it)
Let me know what you think,
Caty
Hi xwikiers,
I'm never sure where to put ideas of extensions I have so I often
forget them or details I had tough about or gathered back then.
I don't think http://design.xwiki.org is the right place until you
really start designing the extension. Also it's too generic for this
need and not a very good entry point for searching something IMO, more
something to link to from somewhere else.
I would prefer something really dedicated to this "that would be a
nice thingy but not sure about the details yet" state. Would be a good
source for hackathons and GSOC or for contributors who are searching
for something interesting to work on.
I was thinking about the following alternatives:
* a new dedicated project on https://jira.xwiki.org
* reuse https://jira.xwiki.org/projects/XCONTRIB after some cleanup
(close everything left in it basically) but not super clean (it's just
that it's a good name)
* some new application on http://www.xwiki.org
WDYT ?
Right now my preference goes to a clean new jira project (just need to
think about a good project id) where you put description and close it
when the extension work really start on a dedicated location. Less
work and should do the job well.
--
Thomas Mortagne
Hi devs,
I don't think there is currently a process that is in place to handle
pull requests and I have the feeling that the way there are handled
today is a bit random.
There are usually comments sent out on each pull request but sometimes
it seems that some pull requests are going in sleep mode and it's not
clear who is in charge.
I would like to suggest that a process is put in place where it's
clear who is responsible for a pull request and a status is given to
the contributors that propose that pull request.
Something like:
Assigned developer: XXXX
Status:
New -> new pull request, not yet assigned
Assigned -> assigned to a developer, he is in charge of reviewing the
pull request and ask for modifications or accept it. The developer can
auto assign it to himself. If nobody does, we need to decide how they
will be taken into account.
ModificationsRequired -> for now rejected with comments. Contributor
needs to apply comments and then change back to Assigned for further
evaluation
VoteRequired -> there are no more comments, but a vote is required as
the changes to XWiki core are important
WaitingFinalAuthorization -> optional step for complex patches where
a additional authorization would be required (need to define who would
be the persons that give the authorization)
WaitingApplication -> there are no more comments and no changes or
vote required. The pull request can be applied and is waiting for a
developer to apply it
Abandoned -> contributors is abandoning the pull request (cannot do
the changes, no more time, etc..)
Rejected -> pull request is rejected (quality not enough, etc..)
Applied -> pull request is applied
What do you think ?
Ludovic
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
>> On 26 Aug 2016, at 13:50, Vincent Massol wrote:
[...]
>> * What I understand is that you’re not proposing to change the XAR
>> format but to introduce some tooling to generate a XAR from a set of
>> source files, at build time. Correct?
[...]
I am rewaking this rather older subject (see
http://xwiki.475771.n2.nabble.com/XAR-source-projects-should-allow-source-f…
and older things mentioned there) with yet another attempt which might
satisfy everyone: an attempt to use XAR-Transformations to include files
into XARs. It defines two extra transformations:
- INSERT_TEXT (using an XPath expression): inserts the content of the
text file
- INSERT_ATTACHMENT_CONTENT (using a file name): inserts the content of
a file in base64
The attempt is detailed in https://jira.xwiki.org/browse/XCOMMONS-1614
and has a pull-request and an example realisation.
I claim that this attempt allows project developers to nicely edit files
and let them be combined into a xar when it is the time. See the issue
for an example realisation.
I would love your comments.
Paul
Hi,
Since Maven 3.3.1 it’s possible to declare default command line options and JVM options, see https://maven.apache.org/docs/3.3.1/release-notes.html
It could be interesting to do so in our repos so that all users run with the right values.
Or we could decide that the values depend too much on the profiles being executed and it’s not worht it.
WDYT?
Thanks
-Vincent