NACK: [j/linux-raspi v2 RESEND4 PATCH 0/2] Make snapcraft.yaml work
Juerg Haefliger
juerg.haefliger at canonical.com
Mon Feb 19 08:07:16 UTC 2024
On Wed, 14 Feb 2024 14:42:34 +0900
Masahiro Yamada <masahiro.yamada at canonical.com> wrote:
> On Fri, Feb 9, 2024 at 6:34 PM Juerg Haefliger
> <juerg.haefliger at canonical.com> wrote:
> >
> > On Thu, 8 Feb 2024 12:35:53 +0000
> > Dimitri John Ledkov <dimitri.ledkov at canonical.com> wrote:
> >
> > > Hi
> > >
> > > On Wed, 7 Feb 2024 at 06:46, Juerg Haefliger
> > > <juerg.haefliger at canonical.com> wrote:
> > > >
> > > > Still missing the requested SRU tag and SRU justification. Why are you
> > > > refusing to follow our process?
>
>
>
> Because this patch is not related to SRU in the first place.
Yes it is. It targets a stable kernel.
>
> Given the inflexible SRU policy and process,
> I understood even adding a single snapcraft.yaml
> is disallowed.
Not true. The patch has been rejected so far because you're not following the
process, not because of the patch content.
>
>
>
>
>
> > > >
> > > > ...Juerg
> > > >
> > >
> > > This is however not a .deb feature at all; nor should it end up in the
> > > changelog. I'm not sure there is anything SRUish to justify here.
> >
> > It's a modification of the kernel source code of a stable kernel, so yes it's
> > an SRU change. Whether that is user-visible or not is irrelevant and
> > can be noted in the bug report. People have tooling to scrub the
> > mailing list and missing SRU tags will/might drop patches. Checking the SRU
> > justification in the bug report is one of the review steps. Why is it so hard
> > to follow the documented process and make the life of the people involved
> > easier?
> >
> > ...Juerg
> >
> >
> > > Separately, I want to try to see if doing this build in launchpad out
> > > of the full kernel git tree will even work, due to the sheer size of
> > > the clone to be done. In the past that would time out. That's why all
> > > of our recipes are usually maintained out of tree. I am pondering if
> > > this should just be a branch with snapcraft.yaml alone on the
> > > ~canonical-kernel-snaps 22 snapcraft recipes repo only, with
> > > snapcraft.yaml doing git clone of the pi kernel packaging repo with
> > > depth set to 1.
>
>
> Or, we can create a separate graveyard repository.
> "Here is a collection of rejected but useful snapcraft.yaml files"
Feel free to do that and maintain it...
> You can locally drop it into the corresponding kernel repository.
>
>
> It would be easier to do this for IOT kernels,
> and having it in-tree is aligned with how snapcraft works.
>
> https://bugs.launchpad.net/shiner/+bug/2047831
>
>
>
> Anyway, I cannot get consensus for this.
> Give up.
You haven't really tried, have you? All we asked is for you to add the SRU tag
to the email subject and the SRU justification to the bug report. That's it.
But you haven't done that so far so what do you expect? You can argue all you
want we me about whether this is SRU material or not but that's not helpful
and just a waste of my (and your) time.
You've worked with upstream, you should know how to handle anal review
comments. Make the requested changes and the reviewer happy or keep arguing...
...Juerg
>
>
>
>
>
>
>
> > >
> > > >
> > > > On Wed, 7 Feb 2024 11:22:04 +0900
> > > > Masahiro Yamada <masahiro.yamada at canonical.com> wrote:
> > > >
> > > > > linux-raspi added snapcraft.yaml more than a decade ago,
> > > > > which is not functional at all.
> > > > >
> > > > > Remove the old one, and re-implement working snapcraft.yaml.
> > > > >
> > > > > BugLink: https://bugs.launchpad.net/bugs/2051468
> > > > >
> > > > >
> > > > >
> > > > > Masahiro Yamada (2):
> > > > > UBUNTU: [Packaging] Remove old snapcraft.yaml
> > > > > UBUNTU: [Packaging] Add snapcraft.yaml for building uc22 pi-kernel
> > > > > snap
> > > > >
> > > > > snapcraft.yaml | 175 ++++++++++++++++++++++++++++++++++++++++---------
> > > > > 1 file changed, 145 insertions(+), 30 deletions(-)
> > > > >
> > > >
> > > > --
> > > > kernel-team mailing list
> > > > kernel-team at lists.ubuntu.com
> > > > https://lists.ubuntu.com/mailman/listinfo/kernel-team
> > >
> > >
> > >
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20240219/9c5ffbe8/attachment.sig>
More information about the kernel-team
mailing list