NACK: [j/linux-raspi v2 RESEND4 PATCH 0/2] Make snapcraft.yaml work

[Masahiro Yamada]

On Mon, Feb 19, 2024 at 5:07 PM Juerg Haefliger
<juerg.haefliger at canonical.com> wrote:
>
> 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



OK.


I completely misunderstood the reason for the rejection.
Sorry about that.


I will add the info to the LP tracker, and I hope this
patch will move forward.


Masahiro