xwiki-devs September 2016

xwiki-devs@xwiki.org

20 participants
47 discussions

[xwiki-devs] [proposal] Process to handle Pull Requests

by Ludovic Dubost

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

5 years, 7 months

[xwiki-devs] Velocity 2.0 and DeprecatedCheckUberspector

by Claude Brisson

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

6 years, 6 months

[xwiki-devs] [Vote] Assignee for PR: Contributor or Committer?

by Ecaterina Moraru (Valica)

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

6 years, 7 months

[xwiki-devs] Edit Modes vs. Editors

by Marius Dumitru Florea

Hi devs, While working on adding extension points to support the replacement of the current WYSIWYG editor I came to the conclusion that we need to make a clear distinction between Edit Modes and Editors. An Edit Mode is basically an HTML *form* that allows you to edit some data that is associated with an XWiki document. There can be for instance an edit mode to edit the document title and content, another edit mode to edit the document objects, another one to edit the document access rights, and so on. Ideally, XWiki extensions should be able to provide new edit modes. The current place where we expose the Edit Modes is the Edit Menu. Class, Objects, Access Rights, Inline Form are well defined edit modes. Before we talk about the Wiki and WYSIWYG "edit modes" let's define what an editor is. An Editor is basically a form *field*. Most of the time it is an enhanced form field, a widget, that allows you to edit a single document field. The editor obviously depends on the field type. There can be a date editor (known as date picker), a plain text editor, a rich text editor, and so on. Ideally, XWiki extensions should be able to provide new editors for specific data types. For instance an extension could replace the date picker. Another one could replace the rich text editor. The relation between Edit Modes and Editors is many to many. An Edit Mode can use multiple editors and an Editor can be used by multiple Edit Modes. For instance the rich text editor can be used in the "Content" edit mode (for document content) but also in the Inline Form edit mode, for TextArea object properties. If we agree with this distinction then I think XWiki should have separate extension points for Edit Modes vs. Editors. What does this mean for the CKEditor integration? Well, CKEditor is an editor.. so it doesn't make sense to have a "CKEditor" edit mode. CKEditor can be used to edit the document content as well as the TextArea object properties that contain wiki syntax. So there should be no "CKEditor" entry in the Edit Menu. Otherwise we need to add "Inline Form - CKEditor" also, and so on for each Edit Mode that can use the CKEditor. So I think we should go in the following direction: * Replace Wiki and WYSIWYG entries from the Edit menu with a single Entry that will represent the Edit Mode for editing the document title, content and syntax. I'm not yet sure what name should we use for this Edit Mode. Let's call it "Content" for now. * The default edit action (for simple users) will ** open the Inline Form edit mode if the document has a sheet associated ** open the "Content" edit mode otherwise * The "Content" edit mode will use the Editor configured in the User Profile, falling-back on the wiki preferences * The Inline Form edit mode will use for TextArea properties the Editor specified in the property meta data, falling-back on the User Profile setting, then on the wiki preferences * We should have an administration section to configure the default Editor as wiki level (wiki preferences) We don't have to implement all this right away. I'd like to start by making the editor list from the TextArea meta data, User Profile and wiki preferences extensible, so that CKEditor can add its entry there. WDYT? Thanks, Marius

7 years, 10 months

[xwiki-devs] [Proposal] New Best Practice for closing issues as Duplicate

by Manuel Smeria

Hello Devs, I would like to propose a new best practice for the way we close issues as Duplicate. As an example I've reported this issue: http://jira.xwiki.org/browse/XWIKI-13728 which was later closed as a Duplicate to http://jira.xwiki.org/browse/XWIKI-13729. >From my perspective, this is not correct since the issue I reported is valid from an user's POV. I would have preferred that my issue was renamed and that developers would have added some technical information as a comment to it if they wanted to do so. It just doesn't make any sense to me to close a perfectly valid issue as a Duplicate just to create another one that has a more technically correct summary and description. It also doesn't make sense to close the original issue as a Duplicate to a duplicate issue :) (pun intended) I see things like this: my issue's description is a use-case of the issue later reported by Edy, so if anything, Edy's issue should be closed as a Duplicate to mine and not the other way around. One scenario where I think issues dated previously should be closed as Duplicate is if the new issue has already been fixed. For example when a Developer doesn't notice an older issue and starts working on the new one instead of closing the new one as a Duplicate and work on the older one. There might be more, feel free to add them to this thread. So, what I propose is that we don't close original issues as Duplicate unless it falls into the category previously described or some other exceptions that I can't think of now and might occur. Thanks, Manuel

7 years, 11 months

[xwiki-devs] [VOTE] xwiki.org Governance change for paying extensions

by Vincent Massol

Hi devs, I’d like to propose some changes to the governance related to paying extensions and extensions.xwiki.org and the Extension Manager. * Make extensions.xwiki.org an extension repo for free and open source extensions only. This is the case till now but during the last governance change VOTE we had said we could allow non-free versions. After more thinking I believe it’s better that companies who want to have paying apps provide them through their own extension repository. One issue is that these companies will need to have users register and log in and we cannot do that on xwiki.org. * Allow top sponsoring companies to have their extension repository defined in the default XWiki configuration (in xwiki.properties). I’m proposing that sponsoring companies require 3 active committers to be able to have their stores listed by default in the XWiki config. The same would be done on nexus.xwiki.org which would proxy any maven repo from a top sponsoring company. Note that any company (even one not participating to the development of the XWiki project can provide an extension repository with some instructions for users to add their repo to their config - This point here is only about having some repos by default). * Allow the top sponsoring company (TSC) an advertising space on the home page of extensions.xwiki.org to advertise extensions it wishes to promote. Please cast your votes. Here’s my +1 Thanks -Vincent

7 years, 11 months

[xwiki-devs] Release notes strategy for included contrib extensions

by Vincent Massol

Hi devs, We now include a few contrib apps in XE. However, when someone checks the RN for XE, for example http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki83M2 all they see is this: “The following dependencies have been upgraded: * Tour Application 1.0.4” It doesn’t say if there are any substantial things added those deps. I can think of 2 solutions: 1) When something is noticeable, add it to the RN of XE. So for example if CKEditor extension adds something new, users checking the RN of XE can see it immediately. 2) Link to the RN of the extension. However RN of extensions on e.x.o are not nice. They’re just lists of JIRA issues. So for this solution to be a bit satisfactory we would need to improve the RN of extensions, starting with those we bundle in XE. Another possibility is to say that for Recommended Extensions we pay an extra care to write nice Release Notes. But that’s harder to enforce and ensure. Option 1) is my preference. WDYT? Thanks -Vincent

8 years, 2 months

[xwiki-devs] [Proposal] 2 new rules for Application Best Practices

by vincent＠massol.net

Hi devs, Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra… 1) New rule 1: “Code” subspace Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code” Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this. 2) New rule 2: * Technical pages without children must be terminal pages. WDYT? Thanks -Vincent

8 years, 2 months

[xwiki-devs] [XWiki Day] BFD#120

by Alexandru Cotiuga

Hello devs, This Thursday is BFD#120: http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays Our current status for the 1 year period is 49 bugs behind. See: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=100 00#Created-vs-Resolved-Chart/10470 Here's the BFD#120 dashboard to follow the progress during the day: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13696 Happy Bug Fixing Day, Alex

8 years, 2 months

[xwiki-devs] [VOTE] Change the release cycle to 1 month

by Vincent Massol

Hi devs, Executive summary: * Replace our 3 month release cycle by a 1 month release cycle. Needs and advantages: * Be able to get our changes faster to our users. Importantly, bugfixes are released faster to users. Note: it’s not because we release faster that our users have to upgrade as fast. They can skip some versions if they want/need. * Be able to get more feedback more quickly from users. Right now, most (if not all) of our users are testing only final versions. They’re not testing milestones or RCs and thus we usually only know about problems after the final has been released and we incorporate the change in the next one (to be released 3 months later) or we have to do a bugfix release. * Get closer to cloud needs. Nowadays, could offerings happen more and more and operating a cloud means bringing improvements and fixes as fast as possible. Some software in the cloud are even updated/patched several times per day. We’re not there yet but we’re trying to get closer by reducing from 3 months to 1 month * This also means more marketing for the xwiki project since other site relay the new whenever a final version is released Proposal Details: * 1 month split in: 3 weeks to release a RC + 1 week to release the final version. It’s very important to keep the RC as a meeting point and ensuring all is going to be ready on time for the final release (jiras are closed or moved to the next release, CI is passing, documentation and RN are ready, etc). * Split large features into smaller chunks. It doesn’t matter if some code is released but unused for example (provided the build is passing). For larger refactoring that absolutely cannot be split into 3 weeks chunks (I’m not sure that really exists) then we can use branches (and create a CI job to ensure integration). * Less need for bugfix releases of stable versions. For LTS it’s still required though. * Note that this 1 month release strategy will not generate more releases (and thus more work) over the year since we’re already releasing every 2-3 weeks ATM (milestones, RCs, et) * Version Naming: from N.0 to N.10 where N is the cycle name. The reason for 11 releases and not 12 is to account for slippages + potential bugfix release at the end of the cycle for stabilization + holidays. We might even be able to do only 10 releases and not 11 but I’m suggesting we try with 11 for now. When: * I’m proposing to start this process with the 8.4 release (starting on the 10th of October). Since that version is already supposed to be a stabilization release (and thus a short 1 month release) it’s not going to change anything. We should also do bugfix releases after 8.4 is releases: 8.4.1, 8.4.2, etc till the end of the year * Then starting 9.0 we really start doing 1 month releases. WDYT? Here’s my +1 to try this. Thanks -Vincent

8 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2016