Re: [OpenStack-Infra] OpenDaylight Internship 2017 : Introduction

[Dong Ma]

Hello Yolande, I have made some plugin changes to use convert xml [1], if
you interested you can work on this part.

[1] https://etherpad.openstack.org/p/JJB_plugins_support

Thanks,
Dong

2017-02-14 0:58 GMT+08:00 Yolande Amate :

> Hello,
>
> My name is Yolande Amate, I am a third year computer Science student
> at the university of Buea Cameroon in Africa. I have been selected for
> the OpenDaylight internship [0] 2017, to work on the project  "Jenkins
> Job Builder-Improve Jenkins Plugins Support". I will be implementing
> support for Jenkins plugins, so I would like to know if there are any
> currently any plugins of interest to the community which are currently
> missing that I could add support for.
>
>  I am looking forward to working with the community and a successful
> contribution to the project.
>
> Cheers,
> Yolande
>
> [0] https://wiki.opendaylight.org/view/Interns
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB V2.0 planning

[Dong Ma]

Hey Darragh,

For Mon/Fri, the current time slots both works for me.

Thanks,
Dong



>> On Mon, Jul 4, 2016 at 8:47 PM, Dong Ma <winterma.d...@gmail.com> wrote:
>>
>>> Hey Darragh,
>>>
>>>
>>>
>>> I agree with your thought and would like to participate to the reviews,
>>> although the time slots is a little late for me but it works.
>>>
>>>
>>>
>>
> Would moving the time slot an hour earlier on either Mon/Fri suit you
> better?
>
> --
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool"
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Jenkins job builder status report

[Dong Ma]

Hi Kien,

What I thought is the changes made to convert to xml function have been
updated to a lot of plugins, also some plugins have not been updated. So if
we have a spec to keep why and how to use the convert to xml function and
which plugins have been updated, which not, it will be great. But it's not
must needed, just my opinion.

Thanks,
Dong

2016-07-06 14:20 GMT+08:00 Kien Ha <kienha9...@gmail.com>:

> Hi Dong,
>
> Looks like I misinterpreted what you mean the first time around, sorry
> about that. To clarify, did you mean to keep track of changes made to
> convert to xml function or to keep track of the plugins that have been
> updated to use the function? If it is wanted, I can go ahead and start
> adding it to the commit messages.
>
> Thanks,
> Kien
>
> On Sun, Jul 3, 2016 at 5:13 AM, Dong Ma <winterma.d...@gmail.com> wrote:
>
>> Hey Darragh and Kien,
>>
>> What I proposed is to create a etherpad/spec/blueprint to cover these
>> changes of using the convert to xml function in JJB, and include it in the
>> commit message as reference to keep tracking the process, so if someone
>> else would like to contribute, it will be easy to find it.
>>
>> Yes, include the document link into the commit message is not a good
>> commit message, I agree to keep the commits describing the functional
>> reason.
>>
>> Thanks,
>> Vincent
>>
>> 2016-07-01 22:25 GMT+08:00 Darragh Bailey <daragh.bai...@gmail.com>:
>>
>>> Hi Kien,
>>>
>>>
>>> I missed this email, but spotted this appearing in recent commits.
>>>
>>>
>>> On 13 June 2016 at 03:28, Kien Ha <kienha9...@gmail.com> wrote:
>>>
>>>>
>>>> On Sat, Jun 11, 2016 at 11:12 PM, Dong Ma <winterma.d...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hello Kien Ha,
>>>>>
>>>>> Thanks for the contribution to the Jenkins job builder projects, have
>>>>> one comment here, how about add your proposal document link or create a 
>>>>> new
>>>>> etherpad into the commit message of each patches as reference to keep
>>>>> tracking the process.
>>>>>
>>>>> Vincent
>>>>>
>>>>
>>> This kind goes outside of what is generally described as
>>> https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages
>>>
>>>
>>> The update to the mailing list is more than enough, let's keep the
>>> commits describing the functional reason for the change, or if there is a
>>> separate proposal spec/blueprint that covers changing to use the convert to
>>> xml function in JJB, changes relevant can include a reference, otherwise
>>> lets keep the commit messages focused on the change itself.
>>>
>>>
>>> --
>>> Darragh Bailey
>>> "Nothing is foolproof to a sufficiently talented fool"
>>>
>>
>>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] JJB V2.0 planning

[Dong Ma]

Hey Darragh,



I agree with your thought and would like to participate to the reviews,
although the time slots is a little late for me but it works.



Thanks,

Dong Ma (Vincent)



Email: winterma.d...@gmail.com

IRC: larainema

Telephone: +86 18610023880




2016-07-05 0:43 GMT+08:00 Darragh Bailey <daragh.bai...@gmail.com>:

> Hi,
>
>
> To try and minimise trashing of both core reviews and V2.0 patch
> author(s), I'd like to propose that we pick a time/day every second week
> for 3-4 iterations where those interested set aside a set block of time to
> collaborate in getting the main rework patches landed. Consider it a set of
> mini bug days focused on JJB 2.0 API changes.
>
> To get the ball rolling, I'm going to suggest one of the following 2
> timezones (obviously these suit me best, but I'm available the other days
> as well):
> 14:00-1800 UTC Thurs (Staring 7th July - not available the 14th hence
> suggesting this Thurs)
> 14:00-1800 UTC Tues (Staring 12th July)
>
> I'm assuming that later in the day for me aligns better with others, but I
> could be very wrong.
>
> Also thinking that spinning up a temporary public dedicated IRC chat room
> would be helpful here, probably look to avoid using one of the existing
> meeting rooms because I'm assuming that would conflict with other teams,
> unless someone tells me there is a simple solution to this. Only negative I
> can see is that the chats wouldn't be logged.
>
>
>
> More info below on why suggest this:
>
>
> Having gone through a few cycles where patches get reviewed, reworked and
> then broken by other changes landing, reworked again, reviewed and broken
> again, it can be quite onerous on both author and reviewer getting a change
> that touches a number of places to land as the risk of another patch
> landing causing a merge failure increases dramatically the more places the
> patch touches.
>
> The set of V2 patches has to bring the existing code through some amount
> of interim steps to make it easy to review, unfortunately given the amount
> of rework to do, the odds of anything else triggering a conflict is pretty
> high and basically faced with the following choices:
>
>- Take a long time complete the cycle of rework -> review -> rework ->
>break -> rework ->. ...
>- Block landing any changes that touch any of the code impacted by V2
>work until most V2 patches are landed.
>
>
>
> However we can get enough cores on around the same time and try for some
> synchronized collaboration, I think it's probably far easier to land a
> series of patches over a few meetings and get everything far enough along
> with much less workload placed on everyone involved that we can then revert
> back to the more async approach without the same issues around the
> remaining changes.
>
> Expect that this would only take 3-4 of these to get the major part of the
> rewrite in place.
>
> Thoughts? Does this work for enough other JJB reviewers?
>
>
> --
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool"
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Jenkins job builder status report

[Dong Ma]

Hey Darragh and Kien,

What I proposed is to create a etherpad/spec/blueprint to cover these
changes of using the convert to xml function in JJB, and include it in the
commit message as reference to keep tracking the process, so if someone
else would like to contribute, it will be easy to find it.

Yes, include the document link into the commit message is not a good commit
message, I agree to keep the commits describing the functional reason.

Thanks,
Vincent

2016-07-01 22:25 GMT+08:00 Darragh Bailey <daragh.bai...@gmail.com>:

> Hi Kien,
>
>
> I missed this email, but spotted this appearing in recent commits.
>
>
> On 13 June 2016 at 03:28, Kien Ha <kienha9...@gmail.com> wrote:
>
>>
>> On Sat, Jun 11, 2016 at 11:12 PM, Dong Ma <winterma.d...@gmail.com>
>> wrote:
>>
>>> Hello Kien Ha,
>>>
>>> Thanks for the contribution to the Jenkins job builder projects, have
>>> one comment here, how about add your proposal document link or create a new
>>> etherpad into the commit message of each patches as reference to keep
>>> tracking the process.
>>>
>>> Vincent
>>>
>>
> This kind goes outside of what is generally described as
> https://wiki.openstack.org/wiki/GitCommitMessages#Information_in_commit_messages
>
>
> The update to the mailing list is more than enough, let's keep the commits
> describing the functional reason for the change, or if there is a separate
> proposal spec/blueprint that covers changing to use the convert to xml
> function in JJB, changes relevant can include a reference, otherwise lets
> keep the commit messages focused on the change itself.
>
>
> --
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool"
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Jenkins job builder status report

[Dong Ma]

Hello Kien Ha,

Thanks for the contribution to the Jenkins job builder projects, have one
comment here, how about add your proposal document link or create a new
etherpad into the commit message of each patches as reference to keep
tracking the process.

Vincent

2016-06-11 4:05 GMT+08:00 Kien Ha :

> Hello,
>
> My name is Kien Ha and I am being mentored by Thanh Ha. I mainly work on
> the Jenkins Job Builder Project. I was asked to give my status report to
> the OpenStack.
>
> This week I have:
> - Update Cucumber Reports plugin
> - Update EnvInject plugin
> - Update FSTrigger plugin
> - Update JaCoCo plugin
> - Update support for BuildResultTrigger plugin
> - Update Sonatype CLM for CI plugin
> - External Monitor Job Type is up-to-date
> - Investigate HTTP Request
>
> I was asked to investigate HTTP Request and I found out that it does not
> have a way to put files onto nexus. It can however delete files on nexus if
> they are there.
>
> Next week I plan on working on:
> - FindBugs Plugin
> - Gearman Plugin
> - IvyTrigger Plugin
>
> I have a final exam next week so I will be more focused on my studies.
>
> Attach below is a link to my Jenkins job builder project proposal document
> with a complete table of plugins that I have worked on found at the top of
> the document [0]. The weekly work log is found at the bottom of the
> document.
>
> Regards,
> Kien Ha
>
> [0]
> https://docs.google.com/document/d/17AHluxqiBFcsTCkpyekDOFSTahX50pXFmQgjlK-PoEQ/edit
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra