[cip-dev] List of patches that failed to apply to 4.4-stable

[cip-dev] List of patches that failed to apply to 4.4-stable

[Daniel Sangorrin]

To: CIP Kernel team

I have prepared a list of patches that failed to apply to 4.4-stable in the past. The list is based on the corresponding e-mails sent to the stable mailing list (since I subscribed, there may be more failed patches before my subscription). We can discuss today at the TSC meeting, and on Thursday during the IRC meeting whether we want to backport any of them or not.
[Note] I still have to check if some of them were applied by any other means.

Best regards,
Daniel
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: failed-subjects.txt
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20181112/82ba90fc/attachment.txt>

[cip-dev] List of patches that failed to apply to 4.4-stable

[SZ Lin (林上智)]

Hi Daniel,

Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp> ? 2018?11?12? ?? ??5:15???
>
> To: CIP Kernel team
>
> I have prepared a list of patches that failed to apply to 4.4-stable in the past. The list is based on the corresponding e-mails sent to the stable mailing list (since I subscribed, there may be more failed patches before my subscription). We can discuss today at the TSC meeting, and on Thursday during the IRC meeting whether we want to backport any of them or not.

I've created a draft wiki page for it, feel free to modify the format.

https://wiki.linuxfoundation.org/civilinfrastructureplatform/linux-4.4-failed-patches

SZ

> [Note] I still have to check if some of them were applied by any other means.
>
> Best regards,
> Daniel
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

[cip-dev] List of patches that failed to apply to 4.4-stable

[Daniel Sangorrin]

To kernel team,

@SZLin: thanks for creating a page on the wiki just for that.

Yesterday, I checked the patches in my "failed to apply to 4.4-stable" list against the actual git repository using a short python script.
It turns out that some of the patches in the "to apply" list were already there applied.

I have updated our wiki page accordingly
https://wiki.linuxfoundation.org/civilinfrastructureplatform/linux-4.4-failed-patches

For the curious minds, you can find my (dirty) script attached to this e-mail.

Thanks,
Daniel



> -----Original Message-----
> From: SZ Lin (???) <sz.lin@moxa.com>
> Sent: Monday, November 12, 2018 8:04 PM
> To: daniel.sangorrin at toshiba.co.jp
> Cc: cip dev <cip-dev@lists.cip-project.org>
> Subject: Re: [cip-dev] List of patches that failed to apply to 4.4-stable
> 
> Hi Daniel,
> 
> Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp> ? 2018?11?12? ?? ?
> ?5:15???
> >
> > To: CIP Kernel team
> >
> > I have prepared a list of patches that failed to apply to 4.4-stable in the past. The
> list is based on the corresponding e-mails sent to the stable mailing list (since I
> subscribed, there may be more failed patches before my subscription). We can
> discuss today at the TSC meeting, and on Thursday during the IRC meeting whether
> we want to backport any of them or not.
> 
> I've created a draft wiki page for it, feel free to modify the format.
> 
> https://wiki.linuxfoundation.org/civilinfrastructureplatform/linux-4.4-failed-patche
> s
> 
> SZ
> 
> > [Note] I still have to check if some of them were applied by any other means.
> >
> > Best regards,
> > Daniel
> > _______________________________________________
> > cip-dev mailing list
> > cip-dev at lists.cip-project.org
> > https://lists.cip-project.org/mailman/listinfo/cip-dev
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: classify_failed_patches.py
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20181116/1c747e0d/attachment.ksh>

[cip-dev] List of patches that failed to apply to 4.4-stable

[Agustín Benito Bethencourt]

Hi,

On Friday, 16 November 2018 06:16:31 WET Daniel Sangorrin wrote:
> To kernel team,
> 
> @SZLin: thanks for creating a page on the wiki just for that.
> 
> Yesterday, I checked the patches in my "failed to apply to 4.4-stable" list against the actual git repository using a short python script.
> It turns out that some of the patches in the "to apply" list were already there applied.
> 
> I have updated our wiki page accordingly
> https://wiki.linuxfoundation.org/civilinfrastructureplatform/linux-4.4-failed-patches
> 
> For the curious minds, you can find my (dirty) script attached to this e-mail.

If you can put the patches list as a repo on gitlab, and since the target repo is already being mirrored, I wonder if we can create a job that executes the script when the origin list gets updated. We can create a notification with the outcome to our testing mailing list. This way we just need to focus on having the origin in shape. If we add to this a way to parser the outcome in .md format and published as result in gitlab when the job "succeeds", we significantly reduce the effort associated to the wiki page.

@Daniel W. is the above possible, based on your experience with Gitlab?

Best Regards


-- 
Agust?n Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy.   See https://www.codethink.co.uk/privacy.html

[cip-dev] List of patches that failed to apply to 4.4-stable

[Daniel Wagner]

>> Yesterday, I checked the patches in my "failed to apply to 4.4-stable" list against the actual git repository using a short python script.
>> It turns out that some of the patches in the "to apply" list were already there applied.
>>
>> I have updated our wiki page accordingly
>> https://wiki.linuxfoundation.org/civilinfrastructureplatform/linux-4.4-failed-patches
>>
>> For the curious minds, you can find my (dirty) script attached to this e-mail.
> 
> If you can put the patches list as a repo on gitlab, and since the target repo is already being mirrored, I wonder if we can create a job that executes the script when the origin list gets updated. We can create a notification with the outcome to our testing mailing list. This way we just need to focus on having the origin in shape. If we add to this a way to parser the outcome in .md format and published as result in gitlab when the job "succeeds", we significantly reduce the effort associated to the wiki page.
> 
> @Daniel W. is the above possible, based on your experience with Gitlab?

I don't think you can update a .md file via gitlab-ci. Though there is
GitLab pages which seems to be the thing for creating documentation via
a CI/CD job:

https://docs.gitlab.com/ee/user/project/pages/

[cip-dev] List of patches that failed to apply to 4.4-stable

[Agustín Benito Bethencourt]

Hi,

On Monday, 19 November 2018 16:53:05 WET Daniel Wagner wrote:
> >> Yesterday, I checked the patches in my "failed to apply to 4.4-stable" list against the actual git repository using a short python script.
> >> It turns out that some of the patches in the "to apply" list were already there applied.
> >>
> >> I have updated our wiki page accordingly
> >> https://wiki.linuxfoundation.org/civilinfrastructureplatform/linux-4.4-failed-patches
> >>
> >> For the curious minds, you can find my (dirty) script attached to this e-mail.
> > 
> > If you can put the patches list as a repo on gitlab, and since the target repo is already being mirrored, I wonder if we can create a job that executes the script when the origin list gets updated. We can create a notification with the outcome to our testing mailing list. This way we just need to focus on having the origin in shape. If we add to this a way to parser the outcome in .md format and published as result in gitlab when the job "succeeds", we significantly reduce the effort associated to the wiki page.
> > 
> > @Daniel W. is the above possible, based on your experience with Gitlab?
> 
> I don't think you can update a .md file via gitlab-ci. Though there is
> GitLab pages which seems to be the thing for creating documentation via
> a CI/CD job:
> 
> https://docs.gitlab.com/ee/user/project/pages/

There are SSGs that digest .md

https://about.gitlab.com/2016/06/10/ssg-overview-gitlab-pages-part-2/

this way the report can also be visualized not just as a static page but also as a repo file, like a normal wiki page. In any case, the format of the report is not a key point. HTML alone would work fine too, I guess.

I assume you agree with the approach in general. Thanks for the response.

Best Regards
-- 
Agust?n Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy.   See https://www.codethink.co.uk/privacy.html