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 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
Hi.
I'm currently working on Velocity 2.0 packaging.
If that's OK with you, I would like to incorporate
DeprecatedCheckUberspector.java into Velocity, but I need a statement
from your part to be able to change its licence to Apache 2.0 (LGPL and
Apache 2.0 licences aren't compatible).
By the way, I take this opportunity to tell you that if there is another
specific part of xwiki-commons-velocity that you think should be
integrated on our side, or an important missing feature you'd like to
insist on, don't hesitate. I already integrated VELOCITY-825, for
instance, so String->Enum constant conversions are now handled by
Velocity. There may be other important conversion cases you'd like to
see handled.
Regards,
Claude
Hi,
We have discussed this subject multiple times, but we don't have an
official vote and conclusion on the topic.
Problem: In JIRA who is the Assignee of an issue fixed by a Pull Request?
1: Contributor
- he provided the solution
- giving the attributions, the contributor might feel encouraged to
contribute more
- we could do some JIRA statistics on external contributions, but this use
case can be covered by GitHub statistics
2: Committer
- he does the merging on his account and he becomes responsible for the
committed code.
- in case there are problems, the committer needs to find solution, since
we can't rely on contributors availability
- in doing the PR review, the committer spends a lot of time analyzing and
testing the provided solution
We are talking here about complete solutions provided by the PR, since in
case of partial solutions, the committer can assign himself on the issue
(depends on the quantity of modification he does).
Let me know what you think,
Caty
Dear XWiki devs
We are using the XWiki platform for our applications but sadly are still
stuck with 2.7.2. Lately we ran into issues on a large database and noticed
"disappearing" BaseObjects. We were able to link it to XWIKI-6990
<http://jira.xwiki.org/browse/XWIKI-6990>, where hibernate IDs collided
(hash collisions) and overwrote other objects without any trace - neither
visible in the history nor in a log file.
We analysed your implemented solution from 4.0+ in XWikiDocument
<https://github.com/xwiki/xwiki-platform/blob/stable-8.4.x/xwiki-platform-co…>
and BaseElement
<https://github.com/xwiki/xwiki-platform/blob/stable-8.4.x/xwiki-platform-co…>
and
noticed that you changed the 32bit String#hashCode to 64bit MD5, which
makes a collision less likely. I have a few questions regarding your
solution:
1) Is there any specific reason why you have chosen MD5 over SHA-1 or 2?
2) Collisions are still possible and would be extremely hard to notice
since they are completely silent. Have you considered to implement a
collision detection to at least log occurring collisions - or even better
reserve 1-2bits of the 64bit to be used as collision counter in the case of
it happening?
3) To question the concept of generating a hash for an ID in general:
Wouldn't a database defined "auto increment" be a much more robust solution
for the hibernate IDs? A collision would be impossible and
clustering/scalability is still possible with e.g. the InnoDB “interleaved”
autoincrement lock mode. Why have you chosen a hash based solution in the
first place?
I'm sorry if these questions were already answered in the dev mailing list
or on issues, please link me to them since I couldn't find any concrete
answers.
Thanks for your time and regards
Marc Sladek
synventis gmbh
Hi devs,
Here’s a proposed roadmap discussed with XWiki SAS devs (Thomas, Guillaume, Caty) who are available to work on 10.1.
Scope
=====
* Finish moving to FS-based attachments by default (it was planned for 10.0 already) - Assignee: Thomas
* Finish polishing/tuning/fixing Notifications and remove watchlist - Assigne: Guillaume
** Idea: enable mails by default when notifs are enabled.
* Prevent accidental move/renames - http://jira.xwiki.org/browse/XWIKI-14591 - Assignee: Thomas
* Start discussions to agree about usability proposals listed at http://design.xwiki.org/xwiki/bin/view/Proposal/Usability/Tasks5/Prioritiza… so that the first ones can be done during 10.2 and 10.3 - Assignee: Caty
* Skin refresh investigation (including Bootstrap 4) - Assignee: Caty
Dates:
=====
* 10.1RC1: 19 Jan 2018
* 10.1Final: 26 Jan 2018
Let me know if you have any remarks/issues or if you wish to contribute something extra to this roadmap.
Thanks
-Vincent
Hi developers,
We have never really decided what we will do with javascript frameworks in
the future. Angular was a good candidate at some point, and we have even
used it in the File Manager application. But then we have been very
disappointed when we discovered the new versions of Angular were not
retro-compatible. It may have been fixed since then, but I have not really
followed the news about it.
An other disadvantage of AngularJS is that it does too much. For example,
they have a custom component system with a kind of dependencies injections.
But we already can do that with RequireJS, for which it is the job. I have
already started to split my JavaScript's code in several components thanks
to RequireJS, and it works well. I think it's good to continue with
RequireJS. It is currently our go-to library when we need to use jQuery, or
even... Angular.
I have worked a lot on a new version of the Nested Pages Migrator last
year. The new version has never been released, because of blocking bugs on
the XWiki Platform's core-side. But I now have some experience with the
library I used: KnockoutJS.
It's a very simple library that does only one job and does it well: two-way
data-bindings. It plays well with RequireJS and it does not re-invent its
own component mechanism. The HTML code is not polluted by non-valid tags
(instead it uses "data-" properties and special HTML comments). The
documentation is extremely clear, and tutorials are great.
It's not the most popular library out there, but it's stable and still
alive. The trends are changing so quickly in the JS world (React was the
star not so long ago, but now it is hated because of a license change...),
but Knockout is still there. If the project dies, I think it will be easier
to replace it with an other simple library than a big "framework".
This is not a proposal or a vote, but only a feedback about this library.
You can test it there: http://knockoutjs.com/
Thanks,
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project