Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

2017-02-06 Thread Thomas Mortagne
(This is all modifications made to documents containing a translation object)


On Mon, Feb 6, 2017 at 8:45 PM, Thomas Mortagne
 wrote:
> There is a typo in the previous URL:
> http://l10n.xwiki.org/xwiki/bin/view/L10NCode/BestContributorsSheet?lowerBound=20161201=20170106
>
> I'm surprised $datetool.toDate does not complain about a weird date
> like "201601201".
>
> On Mon, Feb 6, 2017 at 8:35 PM, Thomas Mortagne
>  wrote:
>> Already exist: 
>> http://l10n.xwiki.org/xwiki/bin/view/L10NCode/BestContributorsSheet?lowerBound=201601201=20170106
>>
>> What is missing is find out the dates to pass as parameters.
>>
>> On Mon, Feb 6, 2017 at 5:33 PM, Vincent Massol  wrote:
>>>
 On 6 Feb 2017, at 10:39, Thomas Mortagne  wrote:

 +1 for adding any source of contributions as long as it's automated or
 close to automated (like executing one command/request and
 copy/pasting the result)
>>>
>>> @Thomas: Could I let you write some script to generate:
>>> "B) The people who’ve contributed translations done after the start of the 
>>> release development.”
>>>
>>> ?
>>>
>>> :)
>>>
>>> So the idea is to give a start and end date and get the list of translators 
>>> during that period.
>>>
>>> Thanks
>>> -Vincent
>>>
 On Mon, Feb 6, 2017 at 10:26 AM, Marius Dumitru Florea
  wrote:
> +1
>
> Thanks,
> Marius
>
> On Sun, Feb 5, 2017 at 12:07 PM, Vincent Massol  
> wrote:
>
>> Hi devs,
>>
>> Right now we’ve started acknowledging the committers in the Release 
>> notes.
>>
>> I’d like to propose to extend that try to ack everyone who participates 
>> in
>> one way or another to a release, and not just developers.
>>
>> I can think of 3 more items to add:
>>
>> A) All the JIRA issue reporters that have had an issue fixed for the
>> release (bug, improvement, new feature, etc). They took the time to 
>> report
>> an issue and thus they’ve helped the committers to improve the quality of
>> the release and thus they should be acknowledged. This allows us to also
>> ack QA. We could decide to exclude the reporters who’ve also been
>> committers or leave them in.
>>
>> B) The people who’ve contributed translations done after the start of the
>> release development.
>>
>> Ideally we would also ack:
>>
>> C) The people who’ve helped on the list for the release
>> D) The people who’ve helped on the Design and made proposals that made it
>> to the release. I’m thinking of Caty for example. Luckily Caty also 
>> commits
>> some code and often she’s recognised through commits.
>>
>> The problem with C) and D) is that they’re hard to gather. But we could 
>> do
>> it on an ad-hoc basis by adding them to the RN during the development 
>> (when
>> they help) instead of doing it at the end.
>>
>> In any case I’d like to focus on A) and B) FTM and I’m proposing to add
>> them to the Release Plan since they’re easy to find out.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>>



 --
 Thomas Mortagne
>>>
>>
>>
>>
>> --
>> Thomas Mortagne
>
>
>
> --
> Thomas Mortagne



-- 
Thomas Mortagne


Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

2017-02-06 Thread Thomas Mortagne
There is a typo in the previous URL:
http://l10n.xwiki.org/xwiki/bin/view/L10NCode/BestContributorsSheet?lowerBound=20161201=20170106

I'm surprised $datetool.toDate does not complain about a weird date
like "201601201".

On Mon, Feb 6, 2017 at 8:35 PM, Thomas Mortagne
 wrote:
> Already exist: 
> http://l10n.xwiki.org/xwiki/bin/view/L10NCode/BestContributorsSheet?lowerBound=201601201=20170106
>
> What is missing is find out the dates to pass as parameters.
>
> On Mon, Feb 6, 2017 at 5:33 PM, Vincent Massol  wrote:
>>
>>> On 6 Feb 2017, at 10:39, Thomas Mortagne  wrote:
>>>
>>> +1 for adding any source of contributions as long as it's automated or
>>> close to automated (like executing one command/request and
>>> copy/pasting the result)
>>
>> @Thomas: Could I let you write some script to generate:
>> "B) The people who’ve contributed translations done after the start of the 
>> release development.”
>>
>> ?
>>
>> :)
>>
>> So the idea is to give a start and end date and get the list of translators 
>> during that period.
>>
>> Thanks
>> -Vincent
>>
>>> On Mon, Feb 6, 2017 at 10:26 AM, Marius Dumitru Florea
>>>  wrote:
 +1

 Thanks,
 Marius

 On Sun, Feb 5, 2017 at 12:07 PM, Vincent Massol  wrote:

> Hi devs,
>
> Right now we’ve started acknowledging the committers in the Release notes.
>
> I’d like to propose to extend that try to ack everyone who participates in
> one way or another to a release, and not just developers.
>
> I can think of 3 more items to add:
>
> A) All the JIRA issue reporters that have had an issue fixed for the
> release (bug, improvement, new feature, etc). They took the time to report
> an issue and thus they’ve helped the committers to improve the quality of
> the release and thus they should be acknowledged. This allows us to also
> ack QA. We could decide to exclude the reporters who’ve also been
> committers or leave them in.
>
> B) The people who’ve contributed translations done after the start of the
> release development.
>
> Ideally we would also ack:
>
> C) The people who’ve helped on the list for the release
> D) The people who’ve helped on the Design and made proposals that made it
> to the release. I’m thinking of Caty for example. Luckily Caty also 
> commits
> some code and often she’s recognised through commits.
>
> The problem with C) and D) is that they’re hard to gather. But we could do
> it on an ad-hoc basis by adding them to the RN during the development 
> (when
> they help) instead of doing it at the end.
>
> In any case I’d like to focus on A) and B) FTM and I’m proposing to add
> them to the Release Plan since they’re easy to find out.
>
> WDYT?
>
> Thanks
> -Vincent
>
>
>>>
>>>
>>>
>>> --
>>> Thomas Mortagne
>>
>
>
>
> --
> Thomas Mortagne



-- 
Thomas Mortagne


Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

2017-02-06 Thread Thomas Mortagne
Already exist: 
http://l10n.xwiki.org/xwiki/bin/view/L10NCode/BestContributorsSheet?lowerBound=201601201=20170106

What is missing is find out the dates to pass as parameters.

On Mon, Feb 6, 2017 at 5:33 PM, Vincent Massol  wrote:
>
>> On 6 Feb 2017, at 10:39, Thomas Mortagne  wrote:
>>
>> +1 for adding any source of contributions as long as it's automated or
>> close to automated (like executing one command/request and
>> copy/pasting the result)
>
> @Thomas: Could I let you write some script to generate:
> "B) The people who’ve contributed translations done after the start of the 
> release development.”
>
> ?
>
> :)
>
> So the idea is to give a start and end date and get the list of translators 
> during that period.
>
> Thanks
> -Vincent
>
>> On Mon, Feb 6, 2017 at 10:26 AM, Marius Dumitru Florea
>>  wrote:
>>> +1
>>>
>>> Thanks,
>>> Marius
>>>
>>> On Sun, Feb 5, 2017 at 12:07 PM, Vincent Massol  wrote:
>>>
 Hi devs,

 Right now we’ve started acknowledging the committers in the Release notes.

 I’d like to propose to extend that try to ack everyone who participates in
 one way or another to a release, and not just developers.

 I can think of 3 more items to add:

 A) All the JIRA issue reporters that have had an issue fixed for the
 release (bug, improvement, new feature, etc). They took the time to report
 an issue and thus they’ve helped the committers to improve the quality of
 the release and thus they should be acknowledged. This allows us to also
 ack QA. We could decide to exclude the reporters who’ve also been
 committers or leave them in.

 B) The people who’ve contributed translations done after the start of the
 release development.

 Ideally we would also ack:

 C) The people who’ve helped on the list for the release
 D) The people who’ve helped on the Design and made proposals that made it
 to the release. I’m thinking of Caty for example. Luckily Caty also commits
 some code and often she’s recognised through commits.

 The problem with C) and D) is that they’re hard to gather. But we could do
 it on an ad-hoc basis by adding them to the RN during the development (when
 they help) instead of doing it at the end.

 In any case I’d like to focus on A) and B) FTM and I’m proposing to add
 them to the Release Plan since they’re easy to find out.

 WDYT?

 Thanks
 -Vincent


>>
>>
>>
>> --
>> Thomas Mortagne
>



-- 
Thomas Mortagne


Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

2017-02-06 Thread Vincent Massol

> On 6 Feb 2017, at 10:39, Thomas Mortagne  wrote:
> 
> +1 for adding any source of contributions as long as it's automated or
> close to automated (like executing one command/request and
> copy/pasting the result)

@Thomas: Could I let you write some script to generate:
"B) The people who’ve contributed translations done after the start of the 
release development.”

?

:)

So the idea is to give a start and end date and get the list of translators 
during that period.

Thanks
-Vincent

> On Mon, Feb 6, 2017 at 10:26 AM, Marius Dumitru Florea
>  wrote:
>> +1
>> 
>> Thanks,
>> Marius
>> 
>> On Sun, Feb 5, 2017 at 12:07 PM, Vincent Massol  wrote:
>> 
>>> Hi devs,
>>> 
>>> Right now we’ve started acknowledging the committers in the Release notes.
>>> 
>>> I’d like to propose to extend that try to ack everyone who participates in
>>> one way or another to a release, and not just developers.
>>> 
>>> I can think of 3 more items to add:
>>> 
>>> A) All the JIRA issue reporters that have had an issue fixed for the
>>> release (bug, improvement, new feature, etc). They took the time to report
>>> an issue and thus they’ve helped the committers to improve the quality of
>>> the release and thus they should be acknowledged. This allows us to also
>>> ack QA. We could decide to exclude the reporters who’ve also been
>>> committers or leave them in.
>>> 
>>> B) The people who’ve contributed translations done after the start of the
>>> release development.
>>> 
>>> Ideally we would also ack:
>>> 
>>> C) The people who’ve helped on the list for the release
>>> D) The people who’ve helped on the Design and made proposals that made it
>>> to the release. I’m thinking of Caty for example. Luckily Caty also commits
>>> some code and often she’s recognised through commits.
>>> 
>>> The problem with C) and D) is that they’re hard to gather. But we could do
>>> it on an ad-hoc basis by adding them to the RN during the development (when
>>> they help) instead of doing it at the end.
>>> 
>>> In any case I’d like to focus on A) and B) FTM and I’m proposing to add
>>> them to the Release Plan since they’re easy to find out.
>>> 
>>> WDYT?
>>> 
>>> Thanks
>>> -Vincent
>>> 
>>> 
> 
> 
> 
> -- 
> Thomas Mortagne



Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

2017-02-06 Thread Vincent Massol

> On 5 Feb 2017, at 11:07, Vincent Massol  wrote:
> 
> Hi devs,
> 
> Right now we’ve started acknowledging the committers in the Release notes.
> 
> I’d like to propose to extend that try to ack everyone who participates in 
> one way or another to a release, and not just developers.
> 
> I can think of 3 more items to add:
> 
> A) All the JIRA issue reporters that have had an issue fixed for the release 
> (bug, improvement, new feature, etc). They took the time to report an issue 
> and thus they’ve helped the committers to improve the quality of the release 
> and thus they should be acknowledged. This allows us to also ack QA. We could 
> decide to exclude the reporters who’ve also been committers or leave them in.

Here’s how to automate this:

{{groovy}}
def jql = URLEncoder.encode('category = "Top Level Projects" AND (fixVersion = 
"9.0-rc-1" OR fixVersion = "9.0") AND resolution = Fixed AND component != 
"Development Issues only"', "UTF-8")
def columns = "field=reporter"

def url = 
"http://jira.xwiki.org/sr/jira.issueviews:searchrequest-xml/temp/SearchRequest.xml?jqlQuery=${jql}&${columns}".toURL().text
def root = new XmlSlurper().parseText(url)

def reporters = [] as TreeSet
root.channel.item.each() {
  reporters.add(it.reporter.toString())
}

println "{{{"
reporters.each() {
  println "* ${it}"
}
println "}}}"
{{/groovy}}

Thanks
-Vincent

> 
> B) The people who’ve contributed translations done after the start of the 
> release development.
> 
> Ideally we would also ack:
> 
> C) The people who’ve helped on the list for the release
> D) The people who’ve helped on the Design and made proposals that made it to 
> the release. I’m thinking of Caty for example. Luckily Caty also commits some 
> code and often she’s recognised through commits.
> 
> The problem with C) and D) is that they’re hard to gather. But we could do it 
> on an ad-hoc basis by adding them to the RN during the development (when they 
> help) instead of doing it at the end.
> 
> In any case I’d like to focus on A) and B) FTM and I’m proposing to add them 
> to the Release Plan since they’re easy to find out.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 



Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

2017-02-06 Thread Guillaume Delhumeau
Same as Thomas too.

2017-02-06 16:13 GMT+01:00 Sergiu Dumitriu :

> Same as Thomas.
>
> On 02/06/2017 04:39 AM, Thomas Mortagne wrote:
> > +1 for adding any source of contributions as long as it's automated or
> > close to automated (like executing one command/request and
> > copy/pasting the result)
> >
> > On Mon, Feb 6, 2017 at 10:26 AM, Marius Dumitru Florea
> >  wrote:
> >> +1
> >>
> >> Thanks,
> >> Marius
> >>
> >> On Sun, Feb 5, 2017 at 12:07 PM, Vincent Massol 
> wrote:
> >>
> >>> Hi devs,
> >>>
> >>> Right now we’ve started acknowledging the committers in the Release
> notes.
> >>>
> >>> I’d like to propose to extend that try to ack everyone who
> participates in
> >>> one way or another to a release, and not just developers.
> >>>
> >>> I can think of 3 more items to add:
> >>>
> >>> A) All the JIRA issue reporters that have had an issue fixed for the
> >>> release (bug, improvement, new feature, etc). They took the time to
> report
> >>> an issue and thus they’ve helped the committers to improve the quality
> of
> >>> the release and thus they should be acknowledged. This allows us to
> also
> >>> ack QA. We could decide to exclude the reporters who’ve also been
> >>> committers or leave them in.
> >>>
> >>> B) The people who’ve contributed translations done after the start of
> the
> >>> release development.
> >>>
> >>> Ideally we would also ack:
> >>>
> >>> C) The people who’ve helped on the list for the release
> >>> D) The people who’ve helped on the Design and made proposals that made
> it
> >>> to the release. I’m thinking of Caty for example. Luckily Caty also
> commits
> >>> some code and often she’s recognised through commits.
> >>>
> >>> The problem with C) and D) is that they’re hard to gather. But we
> could do
> >>> it on an ad-hoc basis by adding them to the RN during the development
> (when
> >>> they help) instead of doing it at the end.
> >>>
> >>> In any case I’d like to focus on A) and B) FTM and I’m proposing to add
> >>> them to the Release Plan since they’re easy to find out.
> >>>
> >>> WDYT?
> >>>
> >>> Thanks
> >>> -Vincent
> >>>
> >>>
> >
> >
> >
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu
>



-- 
Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project


Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

2017-02-06 Thread Sergiu Dumitriu
Same as Thomas.

On 02/06/2017 04:39 AM, Thomas Mortagne wrote:
> +1 for adding any source of contributions as long as it's automated or
> close to automated (like executing one command/request and
> copy/pasting the result)
> 
> On Mon, Feb 6, 2017 at 10:26 AM, Marius Dumitru Florea
>  wrote:
>> +1
>>
>> Thanks,
>> Marius
>>
>> On Sun, Feb 5, 2017 at 12:07 PM, Vincent Massol  wrote:
>>
>>> Hi devs,
>>>
>>> Right now we’ve started acknowledging the committers in the Release notes.
>>>
>>> I’d like to propose to extend that try to ack everyone who participates in
>>> one way or another to a release, and not just developers.
>>>
>>> I can think of 3 more items to add:
>>>
>>> A) All the JIRA issue reporters that have had an issue fixed for the
>>> release (bug, improvement, new feature, etc). They took the time to report
>>> an issue and thus they’ve helped the committers to improve the quality of
>>> the release and thus they should be acknowledged. This allows us to also
>>> ack QA. We could decide to exclude the reporters who’ve also been
>>> committers or leave them in.
>>>
>>> B) The people who’ve contributed translations done after the start of the
>>> release development.
>>>
>>> Ideally we would also ack:
>>>
>>> C) The people who’ve helped on the list for the release
>>> D) The people who’ve helped on the Design and made proposals that made it
>>> to the release. I’m thinking of Caty for example. Luckily Caty also commits
>>> some code and often she’s recognised through commits.
>>>
>>> The problem with C) and D) is that they’re hard to gather. But we could do
>>> it on an ad-hoc basis by adding them to the RN during the development (when
>>> they help) instead of doing it at the end.
>>>
>>> In any case I’d like to focus on A) and B) FTM and I’m proposing to add
>>> them to the Release Plan since they’re easy to find out.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
>>>
>>>
> 
> 
> 


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu


Re: [xwiki-devs] [Proposal] Create a xwiki-jenkins repo in the xwiki GitHub org

2017-02-06 Thread Vincent Massol
One thing that’s left is to update the CI status badges in the README.md pages 
for contrib apps.

I’ve fixed a few but it’s a lot of work and I would welcome some help. So if 
you have some contrib project, it would be nice if you could check them and 
update the README and use the URLs mentioned at 
http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HREADME.mdTemplate

Sorry about the trouble.
Thanks
-Vincent

> On 6 Feb 2017, at 14:28, Vincent Massol  wrote:
> 
> I’ve also documented the new way of getting CI for contrib projects at:
> http://contrib.xwiki.org/xwiki/bin/view/Main/#HRequestingCI2FSnapshotbuildsforyourproject
> 
> Thanks
> -Vincent
> 
>> On 6 Feb 2017, at 14:18, Vincent Massol  wrote:
>> 
>>> 
>>> On 1 Feb 2017, at 18:27, Vincent Massol  wrote:
>>> 
>>> Ok it’s now done.
>>> 
>>> If you’re curious:
>>> https://github.com/xwiki/xwiki-jenkins-pipeline/blob/master/vars/xwikiModule.groovy
>>> 
>>> And here’s an example of using it:
>>> https://github.com/xwiki-contrib/application-faq/blob/master/Jenkinsfile
>>> 
>>> Right now we have 3 repos being built by the Organisation Folder job for 
>>> XWiki Contrib:
>>> http://ci.xwiki.org/view/Contrib/job/XWiki%20Contrib/
>>> 
>>> Next steps:
>>> 1) Convert all those builds: http://ci.xwiki.org/view/Contrib/
>> 
>> Done, see http://ci.xwiki.org/view/Contrib/
>> 
>> Thanks
>> -Vincent
>> 
>>> 2) Setup an org rescan and research how it’s supposed to work (Seems things 
>>> are also changing: https://jenkins.io/blog/2017/01/17/scm-api-2/).
>>> 
>>> Thanks
>>> -Vincent
>>> 
 On 27 Jan 2017, at 16:56, Vincent Massol  wrote:
 
 Hi devs,
 
 I’ve started setting up GitHub organization jobs on ci.xwiki.org. One is 
 already set up for xwiki contrib:
 http://ci.xwiki.org/job/XWiki%20Contrib/
 
 What it means:
 * Whenever a contrib project commits a Jenkinsfile (see example: 
 https://github.com/xwiki-contrib/syntax-markdown/blob/master/Jenkinsfile) 
 then automatically this project gets built by jenkins
 * It works for all branches and is removed when branches are removed
 
 Now, I’m working on creating some shared pipeline libraries (see 
 https://github.com/jenkinsci/workflow-cps-global-lib-plugin) so that we 
 can avoid duplications in Jenkinsfile. So I need an SCM location for it 
 and it seems that it cannot be in a directory of an existing repo and it 
 needs to be in the root of a repo.
 
 Thus I’m proposing https://github.com/xwiki/xwiki-jenkins
 
 WDYT?
 
 Note: we could also use xwiki-contrib but it would be a bit weird to use 
 that for building xwiki org repos and my plan is to move to Jenkinsfile 
 also for repos in the xwiki GitHub org (commons, rendering, etc).
 
 Thanks
 -Vincent
> 



Re: [xwiki-devs] [Proposal] Create a xwiki-jenkins repo in the xwiki GitHub org

2017-02-06 Thread Vincent Massol
I’ve also documented the new way of getting CI for contrib projects at:
http://contrib.xwiki.org/xwiki/bin/view/Main/#HRequestingCI2FSnapshotbuildsforyourproject

Thanks
-Vincent

> On 6 Feb 2017, at 14:18, Vincent Massol  wrote:
> 
>> 
>> On 1 Feb 2017, at 18:27, Vincent Massol  wrote:
>> 
>> Ok it’s now done.
>> 
>> If you’re curious:
>> https://github.com/xwiki/xwiki-jenkins-pipeline/blob/master/vars/xwikiModule.groovy
>> 
>> And here’s an example of using it:
>> https://github.com/xwiki-contrib/application-faq/blob/master/Jenkinsfile
>> 
>> Right now we have 3 repos being built by the Organisation Folder job for 
>> XWiki Contrib:
>> http://ci.xwiki.org/view/Contrib/job/XWiki%20Contrib/
>> 
>> Next steps:
>> 1) Convert all those builds: http://ci.xwiki.org/view/Contrib/
> 
> Done, see http://ci.xwiki.org/view/Contrib/
> 
> Thanks
> -Vincent
> 
>> 2) Setup an org rescan and research how it’s supposed to work (Seems things 
>> are also changing: https://jenkins.io/blog/2017/01/17/scm-api-2/).
>> 
>> Thanks
>> -Vincent
>> 
>>> On 27 Jan 2017, at 16:56, Vincent Massol  wrote:
>>> 
>>> Hi devs,
>>> 
>>> I’ve started setting up GitHub organization jobs on ci.xwiki.org. One is 
>>> already set up for xwiki contrib:
>>> http://ci.xwiki.org/job/XWiki%20Contrib/
>>> 
>>> What it means:
>>> * Whenever a contrib project commits a Jenkinsfile (see example: 
>>> https://github.com/xwiki-contrib/syntax-markdown/blob/master/Jenkinsfile) 
>>> then automatically this project gets built by jenkins
>>> * It works for all branches and is removed when branches are removed
>>> 
>>> Now, I’m working on creating some shared pipeline libraries (see 
>>> https://github.com/jenkinsci/workflow-cps-global-lib-plugin) so that we can 
>>> avoid duplications in Jenkinsfile. So I need an SCM location for it and it 
>>> seems that it cannot be in a directory of an existing repo and it needs to 
>>> be in the root of a repo.
>>> 
>>> Thus I’m proposing https://github.com/xwiki/xwiki-jenkins
>>> 
>>> WDYT?
>>> 
>>> Note: we could also use xwiki-contrib but it would be a bit weird to use 
>>> that for building xwiki org repos and my plan is to move to Jenkinsfile 
>>> also for repos in the xwiki GitHub org (commons, rendering, etc).
>>> 
>>> Thanks
>>> -Vincent



Re: [xwiki-devs] [Proposal] Create a xwiki-jenkins repo in the xwiki GitHub org

2017-02-06 Thread Vincent Massol

> On 1 Feb 2017, at 18:27, Vincent Massol  wrote:
> 
> Ok it’s now done.
> 
> If you’re curious:
> https://github.com/xwiki/xwiki-jenkins-pipeline/blob/master/vars/xwikiModule.groovy
> 
> And here’s an example of using it:
> https://github.com/xwiki-contrib/application-faq/blob/master/Jenkinsfile
> 
> Right now we have 3 repos being built by the Organisation Folder job for 
> XWiki Contrib:
> http://ci.xwiki.org/view/Contrib/job/XWiki%20Contrib/
> 
> Next steps:
> 1) Convert all those builds: http://ci.xwiki.org/view/Contrib/

Done, see http://ci.xwiki.org/view/Contrib/

Thanks
-Vincent

> 2) Setup an org rescan and research how it’s supposed to work (Seems things 
> are also changing: https://jenkins.io/blog/2017/01/17/scm-api-2/).
> 
> Thanks
> -Vincent
> 
>> On 27 Jan 2017, at 16:56, Vincent Massol  wrote:
>> 
>> Hi devs,
>> 
>> I’ve started setting up GitHub organization jobs on ci.xwiki.org. One is 
>> already set up for xwiki contrib:
>> http://ci.xwiki.org/job/XWiki%20Contrib/
>> 
>> What it means:
>> * Whenever a contrib project commits a Jenkinsfile (see example: 
>> https://github.com/xwiki-contrib/syntax-markdown/blob/master/Jenkinsfile) 
>> then automatically this project gets built by jenkins
>> * It works for all branches and is removed when branches are removed
>> 
>> Now, I’m working on creating some shared pipeline libraries (see 
>> https://github.com/jenkinsci/workflow-cps-global-lib-plugin) so that we can 
>> avoid duplications in Jenkinsfile. So I need an SCM location for it and it 
>> seems that it cannot be in a directory of an existing repo and it needs to 
>> be in the root of a repo.
>> 
>> Thus I’m proposing https://github.com/xwiki/xwiki-jenkins
>> 
>> WDYT?
>> 
>> Note: we could also use xwiki-contrib but it would be a bit weird to use 
>> that for building xwiki org repos and my plan is to move to Jenkinsfile also 
>> for repos in the xwiki GitHub org (commons, rendering, etc).
>> 
>> Thanks
>> -Vincent
>> 
> 



Re: [xwiki-devs] [GSOC] Org registration deadline and admin needed

2017-02-06 Thread Thomas Mortagne
Application done and Vincent is co-admin.

On Mon, Feb 6, 2017 at 11:37 AM, Vincent Massol  wrote:
> Thanks Thomas!
>
> -Vincent
>
>> On 6 Feb 2017, at 11:23, Thomas Mortagne  wrote:
>>
>> Several people indicated that they wanted to be a mentor so I will
>> take care of admin work this year (for once).
>>
>> On Sat, Feb 4, 2017 at 5:42 PM, Ecaterina Moraru (Valica)
>>  wrote:
>>> Hi,
>>>
>>> Reminder: According to the timeline https://developers.google.com/
>>> open-source/gsoc/timeline
>>> February 9 16:00 UTC is the Mentoring organization application deadline.
>>>
>>> Because of the differences in stipends for students around the world that
>>> were introduced thi year, see https://developers.google.
>>> com/open-source/gsoc/help/student-stipends
>>> I will not be this year a mentor or an org administrator. I find the
>>> segregation offensive and contrary to the principles I was promoting as
>>> part of the GSOC program.
>>>
>>> I ask someone else to continue with the registration process, in case we
>>> want to attend. You can find all the documents needed at
>>> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/
>>> OrganizationAdministratorGuide
>>>
>>> We also need proposals so mentors should revive proposals from previous
>>> years or propose new ideas for this year.
>>>
>>> Thanks,
>>> Ecaterina Moraru
>>> Eduard Moraru
>>
>>
>>
>> --
>> Thomas Mortagne
>



-- 
Thomas Mortagne


Re: [xwiki-devs] [GSOC] Org registration deadline and admin needed

2017-02-06 Thread Vincent Massol
Thanks Thomas!

-Vincent

> On 6 Feb 2017, at 11:23, Thomas Mortagne  wrote:
> 
> Several people indicated that they wanted to be a mentor so I will
> take care of admin work this year (for once).
> 
> On Sat, Feb 4, 2017 at 5:42 PM, Ecaterina Moraru (Valica)
>  wrote:
>> Hi,
>> 
>> Reminder: According to the timeline https://developers.google.com/
>> open-source/gsoc/timeline
>> February 9 16:00 UTC is the Mentoring organization application deadline.
>> 
>> Because of the differences in stipends for students around the world that
>> were introduced thi year, see https://developers.google.
>> com/open-source/gsoc/help/student-stipends
>> I will not be this year a mentor or an org administrator. I find the
>> segregation offensive and contrary to the principles I was promoting as
>> part of the GSOC program.
>> 
>> I ask someone else to continue with the registration process, in case we
>> want to attend. You can find all the documents needed at
>> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/
>> OrganizationAdministratorGuide
>> 
>> We also need proposals so mentors should revive proposals from previous
>> years or propose new ideas for this year.
>> 
>> Thanks,
>> Ecaterina Moraru
>> Eduard Moraru
> 
> 
> 
> -- 
> Thomas Mortagne



Re: [xwiki-devs] [GSOC] Org registration deadline and admin needed

2017-02-06 Thread Thomas Mortagne
Several people indicated that they wanted to be a mentor so I will
take care of admin work this year (for once).

On Sat, Feb 4, 2017 at 5:42 PM, Ecaterina Moraru (Valica)
 wrote:
> Hi,
>
> Reminder: According to the timeline https://developers.google.com/
> open-source/gsoc/timeline
> February 9 16:00 UTC is the Mentoring organization application deadline.
>
> Because of the differences in stipends for students around the world that
> were introduced thi year, see https://developers.google.
> com/open-source/gsoc/help/student-stipends
> I will not be this year a mentor or an org administrator. I find the
> segregation offensive and contrary to the principles I was promoting as
> part of the GSOC program.
>
> I ask someone else to continue with the registration process, in case we
> want to attend. You can find all the documents needed at
> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/
> OrganizationAdministratorGuide
>
> We also need proposals so mentors should revive proposals from previous
> years or propose new ideas for this year.
>
> Thanks,
> Ecaterina Moraru
> Eduard Moraru



-- 
Thomas Mortagne


Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

2017-02-06 Thread Alexandru Cotiuga
+1

Thanks,
Alex

On Mon, Feb 6, 2017 at 11:39 AM, Thomas Mortagne 
wrote:

> +1 for adding any source of contributions as long as it's automated or
> close to automated (like executing one command/request and
> copy/pasting the result)
>
> On Mon, Feb 6, 2017 at 10:26 AM, Marius Dumitru Florea
>  wrote:
> > +1
> >
> > Thanks,
> > Marius
> >
> > On Sun, Feb 5, 2017 at 12:07 PM, Vincent Massol 
> wrote:
> >
> >> Hi devs,
> >>
> >> Right now we’ve started acknowledging the committers in the Release
> notes.
> >>
> >> I’d like to propose to extend that try to ack everyone who participates
> in
> >> one way or another to a release, and not just developers.
> >>
> >> I can think of 3 more items to add:
> >>
> >> A) All the JIRA issue reporters that have had an issue fixed for the
> >> release (bug, improvement, new feature, etc). They took the time to
> report
> >> an issue and thus they’ve helped the committers to improve the quality
> of
> >> the release and thus they should be acknowledged. This allows us to also
> >> ack QA. We could decide to exclude the reporters who’ve also been
> >> committers or leave them in.
> >>
> >> B) The people who’ve contributed translations done after the start of
> the
> >> release development.
> >>
> >> Ideally we would also ack:
> >>
> >> C) The people who’ve helped on the list for the release
> >> D) The people who’ve helped on the Design and made proposals that made
> it
> >> to the release. I’m thinking of Caty for example. Luckily Caty also
> commits
> >> some code and often she’s recognised through commits.
> >>
> >> The problem with C) and D) is that they’re hard to gather. But we could
> do
> >> it on an ad-hoc basis by adding them to the RN during the development
> (when
> >> they help) instead of doing it at the end.
> >>
> >> In any case I’d like to focus on A) and B) FTM and I’m proposing to add
> >> them to the Release Plan since they’re easy to find out.
> >>
> >> WDYT?
> >>
> >> Thanks
> >> -Vincent
> >>
> >>
>
>
>
> --
> Thomas Mortagne
>


Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

2017-02-06 Thread Thomas Mortagne
+1 for adding any source of contributions as long as it's automated or
close to automated (like executing one command/request and
copy/pasting the result)

On Mon, Feb 6, 2017 at 10:26 AM, Marius Dumitru Florea
 wrote:
> +1
>
> Thanks,
> Marius
>
> On Sun, Feb 5, 2017 at 12:07 PM, Vincent Massol  wrote:
>
>> Hi devs,
>>
>> Right now we’ve started acknowledging the committers in the Release notes.
>>
>> I’d like to propose to extend that try to ack everyone who participates in
>> one way or another to a release, and not just developers.
>>
>> I can think of 3 more items to add:
>>
>> A) All the JIRA issue reporters that have had an issue fixed for the
>> release (bug, improvement, new feature, etc). They took the time to report
>> an issue and thus they’ve helped the committers to improve the quality of
>> the release and thus they should be acknowledged. This allows us to also
>> ack QA. We could decide to exclude the reporters who’ve also been
>> committers or leave them in.
>>
>> B) The people who’ve contributed translations done after the start of the
>> release development.
>>
>> Ideally we would also ack:
>>
>> C) The people who’ve helped on the list for the release
>> D) The people who’ve helped on the Design and made proposals that made it
>> to the release. I’m thinking of Caty for example. Luckily Caty also commits
>> some code and often she’s recognised through commits.
>>
>> The problem with C) and D) is that they’re hard to gather. But we could do
>> it on an ad-hoc basis by adding them to the RN during the development (when
>> they help) instead of doing it at the end.
>>
>> In any case I’d like to focus on A) and B) FTM and I’m proposing to add
>> them to the Release Plan since they’re easy to find out.
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>>



-- 
Thomas Mortagne


Re: [xwiki-devs] [Proposal] Extend the ack section of the Release Notes

2017-02-06 Thread Marius Dumitru Florea
+1

Thanks,
Marius

On Sun, Feb 5, 2017 at 12:07 PM, Vincent Massol  wrote:

> Hi devs,
>
> Right now we’ve started acknowledging the committers in the Release notes.
>
> I’d like to propose to extend that try to ack everyone who participates in
> one way or another to a release, and not just developers.
>
> I can think of 3 more items to add:
>
> A) All the JIRA issue reporters that have had an issue fixed for the
> release (bug, improvement, new feature, etc). They took the time to report
> an issue and thus they’ve helped the committers to improve the quality of
> the release and thus they should be acknowledged. This allows us to also
> ack QA. We could decide to exclude the reporters who’ve also been
> committers or leave them in.
>
> B) The people who’ve contributed translations done after the start of the
> release development.
>
> Ideally we would also ack:
>
> C) The people who’ve helped on the list for the release
> D) The people who’ve helped on the Design and made proposals that made it
> to the release. I’m thinking of Caty for example. Luckily Caty also commits
> some code and often she’s recognised through commits.
>
> The problem with C) and D) is that they’re hard to gather. But we could do
> it on an ad-hoc basis by adding them to the RN during the development (when
> they help) instead of doing it at the end.
>
> In any case I’d like to focus on A) and B) FTM and I’m proposing to add
> them to the Release Plan since they’re easy to find out.
>
> WDYT?
>
> Thanks
> -Vincent
>
>