On Thu, 4 Apr 2019 at 14:26, Lukasz Zemczak
<lukasz.zemczak@canonical.com> wrote:
>
> I would also prefer not to see those in the description, especially
> that we'll have automated bug comments on autopkgtest regressions
> soon.
>
> That being said, I don't think someone not part of the SRU team should
> be editing the SRU tempate without discussion with the SRU team. Can
> we get this change reverted and at least have a discussion started
> about it? If we allow anyone updating the SRU process as they see fit,
> soon we'll have no official documentation and more people will be
> confused.
>
The SRU template was started by me, out of experience of having many
of my SRU uploads either linger in unapproved or getting rejected over
repeating reasons. It has improved velocity and quality of the SRU
process as experienced by the submitters. I have no idea if the SRU
team likes the template or not, as it's neither mandatory nor required
to be used, although many SRUs do use it.
The autopkgtest rergressions section is added by me, based on the
observation that many SRUs in verification-done state are neither
getting released nor getting any comments from neither submitters nor
the SRU team members. I also observed that this often happens when
there are autopkgtest regressions of the reverse triggers, and at the
moment there is no documentation on doing hints merges, nor automatic
notifications to the bug reports about them. I also observed that many
SRU submitters are proactively documenting autopkgtest regressions and
that their SRUs are getting released by the SRU team members faster,
than the other uncommented aging verification-done SRUs.
Thus the addition of this section, is merely a reflection of the
currently best-known way (which is proven to achieve the intended
result) to get an SRU released as seen performed by multiple people
across foundations, server, STS teams.
I have attempted to submit hints branch merge proposals, and attempted
to document them, but failed at this task due to multiple reasons.
Different sru team members preffer different style of hints, my hints
often were rewritten in a different format and/or consolidated, or out
right rejected "go and fix unrelated regressed in -updates
autopkgtests due to security uploads" and etc. My previous request to
the SRU team to document which hints, in what syntax, and where, and
in which situations you'd accept has been so far not actioned. See
previous mailing list thread in which Robie and I participated in.
Dear SRU team, have you written the documentations to stir people to
create hints merge proposals with guidance on syntax with examples?
Or given the complexity of the hints, and how infrequently most SRU
submitters have to work with them (unlike e.g. release team & sru
team), it would be nice if SRU team members upon releasing SRUs commit
appropriate hints to the hints branches as you see fit. It is beyond
doubt that SRU team members have the best working knowledge of hints.
And the burden to iterate hints with merge proposals & rejections /
rewrites based on SRU team member comments shouldn't be with the SRU
submitters. Especially since SRU team has never yet stated which hints
are desired/expected.
I am happy to revert this new section in the template, once there is
something better for SRU submitters to proactively help sheperd the
SRU themselves. At the moment, there is none, despite previous
requests.
--
Regards,
Dimitri.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
