On Wed, Mar 01, 2023 at 11:03:02AM +1030, Alex Murray wrote:
> Just wondering if you had a chance to review my feedback? It would be
> great to try and make some progress here.
We have a meeting later today, but I'll give you my own inputs.
The tl;dr: I'm more in-line with Dan comments.
> >>> * Establish and manage an effective process to handle backport
> >>>requests based solely on their technical merit.
> >>
> >> I'm not sure this is correct, to handle requests *solely* on technical
> >> merit. For example, part of the backport process is the expectation
> >> that the backport requestor/uploader will remain responsible for
> >> further backports as needed; if an uploaded backport seems technically
> >> correct but the backports team does not believe the uploader would be
> >> responsible for further uploads, the backports team should be able to
> >> reject the upload on that basis.
> >>
> >> Stating "solely on their technical merit" places undue restrictions on
> >> our team, I believe.
> >>
> >
> > I feel it is perhaps a bit too onerous to expect that just because a
> > user contributes one backport that they then should be expected to keep
> > doing backports for that package - this is placing undue restrictions on
> > your possible contributors. Regardless though, I don't think the
> > backports team should be trying to guess whether someone is likely to
> > contribute further backports in the future - this leaves too much chance
> > for the team to ignore proposed backports on arbitrary grounds. As such,
> > this is the exact point of the statement "solely on their technical
> > merit" - to give confidence to prospective users who want to contribute
> > backports that their submissions will be treated in a fair manner.
I'm sorry, but I do have and want to have some expectations that nobody
does *1* drive-by contribution and upload, and then the package is left
to bitrot in the backports pocket forevermore. Really, if that was
their goal, they are better served by a PPA.
We are clearly not enforcing this at this time, but I don't want to
restrict us.
From my own side, I'd propose this sentence instead:
* Establish and manage an effective process and a set of policies to
handle contributions to the "backports" pocket.
> >>> * Maintain the backports pocket based on this process, with an aim to
> >>>ensure all requests are responded to in a reasonable amount of time.
> >>
> >> What does "reasonable amount of time" mean?
> >>
> >
> > This is purposely non-specific - but again is here to give prospective
> > users confidence that their submissions will not sit ignored for an
> > indefinite period.
Too little specificity is not good. I'm not sure what's best (to write
down an arbitrary timeframe or what else), but having this sentence so
meaningless is worse than not having it, for me.
Potentially, I'd be more open to have a SLA-like rule in our internal
policies.
> >>> * Maintain quality in the backports pocket, where the definition of
> >>>quality is driven by the team, but decided by consensus within the
> >>>wider Ubuntu developer community.
> >>
> >> I'm not quite sure what this statement is trying to achieve, or what
> >> it would mean in practice. Can you clarify?
> >>
> >
> > This allows the backports team to take the lead on defining what is
> > required in terms of quality for submissions but also allows the
> > community to give feedback / input as well.
I'd drop this. Or at worse add a couple of words in the first point
about us defining policies.
> >>> * Handle process reform and membership management internally, ensuring
> >>>that any responsibility can be carried by any contributor who
> >>>demonstrates the required capacity and competence.
> >>
> >> I think this statement is even harder to read, can you clarify and/or
> >> reword it?
> >>
> >> For example, if we must handle process/membership "internally", does
> >> that mean we can't get outside input on those subjects? If not, then
> >> what is the point of the statement at all?
> >>
> >
> > This delegates authority to the backports team for these functions but
> > again makes a statement that hopefully gives prospective contributors
> > confidence that they can contribute just by demonstrating their
> > abilities. I don't see why this statement as written would preclude
> > getting outside input.
Proposal:
* Define a set of rules to handle the Backports Team memberships, its
internal structure and members' responsabilities.
> > So I think we are starting to get to the crux of the difference in
> > viewpoints from the TB to the backporters team. Due to the past history
> > of some perceived dysfunction within the backporters team, I feel it is
> > important to try and set some more specific expectations for how the
> > newly rebooted team would function - particularly to an outsider wishing
> > to contribute.
The problem in my opinion is that also your (rbasak's) original propos
