Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Dan Streetman]

On Mon, Aug 9, 2021 at 5:51 PM Dan Streetman  wrote:
>
> On Wed, Jul 28, 2021 at 11:40 AM Dan Streetman  wrote:
> >
> > On Wed, Jul 28, 2021 at 10:20 AM Robie Basak  wrote:
> > >
> > > On Thu, Jul 22, 2021 at 05:00:26PM -0400, Dan Streetman wrote:
> > > > So as far as next steps based on your proposal, it seems like:
> > >
> > > I detailed the next steps specifically in my proposal but focused on
> > > slightly different things, so I appreciate you laying out your
> > > perspective also. What you suggest here is essentially the same anyway.
> >
> > sorry yes you did, agreed that my list was essentially the same as yours
> >
> > >
> > > > 1) Open call for initial volunteers
> > > > - I volunteer for the leadership role (at least for the initial
> > > > re-establishment), assuming there are no objections
> > >
> > > Looks like there have been no objections. To be clear, I understand that
> > > you're also volunteering for the day-to-day role?
> >
> > yes
> >
> > >
> > > > - mapreri volunteers for day-to-day role (thanks Mattia!)
> > > > - this email thread seems like a good enough call to the community for
> > > > anyone else who wants to volunteer, either in a leadership role or
> > > > day-to-day role
> > >
> > > +1. It appears that Mattia and Dan are currently the only volunteers.
> > >
> > > > 2) Administrative changes to ~ubuntu-backporters
> > > > - I don't see any public documentation on an existing process for
> > > > membership changes to ~ubuntu-backporters, so I assume your proposal
> > > > along with the disussion here is enough justification to ask the TB to
> > > > make the changes, assuming there is no objection from the TB of
> > > > course, or from existing active members (Laney I assume all this
> > > > sounds ok to you?)
> > >
> > > There has been no objection, so I intend to make the changes as agreed
> > > in this thread as soon as ~techboard gets control of the team. Since
> > > there is consensus here, I see no need to ask for TB permission
> > > specifically (or, if you prefer to consider it this way, I will use my
> > > TB hat to JFDI).
> > >
> > > I haven't managed to reach ScottK who currently owns the
> > > ~ubuntu-backporters team. However he stepped away from Ubuntu
> > > development quite a long time ago, and I don't think he would have any
> > > objection to handing over the reins to ~techboard. So I filed
> > > https://answers.launchpad.net/launchpad/+question/698165 yesterday to
> > > request this change.
> > >
> > > Assuming the change is made, following my proposal detail, I intend to
> > > remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> > > and then let Dan take it from there (I assume he will add Mattia as a
> > > team member, and maybe Iain).
> > >
> > > If we can't have ~ubuntu-backporters, I suppose I could register
> > > ~ubuntu-backporters2 and swap the queue ACLs over, but this seems
> > > unlikely (and suboptimal).
> >
> > +1 all sounds good to me
> >
> > >
> > > > 3) New team has initial public irc meeting (and email/chat
> > > > communication as needed) to make any process reforms (membership,
> > > > backports process, etc)
> > > > 4) update public documentation
> > > > 5) New team starts work on reviewing backports
> > > >
> > > > does that seem correct?
> > >
> > > This sounds good to me. These steps 3-5 would be for you (Dan) to
> > > organise.
> >
> > I'm fine with Mattia's suggestion for the first irc mtg the week of
> > Sept 6-10; my TZ is us/eastern (currently UTC-4) so my preference
> > would be anytime between 12:00 and 22:00 UTC, but I could push that a
> > bit earlier or later if needed.
> >
> > mapreri, teward, any preference on the day and/or time for the first
> > mtg? Does Wed, Sept 8 at 14:00 UTC sound ok?
>
> It sounds like both of you prefer this time or (preferably) later, so
> would Sept 8 at 16:00 UTC be agreeable for you? That's right in the
> middle of my day.
>
> Iain, and Robie if you plan to join, would that work for you as well?

Assuming there's no objecting to the proposed time, Sept 8 at 16:00
UTC, I've added it to the Ubuntu Fridge, and created an initial agenda
page:
https://wiki.ubuntu.com/UbuntuBackports/Agenda

Please feel free to update the agenda page with any topics anyone
thinks should be discussed at the meeting, and/or just show up to the
meeting to discuss anything - I think there are a few main items we
should talk about at this first meeting, but I don't think we
necessarily need a strict agenda.

Thanks!

>
> >
> > >
> > > Thanks,
> > >
> > > Robie

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Iain Lane]

On Mon, Aug 09, 2021 at 05:51:13PM -0400, Dan Streetman wrote:
> > mapreri, teward, any preference on the day and/or time for the first
> > mtg? Does Wed, Sept 8 at 14:00 UTC sound ok?
> 
> It sounds like both of you prefer this time or (preferably) later, so
> would Sept 8 at 16:00 UTC be agreeable for you? That's right in the
> middle of my day.
> 
> Iain, and Robie if you plan to join, would that work for you as well?

I should be able to make this (I'll add a calendar event now).

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Dan Streetman]

On Wed, Jul 28, 2021 at 11:40 AM Dan Streetman  wrote:
>
> On Wed, Jul 28, 2021 at 10:20 AM Robie Basak  wrote:
> >
> > On Thu, Jul 22, 2021 at 05:00:26PM -0400, Dan Streetman wrote:
> > > So as far as next steps based on your proposal, it seems like:
> >
> > I detailed the next steps specifically in my proposal but focused on
> > slightly different things, so I appreciate you laying out your
> > perspective also. What you suggest here is essentially the same anyway.
>
> sorry yes you did, agreed that my list was essentially the same as yours
>
> >
> > > 1) Open call for initial volunteers
> > > - I volunteer for the leadership role (at least for the initial
> > > re-establishment), assuming there are no objections
> >
> > Looks like there have been no objections. To be clear, I understand that
> > you're also volunteering for the day-to-day role?
>
> yes
>
> >
> > > - mapreri volunteers for day-to-day role (thanks Mattia!)
> > > - this email thread seems like a good enough call to the community for
> > > anyone else who wants to volunteer, either in a leadership role or
> > > day-to-day role
> >
> > +1. It appears that Mattia and Dan are currently the only volunteers.
> >
> > > 2) Administrative changes to ~ubuntu-backporters
> > > - I don't see any public documentation on an existing process for
> > > membership changes to ~ubuntu-backporters, so I assume your proposal
> > > along with the disussion here is enough justification to ask the TB to
> > > make the changes, assuming there is no objection from the TB of
> > > course, or from existing active members (Laney I assume all this
> > > sounds ok to you?)
> >
> > There has been no objection, so I intend to make the changes as agreed
> > in this thread as soon as ~techboard gets control of the team. Since
> > there is consensus here, I see no need to ask for TB permission
> > specifically (or, if you prefer to consider it this way, I will use my
> > TB hat to JFDI).
> >
> > I haven't managed to reach ScottK who currently owns the
> > ~ubuntu-backporters team. However he stepped away from Ubuntu
> > development quite a long time ago, and I don't think he would have any
> > objection to handing over the reins to ~techboard. So I filed
> > https://answers.launchpad.net/launchpad/+question/698165 yesterday to
> > request this change.
> >
> > Assuming the change is made, following my proposal detail, I intend to
> > remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> > and then let Dan take it from there (I assume he will add Mattia as a
> > team member, and maybe Iain).
> >
> > If we can't have ~ubuntu-backporters, I suppose I could register
> > ~ubuntu-backporters2 and swap the queue ACLs over, but this seems
> > unlikely (and suboptimal).
>
> +1 all sounds good to me
>
> >
> > > 3) New team has initial public irc meeting (and email/chat
> > > communication as needed) to make any process reforms (membership,
> > > backports process, etc)
> > > 4) update public documentation
> > > 5) New team starts work on reviewing backports
> > >
> > > does that seem correct?
> >
> > This sounds good to me. These steps 3-5 would be for you (Dan) to
> > organise.
>
> I'm fine with Mattia's suggestion for the first irc mtg the week of
> Sept 6-10; my TZ is us/eastern (currently UTC-4) so my preference
> would be anytime between 12:00 and 22:00 UTC, but I could push that a
> bit earlier or later if needed.
>
> mapreri, teward, any preference on the day and/or time for the first
> mtg? Does Wed, Sept 8 at 14:00 UTC sound ok?

It sounds like both of you prefer this time or (preferably) later, so
would Sept 8 at 16:00 UTC be agreeable for you? That's right in the
middle of my day.

Iain, and Robie if you plan to join, would that work for you as well?

>
> >
> > Thanks,
> >
> > Robie

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Dan Streetman]

On Fri, Jul 30, 2021 at 12:11 PM Robie Basak  wrote:
>
> Hi Iain,
>
> Perhaps I see the situation differently from you. From my perspective,
> this is an extraordinary intervention "from above" by consensus from
> Ubuntu developers. The backporters team has been unable to act for an
> extended period of time, and when threatened with closure, nobody from
> the team has been able to volunteer to continue in any role, let alone a
> leadership role. Others _have_ volunteered; therefore the team is being
> replaced.
>
> Nothing stops previous team members from continuing, subject to any
> requirements from _new_ team leadership, but they haven't even
> volunteered to continue. From my perspective they have effectively
> resigned through their extended absence.
>
> On Fri, Jul 30, 2021 at 02:24:31PM +0100, Iain Lane wrote:
> > > Assuming the change is made, following my proposal detail, I intend to
> > > remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> > > and then let Dan take it from there (I assume he will add Mattia as a
> > > team member, and maybe Iain).
> >
> > To be honest, I think you could - and I'd prefer it if you would - leave
> > this up to the team, especially if there are newly active members.
>
> From my perspective, this would be as if people who have neglected[1]
> matters for years, and effectively blocked progress, would be retaining
> their ability to block progress. This is why I'm against your
> suggestion.
>
> IMHO, previous team members who have not participated in this thread
> should therefore no longer have the status of being in the team. I agree
> with you to leave membership up to the team, but I might differ from you
> in that I want this to be up to the *new team*, not people who have
> their name attached but haven't done anything for the team in multiple
> years and are not stepping up to do so now. IMHO the old and inactive
> team members should, due to neglect[1], have no more say than the wider
> set of Ubuntu developers in this matter. I value their experience and
> opinions, but the final decision making should no longer be up to them
> due to their extended absence. IMHO, any previous backporters team
> member who doesn't want this to happen has had multiple opportunities to
> step up or speak up, and has not done so.
>
> You, Iain, are an exception because you have actually participated in
> the conversation. Thank you :)
>
> Further IMHO, I think having old inactive members there is harmful. For
> example, for years people have been blocked on backports under the
> illusion that the team exists and team members just need to appear to
> review and approve their stuff. In reality, the team ceased to exist
> years ago; it was just Launchpad that was behind. If the team membership
> in Launchpad had been empty accordingly, we'd probably have sought to
> address the situation much sooner.
>
> So, my proposal is to empty the team membership, _once_, as part of this
> revitalisation. IMHO, only those volunteering to do the whole task of
> resurrecting the backports process (so far that's just Dan) should
> really have a decision making power here, since they are the only ones
> actually taking responsibility. Then the new team members will manage
> the team membership list as they feel appropriate.
>
> > I'd like to talk with the new team about this, but I'm personally not
> > interested in participating in the current process. It's broken by
> > design IMO. I'd be interested in participating in creating a reformed
> > process and more than happy to explain to the team what I consider to be
> > wrong with the way things are now, but I'll probably not be leading any
> > reform efforts myself just for spoons reasons. On that basis I'd be OK
> > stepping down from being an administrator, and possibly leaving the team
> > altogether, depending on what the active members consider their
> > priorities to be.
>
> Thank you for staying involved! Under my proposal I would expect you to
> end up being re-added, but I think that would/should be entirely up to
> the new team to decide. Specifically this is because if you're unable to
> help drive the reform, then that's fine but I think that also means that
> you cannot also be a decision-maker as to whether you get re-added or
> not. That would be up to those who _are_ driving the reform, since part
> of their remit and responsibility is to drive the process for team
> membership.
>
> >   Again I'd prefer to work that out with the team rather
> > than the new owners doing this 'from above'.
>
> IMHO, that ship has sailed. The "from above" approach has become
> necessary because the existing team and team leadership has not managed
> to make any progress on this themselves; nor did they engage when Thomas
> volunteered to join the team to help. You can't have it both ways here.
>
> I expect Dan to work with you, and Ubuntu developers at large, to figure
> out a process that works for everybody. But

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Iain Lane]

On Fri, Jul 30, 2021 at 09:46:37PM +0200, Mattia Rizzolo wrote:
>  FTR, I don't feel as strongly as Robie seems to, but I agree that the
> previous team should be emptied from Launchpad.

I do too, to be honest. Now that the backporters team is reconstituted 
as a result of this thread, I think it can take that decision and do the 
actual deactivations itself.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Mattia Rizzolo]

 FTR, I don't feel as strongly as Robie seems to, but I agree that the
previous team should be emptied from Launchpad.

On Fri, Jul 30, 2021 at 6:11 PM Robie Basak  wrote:
>
> Hi Iain,
>
> Perhaps I see the situation differently from you. From my perspective,
> this is an extraordinary intervention "from above" by consensus from
> Ubuntu developers. The backporters team has been unable to act for an
> extended period of time, and when threatened with closure, nobody from
> the team has been able to volunteer to continue in any role, let alone a
> leadership role. Others _have_ volunteered; therefore the team is being
> replaced.
>
> Nothing stops previous team members from continuing, subject to any
> requirements from _new_ team leadership, but they haven't even
> volunteered to continue. From my perspective they have effectively
> resigned through their extended absence.
>
> On Fri, Jul 30, 2021 at 02:24:31PM +0100, Iain Lane wrote:
> > > Assuming the change is made, following my proposal detail, I intend to
> > > remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> > > and then let Dan take it from there (I assume he will add Mattia as a
> > > team member, and maybe Iain).
> >
> > To be honest, I think you could - and I'd prefer it if you would - leave
> > this up to the team, especially if there are newly active members.
>
> From my perspective, this would be as if people who have neglected[1]
> matters for years, and effectively blocked progress, would be retaining
> their ability to block progress. This is why I'm against your
> suggestion.
>
> IMHO, previous team members who have not participated in this thread
> should therefore no longer have the status of being in the team. I agree
> with you to leave membership up to the team, but I might differ from you
> in that I want this to be up to the *new team*, not people who have
> their name attached but haven't done anything for the team in multiple
> years and are not stepping up to do so now. IMHO the old and inactive
> team members should, due to neglect[1], have no more say than the wider
> set of Ubuntu developers in this matter. I value their experience and
> opinions, but the final decision making should no longer be up to them
> due to their extended absence. IMHO, any previous backporters team
> member who doesn't want this to happen has had multiple opportunities to
> step up or speak up, and has not done so.
>
> You, Iain, are an exception because you have actually participated in
> the conversation. Thank you :)
>
> Further IMHO, I think having old inactive members there is harmful. For
> example, for years people have been blocked on backports under the
> illusion that the team exists and team members just need to appear to
> review and approve their stuff. In reality, the team ceased to exist
> years ago; it was just Launchpad that was behind. If the team membership
> in Launchpad had been empty accordingly, we'd probably have sought to
> address the situation much sooner.
>
> So, my proposal is to empty the team membership, _once_, as part of this
> revitalisation. IMHO, only those volunteering to do the whole task of
> resurrecting the backports process (so far that's just Dan) should
> really have a decision making power here, since they are the only ones
> actually taking responsibility. Then the new team members will manage
> the team membership list as they feel appropriate.
>
> > I'd like to talk with the new team about this, but I'm personally not
> > interested in participating in the current process. It's broken by
> > design IMO. I'd be interested in participating in creating a reformed
> > process and more than happy to explain to the team what I consider to be
> > wrong with the way things are now, but I'll probably not be leading any
> > reform efforts myself just for spoons reasons. On that basis I'd be OK
> > stepping down from being an administrator, and possibly leaving the team
> > altogether, depending on what the active members consider their
> > priorities to be.
>
> Thank you for staying involved! Under my proposal I would expect you to
> end up being re-added, but I think that would/should be entirely up to
> the new team to decide. Specifically this is because if you're unable to
> help drive the reform, then that's fine but I think that also means that
> you cannot also be a decision-maker as to whether you get re-added or
> not. That would be up to those who _are_ driving the reform, since part
> of their remit and responsibility is to drive the process for team
> membership.
>
> >   Again I'd prefer to work that out with the team rather
> > than the new owners doing this 'from above'.
>
> IMHO, that ship has sailed. The "from above" approach has become
> necessary because the existing team and team leadership has not managed
> to make any progress on this themselves; nor did they engage when Thomas
> volunteered to join the team to help. You can't have it both ways here.
>
>

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Robie Basak]

Hi Iain,

Perhaps I see the situation differently from you. From my perspective,
this is an extraordinary intervention "from above" by consensus from
Ubuntu developers. The backporters team has been unable to act for an
extended period of time, and when threatened with closure, nobody from
the team has been able to volunteer to continue in any role, let alone a
leadership role. Others _have_ volunteered; therefore the team is being
replaced.

Nothing stops previous team members from continuing, subject to any
requirements from _new_ team leadership, but they haven't even
volunteered to continue. From my perspective they have effectively
resigned through their extended absence.

On Fri, Jul 30, 2021 at 02:24:31PM +0100, Iain Lane wrote:
> > Assuming the change is made, following my proposal detail, I intend to
> > remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> > and then let Dan take it from there (I assume he will add Mattia as a
> > team member, and maybe Iain).
> 
> To be honest, I think you could - and I'd prefer it if you would - leave 
> this up to the team, especially if there are newly active members.

From my perspective, this would be as if people who have neglected[1]
matters for years, and effectively blocked progress, would be retaining
their ability to block progress. This is why I'm against your
suggestion.

IMHO, previous team members who have not participated in this thread
should therefore no longer have the status of being in the team. I agree
with you to leave membership up to the team, but I might differ from you
in that I want this to be up to the *new team*, not people who have
their name attached but haven't done anything for the team in multiple
years and are not stepping up to do so now. IMHO the old and inactive
team members should, due to neglect[1], have no more say than the wider
set of Ubuntu developers in this matter. I value their experience and
opinions, but the final decision making should no longer be up to them
due to their extended absence. IMHO, any previous backporters team
member who doesn't want this to happen has had multiple opportunities to
step up or speak up, and has not done so.

You, Iain, are an exception because you have actually participated in
the conversation. Thank you :)

Further IMHO, I think having old inactive members there is harmful. For
example, for years people have been blocked on backports under the
illusion that the team exists and team members just need to appear to
review and approve their stuff. In reality, the team ceased to exist
years ago; it was just Launchpad that was behind. If the team membership
in Launchpad had been empty accordingly, we'd probably have sought to
address the situation much sooner.

So, my proposal is to empty the team membership, _once_, as part of this
revitalisation. IMHO, only those volunteering to do the whole task of
resurrecting the backports process (so far that's just Dan) should
really have a decision making power here, since they are the only ones
actually taking responsibility. Then the new team members will manage
the team membership list as they feel appropriate.

> I'd like to talk with the new team about this, but I'm personally not 
> interested in participating in the current process. It's broken by 
> design IMO. I'd be interested in participating in creating a reformed 
> process and more than happy to explain to the team what I consider to be 
> wrong with the way things are now, but I'll probably not be leading any 
> reform efforts myself just for spoons reasons. On that basis I'd be OK 
> stepping down from being an administrator, and possibly leaving the team 
> altogether, depending on what the active members consider their 
> priorities to be.

Thank you for staying involved! Under my proposal I would expect you to
end up being re-added, but I think that would/should be entirely up to
the new team to decide. Specifically this is because if you're unable to
help drive the reform, then that's fine but I think that also means that
you cannot also be a decision-maker as to whether you get re-added or
not. That would be up to those who _are_ driving the reform, since part
of their remit and responsibility is to drive the process for team
membership.

>   Again I'd prefer to work that out with the team rather 
> than the new owners doing this 'from above'.

IMHO, that ship has sailed. The "from above" approach has become
necessary because the existing team and team leadership has not managed
to make any progress on this themselves; nor did they engage when Thomas
volunteered to join the team to help. You can't have it both ways here.

I expect Dan to work with you, and Ubuntu developers at large, to figure
out a process that works for everybody. But I don't think he should be
tied by the need to seek approval from team alumni who have neglected
their responsibilities for years[1]. I think that one way to make this
clear is by explicitly removing old, ina

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Iain Lane]

On Wed, Jul 28, 2021 at 03:20:45PM +0100, Robie Basak wrote:
> > 2) Administrative changes to ~ubuntu-backporters
> > - I don't see any public documentation on an existing process for
> > membership changes to ~ubuntu-backporters, so I assume your proposal
> > along with the disussion here is enough justification to ask the TB to
> > make the changes, assuming there is no objection from the TB of
> > course, or from existing active members (Laney I assume all this
> > sounds ok to you?)
> 
> There has been no objection, so I intend to make the changes as agreed
> in this thread as soon as ~techboard gets control of the team. Since
> there is consensus here, I see no need to ask for TB permission
> specifically (or, if you prefer to consider it this way, I will use my
> TB hat to JFDI).

I'm going to add Dan and Mattia right now (done). We just received a 
request to transfer ownership of the team to the TB, which I agreed to.

> Assuming the change is made, following my proposal detail, I intend to
> remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> and then let Dan take it from there (I assume he will add Mattia as a
> team member, and maybe Iain).

To be honest, I think you could - and I'd prefer it if you would - leave 
this up to the team, especially if there are newly active members.

I'd like to talk with the new team about this, but I'm personally not 
interested in participating in the current process. It's broken by 
design IMO. I'd be interested in participating in creating a reformed 
process and more than happy to explain to the team what I consider to be 
wrong with the way things are now, but I'll probably not be leading any 
reform efforts myself just for spoons reasons. On that basis I'd be OK 
stepping down from being an administrator, and possibly leaving the team 
altogether, depending on what the active members consider their 
priorities to be. Again I'd prefer to work that out with the team rather 
than the new owners doing this 'from above'.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Thomas Ward]

On 7/28/21 11:40 AM, Dan Streetman wrote:


mapreri, teward, any preference on the day and/or time for the first
mtg? Does Wed, Sept 8 at 14:00 UTC sound ok?


Thanks,

Robie



That works for me, but no earlier than that on that day.  Any time later 
in the day is sufficient for me.



Thomas

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Mattia Rizzolo]

On Wed, Jul 28, 2021 at 11:40:47AM -0400, Dan Streetman wrote:
> I'm fine with Mattia's suggestion for the first irc mtg the week of
> Sept 6-10; my TZ is us/eastern (currently UTC-4) so my preference
> would be anytime between 12:00 and 22:00 UTC, but I could push that a
> bit earlier or later if needed.

I'm based in central Europe, so CEST (currently UTC+2), and I'm a late
sleeper, so my normal times for meetings is between 9:00-21:00 UTC.
22:00 UTC would start be a tad late for me.

> mapreri, teward, any preference on the day and/or time for the first
> mtg? Does Wed, Sept 8 at 14:00 UTC sound ok?

Now, you picked a week where I'll likely be busy during daytime, so I'd
be available only after 16:00 UTC or so.

So I'd be up for https://time.is/compare/1600_08_Sep_2021_in_UTC :)

That said, it's more than a month away, and covid is still in flux, so
who knows how my exact time availability might be!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Dan Streetman]

On Wed, Jul 28, 2021 at 10:20 AM Robie Basak  wrote:
>
> On Thu, Jul 22, 2021 at 05:00:26PM -0400, Dan Streetman wrote:
> > So as far as next steps based on your proposal, it seems like:
>
> I detailed the next steps specifically in my proposal but focused on
> slightly different things, so I appreciate you laying out your
> perspective also. What you suggest here is essentially the same anyway.

sorry yes you did, agreed that my list was essentially the same as yours

>
> > 1) Open call for initial volunteers
> > - I volunteer for the leadership role (at least for the initial
> > re-establishment), assuming there are no objections
>
> Looks like there have been no objections. To be clear, I understand that
> you're also volunteering for the day-to-day role?

yes

>
> > - mapreri volunteers for day-to-day role (thanks Mattia!)
> > - this email thread seems like a good enough call to the community for
> > anyone else who wants to volunteer, either in a leadership role or
> > day-to-day role
>
> +1. It appears that Mattia and Dan are currently the only volunteers.
>
> > 2) Administrative changes to ~ubuntu-backporters
> > - I don't see any public documentation on an existing process for
> > membership changes to ~ubuntu-backporters, so I assume your proposal
> > along with the disussion here is enough justification to ask the TB to
> > make the changes, assuming there is no objection from the TB of
> > course, or from existing active members (Laney I assume all this
> > sounds ok to you?)
>
> There has been no objection, so I intend to make the changes as agreed
> in this thread as soon as ~techboard gets control of the team. Since
> there is consensus here, I see no need to ask for TB permission
> specifically (or, if you prefer to consider it this way, I will use my
> TB hat to JFDI).
>
> I haven't managed to reach ScottK who currently owns the
> ~ubuntu-backporters team. However he stepped away from Ubuntu
> development quite a long time ago, and I don't think he would have any
> objection to handing over the reins to ~techboard. So I filed
> https://answers.launchpad.net/launchpad/+question/698165 yesterday to
> request this change.
>
> Assuming the change is made, following my proposal detail, I intend to
> remove everyone from ~ubuntu-backports and add Dan as its sole admin,
> and then let Dan take it from there (I assume he will add Mattia as a
> team member, and maybe Iain).
>
> If we can't have ~ubuntu-backporters, I suppose I could register
> ~ubuntu-backporters2 and swap the queue ACLs over, but this seems
> unlikely (and suboptimal).

+1 all sounds good to me

>
> > 3) New team has initial public irc meeting (and email/chat
> > communication as needed) to make any process reforms (membership,
> > backports process, etc)
> > 4) update public documentation
> > 5) New team starts work on reviewing backports
> >
> > does that seem correct?
>
> This sounds good to me. These steps 3-5 would be for you (Dan) to
> organise.

I'm fine with Mattia's suggestion for the first irc mtg the week of
Sept 6-10; my TZ is us/eastern (currently UTC-4) so my preference
would be anytime between 12:00 and 22:00 UTC, but I could push that a
bit earlier or later if needed.

mapreri, teward, any preference on the day and/or time for the first
mtg? Does Wed, Sept 8 at 14:00 UTC sound ok?

>
> Thanks,
>
> Robie

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Robie Basak]

On Wed, Jul 28, 2021 at 10:53:37AM -0400, Thomas Ward wrote:
> I volunteered via IRC in #ubuntu-devel to ddstreet.  I think that got buried
> though...

Great. Thank you!


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Thomas Ward]

FYI, though it was via IRC and not Email due to my email being fubar at 
the time:


On 7/28/21 10:20 AM, Robie Basak wrote:

On Thu, Jul 22, 2021 at 05:00:26PM -0400, Dan Streetman wrote:

- mapreri volunteers for day-to-day role (thanks Mattia!)
- this email thread seems like a good enough call to the community for
anyone else who wants to volunteer, either in a leadership role or
day-to-day role

+1. It appears that Mattia and Dan are currently the only volunteers.


I volunteered via IRC in #ubuntu-devel to ddstreet.  I think that got 
buried though...




Thanks,

Robie



Thomas

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Robie Basak]

Hi Mattia,

Thank you for organising getting things going!

I'll stay out of any decisions since I won't be a member of the new
team. I'd like to suggest, though, that you try and keep discussion in
ubuntu-devel@ if possible. IMHO, keeping ubuntu-backports@ discussions
separately in its own list will only hurt opportunities to get more
Ubuntu developers involved in backporting activities. I would only split
off into a different list if traffic gets too dense in the more general
place.

However, that's just my opinion and it should be entirely up to the new
team to decide how to run their affairs. I'm just happy to see the team
active again!

Robie


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Robie Basak]

On Thu, Jul 22, 2021 at 05:00:26PM -0400, Dan Streetman wrote:
> So as far as next steps based on your proposal, it seems like:

I detailed the next steps specifically in my proposal but focused on
slightly different things, so I appreciate you laying out your
perspective also. What you suggest here is essentially the same anyway.

> 1) Open call for initial volunteers
> - I volunteer for the leadership role (at least for the initial
> re-establishment), assuming there are no objections

Looks like there have been no objections. To be clear, I understand that
you're also volunteering for the day-to-day role?

> - mapreri volunteers for day-to-day role (thanks Mattia!)
> - this email thread seems like a good enough call to the community for
> anyone else who wants to volunteer, either in a leadership role or
> day-to-day role

+1. It appears that Mattia and Dan are currently the only volunteers.

> 2) Administrative changes to ~ubuntu-backporters
> - I don't see any public documentation on an existing process for
> membership changes to ~ubuntu-backporters, so I assume your proposal
> along with the disussion here is enough justification to ask the TB to
> make the changes, assuming there is no objection from the TB of
> course, or from existing active members (Laney I assume all this
> sounds ok to you?)

There has been no objection, so I intend to make the changes as agreed
in this thread as soon as ~techboard gets control of the team. Since
there is consensus here, I see no need to ask for TB permission
specifically (or, if you prefer to consider it this way, I will use my
TB hat to JFDI).

I haven't managed to reach ScottK who currently owns the
~ubuntu-backporters team. However he stepped away from Ubuntu
development quite a long time ago, and I don't think he would have any
objection to handing over the reins to ~techboard. So I filed
https://answers.launchpad.net/launchpad/+question/698165 yesterday to
request this change.

Assuming the change is made, following my proposal detail, I intend to
remove everyone from ~ubuntu-backports and add Dan as its sole admin,
and then let Dan take it from there (I assume he will add Mattia as a
team member, and maybe Iain).

If we can't have ~ubuntu-backporters, I suppose I could register
~ubuntu-backporters2 and swap the queue ACLs over, but this seems
unlikely (and suboptimal).

> 3) New team has initial public irc meeting (and email/chat
> communication as needed) to make any process reforms (membership,
> backports process, etc)
> 4) update public documentation
> 5) New team starts work on reviewing backports
> 
> does that seem correct?

This sounds good to me. These steps 3-5 would be for you (Dan) to
organise.

Thanks,

Robie


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Mattia Rizzolo]

[ FYI: I just subscribed ubuntu-backports@ (where I wasn't before) - so
if we want to discuss specific bpo plans we can drop u-devel@  ]

On Thu, Jul 22, 2021 at 05:00:26PM -0400, Dan Streetman wrote:
> 1) Open call for initial volunteers
> - this email thread seems like a good enough call to the community for
> anyone else who wants to volunteer, either in a leadership role or
> day-to-day role
> 2) Administrative changes to ~ubuntu-backporters
> - I don't see any public documentation on an existing process for
> membership changes to ~ubuntu-backporters, so I assume your proposal
> along with the disussion here is enough justification to ask the TB to
> make the changes, assuming there is no objection from the TB of
> course, or from existing active members (Laney I assume all this
> sounds ok to you?)
> 3) New team has initial public irc meeting (and email/chat
> communication as needed) to make any process reforms (membership,
> backports process, etc)

TBH, I'd swap these items 2 and 3 ;)
Better decide everything in one swoop rather than risking needing any
change later again.

> 4) update public documentation
> 5) New team starts work on reviewing backports


Shall we settle on some dates already?  Keeping in mind that August is a
month of holiday for quite a few people, plus there is the Debian
release in the middle, what about settling on September 5th as a
deadline for point 1, trying for an (IRC?) meeting sometime the next
week?  I'm being very slow-minded in my scheduling here, if you'd like
to keep a quicker momentum, I can agree with an earlier date as well.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Dan Streetman]

On Wed, Jul 21, 2021 at 6:11 AM Robie Basak  wrote:
>
> Thank you for volunteering! As we have at least one qualified person
> committed, I'd be very happy to see the backports pocket continue. As a
> concrete proposal, I suggest we do this by reforming ~ubuntu-backporters
> as follows.
>
> In particular I wanted to enumerate a specific transition plan and the
> reformed team's responsibities below, since my opinion on sunsetting the
> backports pocket is only moot if this actually happens.
>
> Feedback appreciated!
>
> # Team Roles
>
> For clarity, initially there will be two roles in the team: 1) a
> leadership role, driving re-establishment and reform; 2) people doing
> the regular day-to-day work, such as reviews.
>
> I think the first role could only effectively be taken by suitably
> qualified, existing and established Ubuntu developers. We'll see if
> there are any other volunteers, and if there are, see if there is
> consensus that they can also take on the role.
>
> The second role would be open to anyone who meets the requirements of
> the new process, which is yet to be defined.
>
> To get started I suggest continuing the old process, while allowing for
> the new team's leadership to drive process reform.
>
> # Transition Plan
>
>  * This entire plan is predicated on there being at least one suitably
>qualified, experienced and established Ubuntu developer committed to
>taking on both roles. So far, that's Dan, but others may join him.
>
>  * ~techboard takes ownership of ~ubuntu-backporters.
>
>  * Existing but inactive team members are removed.
>
>  * Those that we have agreed will take on the first role are added as
>team admins.
>
>  * Those still active in the team and are willing to do the second role
>(if any; I think only Iain qualifies if he is willing) are added as
>regular team members.
>
>  * A process for future management of team membership would be up to the
>team itself to establish.
>
> # Team responsibilities
>
> Here I've tried to define what we need, rather than specify how the
> backporters team will deliver it. I'd prefer to leave the team to drive
> that. For example, Gunnar asked some good questions in the thread; I've
> deliberately not answered those, leaving that for the backporters team
> to figure out later as part of the process reform.
>
>  * Establish and manage an effective process to handle backport
>requests. Any review process must accept or reject every backport
>request on its technical merit, and be neutral to who is requesting
>it[1].
>
>  * Maintain the backports pocket based on this process, making sure that
>all requests receive an appropriate answer in a reasonable amount of
>time.
>
>  * Maintain quality in the backports pocket, where the definition of
>quality is driven by the team, but defined by consensus within the
>wider Ubuntu developer community.
>
>  * Handle your own process reform and membership management, but making
>sure that any responsibility can be carried by any contributor who
>demonstrates the required capacity and competence. Specifically,
>since the DMB has never managed membership of ~ubuntu-backporters,
>there is no requirement for the DMB to be involved. Unless you want
>to delegate that, in which case that's a conversation to have with
>the DMB.
>
> How does this sound? Feedback appreciated.

I'm in agreement with everything.

So as far as next steps based on your proposal, it seems like:

1) Open call for initial volunteers
- I volunteer for the leadership role (at least for the initial
re-establishment), assuming there are no objections
- mapreri volunteers for day-to-day role (thanks Mattia!)
- this email thread seems like a good enough call to the community for
anyone else who wants to volunteer, either in a leadership role or
day-to-day role
2) Administrative changes to ~ubuntu-backporters
- I don't see any public documentation on an existing process for
membership changes to ~ubuntu-backporters, so I assume your proposal
along with the disussion here is enough justification to ask the TB to
make the changes, assuming there is no objection from the TB of
course, or from existing active members (Laney I assume all this
sounds ok to you?)
3) New team has initial public irc meeting (and email/chat
communication as needed) to make any process reforms (membership,
backports process, etc)
4) update public documentation
5) New team starts work on reviewing backports

does that seem correct?

>
> Robie
>
>
> [1] To be clear, I believe that the current process requires
> sponsorship/upload of a suitable backport, and the backporters team only
> reviews once an upload has taken place. I am not suggesting that we
> require the backporters team to do any more than that - for example
> responding to a backport request with no upload with "please find a
> sponsor[2] to upload an appropriate backported package and then we'll
> review it" would be fine. But the p

Re: Proposal: sunset the backports pockets

[Dan Streetman]

On Tue, Jul 20, 2021 at 8:38 AM Gunnar Hjalmarsson  wrote:
>
> On 2021-07-20 13:58, Dan Streetman wrote:
> > Yes, objection here. The backports pocket is still in use.
> >
> > If I understand correctly, as discussed in much greater length in
> > other posts in this thread, the sole problem with the backports
> > process is lack of time for the Ubuntu Backports Team to actually
> > review uploads to the -backports pocket.
> >
> > If that's the case, then the Canonical Sustaining Engineering Group
> > is happy to take that over (since 'sustaining' the stable releases
> > is...our job), please feel free to ping me about ACLs and process
> > tooling for approving -backports uploads and we'll start reviewing
> > the queues.
>
> That sounds promising, Dan.
>
> As regards uploads in the queues, I had a quick look yesterday. I found
> one item in bionic and four ones in focal. But only one (1) item had a
> reference to a bug report with the expected justification, test results etc.
>
> But then we have all the backport requests which are not yet uploaded:
>
> https://bugs.launchpad.net/bionic-backports
>
> https://bugs.launchpad.net/focal-backports
>
>  gives the impression that the
> uploads should be carried out by an ~ubuntu-backporters member in
> connection with the review.
>
> So if the Canonical Sustaining Engineering Group steps up — which is
> excellent, of course — there still seems to be room for clarification of
> the process.
>
> * Who can/should upload?
>
> * Should sponsorship be sought for uploads to the -backports queues?

definitely good points to clarify, we should probably move any
clarifications over to rbasak's new thread

>
> --
> Cheers,
>
> Gunnar Hjalmarsson
> https://launchpad.net/~gunnarhj

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Gunnar Hjalmarsson]

On 2021-07-21 14:06, Robie Basak wrote:

I haven't checked myself, but there seem to be different opinions on
how it currently works, exactly, based on the discussion so far.


The last para of  is ambiguous, 
and may explain the differences in opinion.



However, I think we're all agreed on the process to reform it, so
I'll leave the details to the newly formed backporters team to sort
out :)


Thanks for making it happen, Robie!

--
Cheers,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

--
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Robie Basak]

Hi Mattia,

Thank you for your support, and for volunteering for the second role!

On Wed, Jul 21, 2021 at 12:56:07PM +0200, Mattia Rizzolo wrote:
> > [1] To be clear, I believe that the current process requires
> > sponsorship/upload of a suitable backport, and the backporters team only
> > reviews once an upload has taken place.
> 
> I believe you are wrong on this.
> They way the current process is worded, uploads should be done by people
> in ~ubuntu-backports only, effectively causing a huge load on the team.
> The reform needed here (as you more or less imply), is that upload
> rights should follow the usual rules, with ~ubuntu-backports only
> reviewing the uploads once they end in the "unapproved" queue (i have no
> idea how the staging queue for backports is currently called).

The point I was trying to make in my footnote was merely that I'm not
intending to demand that the backporters team take on all the work
themselves as soon as someone requests a backport without providing any
further work themselves.

I haven't checked myself, but there seem to be different opinions on how
it currently works, exactly, based on the discussion so far. However, I
think we're all agreed on the process to reform it, so I'll leave the
details to the newly formed backporters team to sort out :)

Robie


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Mattia Rizzolo]

Hi!

Thank you Robie for drafting this!

On Wed, Jul 21, 2021 at 11:11:33AM +0100, Robie Basak wrote:
> # Team Roles
> 
> For clarity, initially there will be two roles in the team: 1) a
> leadership role, driving re-establishment and reform; 2) people doing
> the regular day-to-day work, such as reviews.
> 
> I think the first role could only effectively be taken by suitably
> qualified, existing and established Ubuntu developers. We'll see if
> there are any other volunteers, and if there are, see if there is
> consensus that they can also take on the role.

I agree on this.

> The second role would be open to anyone who meets the requirements of
> the new process, which is yet to be defined.

I also hereby volunteer me for the day-to-day tasks.
Mostly, I don't have enough cycles available to drive discussions and
anything related on how to reform the process, else I'd volunteer for
more, but if anything I'm positive I can handle reviews and similar.
As such, I'm happy to follow Dan or whoever is going to take lead on the
project, provided that they present a viable reform path.

> # Team responsibilities
> 
>  * Establish and manage an effective process to handle backport
>requests. Any review process must accept or reject every backport
>request on its technical merit, and be neutral to who is requesting
>it[1].
> 
>  * Maintain the backports pocket based on this process, making sure that
>all requests receive an appropriate answer in a reasonable amount of
>time.
> 
>  * Maintain quality in the backports pocket, where the definition of
>quality is driven by the team, but defined by consensus within the
>wider Ubuntu developer community.
> 
>  * Handle your own process reform and membership management, but making
>sure that any responsibility can be carried by any contributor who
>demonstrates the required capacity and competence. Specifically,
>since the DMB has never managed membership of ~ubuntu-backporters,
>there is no requirement for the DMB to be involved. Unless you want
>to delegate that, in which case that's a conversation to have with
>the DMB.

I don't think there is a need to involve the DMB here.  I'd just say
that any members should be part of ~ubuntu-dev already, nothing more
complex than that.

> How does this sound? Feedback appreciated.

Nothing to add, your starter is great already, now we only need a lead
to lead :)

> [1] To be clear, I believe that the current process requires
> sponsorship/upload of a suitable backport, and the backporters team only
> reviews once an upload has taken place.

I believe you are wrong on this.
They way the current process is worded, uploads should be done by people
in ~ubuntu-backports only, effectively causing a huge load on the team.
The reform needed here (as you more or less imply), is that upload
rights should follow the usual rules, with ~ubuntu-backports only
reviewing the uploads once they end in the "unapproved" queue (i have no
idea how the staging queue for backports is currently called).

> [2] Availability of sponsors is a separate issue. I'd like to address
> that too, but I don't think it's appropriate to pull that into the scope
> of backports reform.

Aye, unrelated.


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]

[Robie Basak]

Thank you for volunteering! As we have at least one qualified person
committed, I'd be very happy to see the backports pocket continue. As a
concrete proposal, I suggest we do this by reforming ~ubuntu-backporters
as follows.

In particular I wanted to enumerate a specific transition plan and the
reformed team's responsibities below, since my opinion on sunsetting the
backports pocket is only moot if this actually happens.

Feedback appreciated!

# Team Roles

For clarity, initially there will be two roles in the team: 1) a
leadership role, driving re-establishment and reform; 2) people doing
the regular day-to-day work, such as reviews.

I think the first role could only effectively be taken by suitably
qualified, existing and established Ubuntu developers. We'll see if
there are any other volunteers, and if there are, see if there is
consensus that they can also take on the role.

The second role would be open to anyone who meets the requirements of
the new process, which is yet to be defined.

To get started I suggest continuing the old process, while allowing for
the new team's leadership to drive process reform.

# Transition Plan

 * This entire plan is predicated on there being at least one suitably
   qualified, experienced and established Ubuntu developer committed to
   taking on both roles. So far, that's Dan, but others may join him.

 * ~techboard takes ownership of ~ubuntu-backporters.

 * Existing but inactive team members are removed.

 * Those that we have agreed will take on the first role are added as
   team admins.

 * Those still active in the team and are willing to do the second role
   (if any; I think only Iain qualifies if he is willing) are added as
   regular team members.

 * A process for future management of team membership would be up to the
   team itself to establish.

# Team responsibilities

Here I've tried to define what we need, rather than specify how the
backporters team will deliver it. I'd prefer to leave the team to drive
that. For example, Gunnar asked some good questions in the thread; I've
deliberately not answered those, leaving that for the backporters team
to figure out later as part of the process reform.

 * Establish and manage an effective process to handle backport
   requests. Any review process must accept or reject every backport
   request on its technical merit, and be neutral to who is requesting
   it[1].

 * Maintain the backports pocket based on this process, making sure that
   all requests receive an appropriate answer in a reasonable amount of
   time.

 * Maintain quality in the backports pocket, where the definition of
   quality is driven by the team, but defined by consensus within the
   wider Ubuntu developer community.

 * Handle your own process reform and membership management, but making
   sure that any responsibility can be carried by any contributor who
   demonstrates the required capacity and competence. Specifically,
   since the DMB has never managed membership of ~ubuntu-backporters,
   there is no requirement for the DMB to be involved. Unless you want
   to delegate that, in which case that's a conversation to have with
   the DMB.

How does this sound? Feedback appreciated.

Robie


[1] To be clear, I believe that the current process requires
sponsorship/upload of a suitable backport, and the backporters team only
reviews once an upload has taken place. I am not suggesting that we
require the backporters team to do any more than that - for example
responding to a backport request with no upload with "please find a
sponsor[2] to upload an appropriate backported package and then we'll
review it" would be fine. But the process must avoid the current
situation where only privileged people can get their uploads reviewed,
and everyone else is blocked.

[2] Availability of sponsors is a separate issue. I'd like to address
that too, but I don't think it's appropriate to pull that into the scope
of backports reform.


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Gunnar Hjalmarsson]

On 2021-07-20 13:58, Dan Streetman wrote:

Yes, objection here. The backports pocket is still in use.

If I understand correctly, as discussed in much greater length in
other posts in this thread, the sole problem with the backports
process is lack of time for the Ubuntu Backports Team to actually
review uploads to the -backports pocket.

If that's the case, then the Canonical Sustaining Engineering Group
is happy to take that over (since 'sustaining' the stable releases
is...our job), please feel free to ping me about ACLs and process
tooling for approving -backports uploads and we'll start reviewing
the queues.


That sounds promising, Dan.

As regards uploads in the queues, I had a quick look yesterday. I found 
one item in bionic and four ones in focal. But only one (1) item had a 
reference to a bug report with the expected justification, test results etc.


But then we have all the backport requests which are not yet uploaded:

https://bugs.launchpad.net/bionic-backports

https://bugs.launchpad.net/focal-backports

 gives the impression that the 
uploads should be carried out by an ~ubuntu-backporters member in 
connection with the review.


So if the Canonical Sustaining Engineering Group steps up — which is 
excellent, of course — there still seems to be room for clarification of 
the process.


* Who can/should upload?

* Should sponsorship be sought for uploads to the -backports queues?

--
Cheers,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

--
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Dan Streetman]

On Mon, Jul 19, 2021 at 8:06 AM Robie Basak  wrote:
>
> Dear Ubuntu Developers,
>
> As far as I am aware, the Ubuntu Backports Team has been inactive for
> years now, and backports requests and uploads just languish in
> Launchpad. Thomas Ward last proposed an effort to revitalise it over two
> years ago, but with no response. I believe he's no longer available to
> contribute now.
>
> My concern is that the backports documentation and process still exist,
> so users and contributors are being misled into thinking that something
> will happen, when it won't.
>
> I would be very happy for the backports process to continue, but I think
> it's time to accept that it isn't happening, call a spade a spade, and
> shut the process down and document this properly to stop misleading
> users about it.
>
> For example, I just handled LP: #1902198 having received an out-of-band
> ping, and looking at https://bugs.launchpad.net/focal-backports there
> are multiple recent requests that we know are not going to be answered
> from a backports pocket perspective.
>
> Any objections? If you do object, please provide an alternative proposal
> that will mean that users stop getting misled.

Yes, objection here. The backports pocket is still in use.

If I understand correctly, as discussed in much greater length in
other posts in this thread, the sole problem with the backports
process is lack of time for the Ubuntu Backports Team to actually
review uploads to the -backports pocket.

If that's the case, then the Canonical Sustaining Engineering Group is
happy to take that over (since 'sustaining' the stable releases
is...our job), please feel free to ping me about ACLs and process
tooling for approving -backports uploads and we'll start reviewing the
queues.

>
> Robie
> --
> ubuntu-devel mailing list
> ubuntu-de...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Mattia Rizzolo]

On Mon, Jul 19, 2021 at 10:18:08PM +, Seth Arnold wrote:
> On Mon, Jul 19, 2021 at 02:24:30PM +0200, Mattia Rizzolo wrote:
> > I'd love to see it working the same way it works in Debian.  With
> > random developers uploading (AND TAKING ON THEM THE RESPONSABILITY TO
> > KEEP IT WORKING AND POSSIBLY UPDATED EVER AFTER), whilst a "team" is
> > only tasked with basically verifying that the version string is sane and
> > won't break update.
> 
> 'Put the responsibility on the uploader' sounds like PPAs.

With one crucial difference: -backports are distributed through
archive.ubuntu.com.
You should not downplay the importance of a name.  Saying that it's the
"official ubuntu backports" kind of gives it some extra assurances of
quality.

> I think part of why -backports hasn't worked for Ubuntu in the time that
> I've been paying attention is that PPAs do a decent job of replacing it.
> Anyone who would be interested in using -backports can instead upload
> to their own PPA and get immediate sucess.
[…]
> ps I was curious to see how many packages are in -backports:

You can see how trusty is full, and then it starts to be smaller and
smaller.  So you can easily see when the process finally "broke".
Of course people use PPA, but I always have a hard time trusting PPAs
from random people in certain settings, so way too often I end up
needing to do my own builds of things.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Seth Arnold]

On Mon, Jul 19, 2021 at 02:24:30PM +0200, Mattia Rizzolo wrote:
> I'd love to see it working the same way it works in Debian.  With
> random developers uploading (AND TAKING ON THEM THE RESPONSABILITY TO
> KEEP IT WORKING AND POSSIBLY UPDATED EVER AFTER), whilst a "team" is
> only tasked with basically verifying that the version string is sane and
> won't break update.

'Put the responsibility on the uploader' sounds like PPAs.

Ondřej Surý's PPA is a good example of a backports-like experience
where the developer has indicated how to report bugs in his package,
takes care to mark the packages with a visible version string to help
everyone properly triage issues, etc: https://deb.sury.org/

I think part of why -backports hasn't worked for Ubuntu in the time that
I've been paying attention is that PPAs do a decent job of replacing it.
Anyone who would be interested in using -backports can instead upload
to their own PPA and get immediate sucess.

I think it's time we remove -backports and all the documentation around
it. (Of course, actually removing packages from the -backports package
wouldn't be kind to the few using it, so we might not really be able to
clean up after it for a few years, but we can at least start the process.)

Yes even this requires doing work (and asking other people to do work).
But I can easily volunteer to clean up a few wiki pages, far easier than
I can volunteer to tend to the -backports pocket itself.

Thanks



ps I was curious to see how many packages are in -backports:

sarnold@wopr:/srv/mirror/ubuntu/dists $ for d in focal-backports 
bionic-backports xenial-backports trusty-backports; do echo === $d === ; pushd 
$d > /dev/null ; zcat */binary-amd64/Packages.gz | awk -F/ '/^Filename/ {print 
$4;}' | sort -u ; popd > /dev/null ; done
=== focal-backports ===
cockpit
ibus-typing-booster
lvm2
sanlock
=== bionic-backports ===
bird2
cockpit
debhelper
dh-autoreconf
elixir-lang
erlang
hvac
ibus-avro
ibus-typing-booster
init-system-helpers
iproute2
rabbitmq-server
smartmontools
vaultlocker
=== xenial-backports ===
ansible
appstream
autopkgtest
cockpit
debhelper
dh-autoreconf
distro-info
gir-to-d
golang-1.10
golang-1.10-race-detector-runtime
golang-1.9
golang-1.9-race-detector-runtime
ibus-avro
ibus-typing-booster
ldc
libarchive
lmdb
lxc
lxcfs
lxc-templates
lxd
meson
mustache-d
ninja-build
python3-lxc
=== trusty-backports ===
0ad
0ad-data
acsccid
ansible
apache2
asic0x
astyle
autopkgtest
boinc
cgmanager
cgroup-lite
chemps2
clamtk
clinfo
cppcheck
cppreference-doc
ddrescueview
dianara
drmips
duck
fio
flex
fonts-noto
gcalcli
gf-complete
git-dpm
gitolite3
golang
gramps
haproxy
hedgewars
icinga
identity4c
iperf3
iucode-tool
jerasure
jq
kdeconnect
keepalived
libcloud
liberasurecode
libndp
libnss-cache
libnss-securepass
libpam-ufpidentity
libqmi
libradsec
libseccomp
lmdb
lxc
lxcfs
lxd
makedumpfile
milou
minidlna
modem-manager-gui
moonshot-gss-eap
moonshot-ui
nagios-plugins-contrib
nautilus-admin
nautilus-hide
nvidia-modprobe
nvidia-settings
osm-gps-map
p4vasp
parsedatetime
pdns
php-apcu
povray
prodigal
prosody
pumpa
pyclamd
py-lmdb
pypolicyd-spf
pysimplesoap
pyspf
python-debianbts
python-geoip
python-ldap3
python-pkginfo
python-pyeclib
python-releases
python-socketio-client
qbittorrent
reportbug
screen
shellcheck
shibboleth-resolver
sosreport
spyder
squid-deb-proxy
stress-ng
svtplay-dl
swig
sysdig
tinyxml2
torsocks
transdecoder
twine
ubumirror
unity-tweak-tool
wesnoth-1.12
xfce4-whiskermenu-plugin
xml2rfc
yaggo
yelp-tools
yelp-xsl
zsh



signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Bryce Harrington]

On Mon, Jul 19, 2021 at 11:25:48AM -0700, Erich Eickmeyer wrote:
> So, yes, I will block a so-called "improvement" when it comes down to 
> quitting 
> vs exhausting all other options, because, in my opinion, quitting is not an 
> option.

Totally get what you're saying Erich, and exactly right that users need
avenues for getting formally backported software on Ubuntu.  This is a
situation I've found myself in on both sides: as an upstream maintainer
wanting to get new releases out to LTS users, and as a distro developer
handling ubuntu-backports requests.  You're right that the bottleneck in
the process is a huge hinderance.  There are other fundamental
challenges to it, such as backporting applications that need updated
dependencies too (which is not at all uncommon).

And I get what you're saying about throwing babies out with bathwater
and the desire to "never give up".

But I'd point out the Big-Picture Goal here is getting properly vetted
software backports out to users.  For that, there are *many* options
(snaps, PPAs, SRU process refinements, docker, et al) that have come
about since the initial introduction of -backports.  There are pros/cons
to these, of course, but at a system level I'd argue that these other
options may be why demand for (and interest in maintaining)
ubuntu-backports dried up.  The other options solve problems -backports
can't, or are more convenient or more flexible.

So, I would suggest viewing this not as "quitting" but rather a
recognization that ubuntu-backports hasn't worked as a process, and that
letting it go will open space for other ideas to thrive.  We may be
better off to invest our limited time and attention by contributing to
the backporting processes that are already attracting volunteer
attention.

Bryce

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Robie Basak]

[Dropping random extra Ccs; let's not just spam all the lists, please.
If you want people on other MLs to be aware of this thread, I think it's
sufficient to just send one email to point to it]

On Mon, Jul 19, 2021 at 11:25:48AM -0700, Erich Eickmeyer wrote:
> When was the last time this was brought up? I don't remember seeing anything 
> on any public mailing lists, discourse, the fridge, Planet Ubuntu, or even 
> Ubuntu Weekly News about this. This tells me that it was never brought-up 
> publicly, aka no call for volunteers. If that's the case, then that's the 
> failure, not people like me saying it's a bad idea.

https://lists.ubuntu.com/archives/ubuntu-devel/2019-January/040575.html

> What I'm saying is that you might be posting to these mailing lists, but 
> that's not *public enough* to get the attention this needs to drum-up 
> qualified 
> volunteers. Not everybody who is qualified is subscribed to these lists.

I'm surprised to hear that you think that ubuntu-devel@ isn't a wide
enough audience here. Maybe we differ in who we consider qualified? One
key aspect of driving a process change like this in Ubuntu is to have a
good working knowledge of how Ubuntu development process in this area
works already. I'd therefore only consider an existing and experienced
Ubuntu developer to be qualified.

A successful process reform might mean that other people become
qualified to drive backports in the future - and in fact I think we're
all agreed that this would be the point of any reform itself. But that's
distinct from the set of people qualified to drive the process change
itself.

If you want to disseminate this discussion more widely in places that
you think are relevant, here's your opportunity to do so.

> So, yes, I will block a so-called "improvement" when it comes down to 
> quitting 
> vs exhausting all other options, because, in my opinion, quitting is not an 
> option.

We'll have to disagree here then. I call again for volunteers to drive
reform, but in the absence of anyone qualified actually stepping up, I
stand by my position that blocking my proposal is equivalent to
demanding that the current damaging status quo remains.

Robie


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Erich Eickmeyer]

Hi Robie,

On Monday, July 19, 2021 10:56:39 AM PDT Robie Basak wrote:
> Hi Erich,
> 
> On Mon, Jul 19, 2021 at 10:18:36AM -0700, Erich Eickmeyer wrote:
> > TL;DR: Don't sunset the backports, but reform the process.
> 
> Ubuntu is a meritocracy. We invite anybody, from any company, to
> participate in any aspect of the project.
> 
> I would be happy to see the backports process stay, with reform that
> actually works. Like you, I would prefer that, so in that sense, I
> completely agree with you.
> 
> However, somebody needs to drive that reform. Nobody has. The last time
> the topic of reform came up, nobody apart from me bothered to respond to
> the thread.
> 
> There are many people making many suggestions in this thread now, but
> still so far, nobody has volunteered. I don't think that anybody has
> disagreed that the current situation is actively damaging to our
> community.
> 
> *Given that* nobody is stepping up to reform the process, I think that
> sunsetting the process is the least worst option. It might be a
> difficult, unwelcome decision, but it is one that needs to be made.
> 
> I appreciate the points you're making. However, unless you (or somebody
> else qualified) are actively volunteering to step in and drive the
> reform, I cannot give your position much weight. Because how can I,
> knowing that nobody volunteering means that the current harmful
> situation will continue? To me, when you say you want reform, I hear
> that the status quo will continue because nobody will step up to drive
> that reform, and for me that is unacceptable.
> 
> Please don't block an improvement by requesting work that nobody is
> volunteering to do.

When was the last time this was brought up? I don't remember seeing anything 
on any public mailing lists, discourse, the fridge, Planet Ubuntu, or even 
Ubuntu Weekly News about this. This tells me that it was never brought-up 
publicly, aka no call for volunteers. If that's the case, then that's the 
failure, not people like me saying it's a bad idea.

I would 100% volunteer if it aligned with my day job, which it might, but I 
cannot make any promises at this time. It also aligns with my position as a 
flavor lead since Ubuntu Studio currently maintains its own backports 
repository via a PPA, which is not an ideal situation, but it kindof works and 
it beats jumping through hoops to get anything into the official backports repo.

What I'm saying is that you might be posting to these mailing lists, but 
that's not *public enough* to get the attention this needs to drum-up qualified 
volunteers. Not everybody who is qualified is subscribed to these lists.

So, yes, I will block a so-called "improvement" when it comes down to quitting 
vs exhausting all other options, because, in my opinion, quitting is not an 
option.
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

signature.asc
Description: This is a digitally signed message part.
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Robie Basak]

Hi Erich,

On Mon, Jul 19, 2021 at 10:18:36AM -0700, Erich Eickmeyer wrote:
> TL;DR: Don't sunset the backports, but reform the process.

Ubuntu is a meritocracy. We invite anybody, from any company, to
participate in any aspect of the project.

I would be happy to see the backports process stay, with reform that
actually works. Like you, I would prefer that, so in that sense, I
completely agree with you.

However, somebody needs to drive that reform. Nobody has. The last time
the topic of reform came up, nobody apart from me bothered to respond to
the thread.

There are many people making many suggestions in this thread now, but
still so far, nobody has volunteered. I don't think that anybody has
disagreed that the current situation is actively damaging to our
community.

*Given that* nobody is stepping up to reform the process, I think that
sunsetting the process is the least worst option. It might be a
difficult, unwelcome decision, but it is one that needs to be made.

I appreciate the points you're making. However, unless you (or somebody
else qualified) are actively volunteering to step in and drive the
reform, I cannot give your position much weight. Because how can I,
knowing that nobody volunteering means that the current harmful
situation will continue? To me, when you say you want reform, I hear
that the status quo will continue because nobody will step up to drive
that reform, and for me that is unacceptable.

Please don't block an improvement by requesting work that nobody is
volunteering to do.


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Erich Eickmeyer]

Hi Robie,

On Monday, July 19, 2021 5:05:49 AM PDT Robie Basak wrote:
> Dear Ubuntu Developers,
> 
> As far as I am aware, the Ubuntu Backports Team has been inactive for
> years now, and backports requests and uploads just languish in
> Launchpad. Thomas Ward last proposed an effort to revitalise it over two
> years ago, but with no response. I believe he's no longer available to
> contribute now.
> 
> My concern is that the backports documentation and process still exist,
> so users and contributors are being misled into thinking that something
> will happen, when it won't.
> 
> I would be very happy for the backports process to continue, but I think
> it's time to accept that it isn't happening, call a spade a spade, and
> shut the process down and document this properly to stop misleading
> users about it.
> 
> For example, I just handled LP: #1902198 having received an out-of-band
> ping, and looking at https://bugs.launchpad.net/focal-backports there
> are multiple recent requests that we know are not going to be answered
> from a backports pocket perspective.
> 
> Any objections? If you do object, please provide an alternative proposal
> that will mean that users stop getting misled.
> 
> Robie

I'm throwing my Flavor Lead hat on for this one.

I hate this idea.

The Backports have historically been a very difficult process, so difficult 
that 
at least two flavors (Ubuntu Studio and Kubuntu) have created their own 
backport process and a PPA for those who wish to opt-in. In my opinion, this 
should never have been necessary and those flavors should have had a better way 
to backport. These things don't happen because people are unable to follow the 
process, but because the process is a bottleneck.

Bottlenecks and restrictions are great way to make ideas die because those 
that would use it get fed-up with the extremely high bar that must be met in 
order to do anything. 

Additionally, sunsetting things like this are sure ways to permanently kill 
them. I look at Edubuntu as a prime example: it was sunset, and those that 
have wished to revive it have been denied that simply because "it died before, 
what's to prevent that from happening again?". Somebody made an "Ubuntu 
Education Remix" because they felt they could never revive Edubuntu because 
they'd be denied that ability.

With that, I'd rather see the Backports reformed, not sunset. As with any 
process, if it's not working then perhaps the problem is in the process not 
the idea. Throwing away a good idea because it's not working now is just 
giving up, aka quitting. I was raised never to give up. I didn't give up on 
Ubuntu Studio, and now it's thriving. I believe giving up on Backports would 
be a mistake.

Now, with my OEM (Kubuntu Focus, aka my day job) hat on:

I still hate this idea.

At Kubuntu Focus, we rely on the LTS because those in the scientific and 
artificial intelligence communities rely on packages in external repositories 
that are only made for the LTS. It is astoundingly frustrating when we get 
support tickets asking why XYZ isn't in Ubuntu when a newer version of the 
software that includes a feature they need isn't available to them without 
going to an unsupported repository. That's bad customer service and makes us 
(Kubuntu Focus AND Ubuntu) look bad, because now we're scrambling to provide a 
software solution for a customer rather than just having it for them.

Now, with my Community Council hat on:

How much of the community was aware there even is a backports process? I'd say 
very, very few. To me, that means somebody (I don't know who) dropped the ball 
in the community management aspect of this. As somebody who has a degree in 
this very thing, I find that unacceptable on many levels.

All of that to come to this:

Do not do this. That's basically "thowing the baby out with the bathwater." 
Instead, reform the process. Make the bar a little lower. Instead of 
bottlenecking the process, maybe allow people to actually backport. Not with 
direct repository access, but by lowering the bar in the process. The backport 
process, as it stands, it very, very restrictive. In some ways, it's more 
restrictive than an SRU, which seems backwards to me.


TL;DR: Don't sunset the backports, but reform the process.
-- 
Erich Eickmeyer
Project Leader - Ubuntu Studio
Member - Ubuntu Community Council

signature.asc
Description: This is a digitally signed message part.
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Jeffrey Lane]

Excellent. Thank you for that detailed response Robie!

On Mon, Jul 19, 2021 at 1:00 PM Robie Basak  wrote:
>
> On Mon, Jul 19, 2021 at 10:17:44AM -0400, Jeffrey Lane wrote:
> > Would it be worthwhile, (or possible) to keep it open quietly for
> > special cases?
>
> We can certainly leave ourselves open for the backports process to
> restart if someone steps up and adapts it into something workable.
> Similarly, I'm sure the occasional exception will be fine, with the
> caveat that I don't want publication to the backports pocket to
> effectively only be available to privileged people as I mentioned in
> another subthread.
>
> > Or perhaps amend the SRU process to incorporate bits
> > of Backports?
>
> The key difference between the updates and backports pockets is that
> users have to explicitly opt-in to backports, whereas the updates
> pockets is recommended to all users. Therefore, the general user
> expectation is that the updates pocket will not change behaviour from a
> user's perpsective. There are exceptions, but that's the general rule.
> So I'm not keen on stretching the SRU process to accommodate backports
> in the general case, unless the updates already qualify under the
> existing SRU policy anyway. However, other alternatives to the backports
> pocket already exist.
>
> For apps, we have snaps, which have the advantage of third party
> developers being able to publish directly and safely, without manual
> review being required. The problem we have with manual review shortages
> doesn't exist with snaps.
>
> For everything else, third party PPAs are still possible - they have
> their own problems, but apart from an "official" stamp / trust anchor,
> and therefore requiring a more explicit opt-in on a per-PPA basis, they
> are exactly functionally equivalent to the backports pocket. An official
> stamp for any kind of deb-based publishing necessarily requires manual
> review. "Official" manual review is exactly the problem we're facing,
> and it's the only property we'd lose if a backport went into a PPA
> instead of the backports pocket. So either we figure out how to deal
> with the manual review problem, or we lose nothing in sunsetting
> backports.
>
> Admittedly there's a nuance here which is that putting an official stamp
> on things but with a more relaxed review might also be acceptable,
> because that helps draw attention and fix problems by providing a common
> coordination point. So that's possible too, and I have said I support,
> in principle, keeping the backports pocket open if somebody wants to
> drive such a change. But, to date, we have no volunteers for that, so
> that's why I think it's time to sunset it now, rather than delaying
> further for reform that experience shows us won't come.
>
> > Specifically, I'm thinking of cases like this bug I've been working on:
> >
> > https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1903204
>
> As we discussed privately, I think this bug qualifies for an SRU under
> our "hardware enablement" exception, and I recommend doing that in this
> case.
>
> HTH!
>
> Robie



-- 
Jeff Lane
Engineering Manager
IHV/OEM Alliances and Server Certification

"Entropy isn't what it used to be."

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Robie Basak]

On Mon, Jul 19, 2021 at 10:17:44AM -0400, Jeffrey Lane wrote:
> Would it be worthwhile, (or possible) to keep it open quietly for
> special cases?

We can certainly leave ourselves open for the backports process to
restart if someone steps up and adapts it into something workable.
Similarly, I'm sure the occasional exception will be fine, with the
caveat that I don't want publication to the backports pocket to
effectively only be available to privileged people as I mentioned in
another subthread.

> Or perhaps amend the SRU process to incorporate bits
> of Backports?

The key difference between the updates and backports pockets is that
users have to explicitly opt-in to backports, whereas the updates
pockets is recommended to all users. Therefore, the general user
expectation is that the updates pocket will not change behaviour from a
user's perpsective. There are exceptions, but that's the general rule.
So I'm not keen on stretching the SRU process to accommodate backports
in the general case, unless the updates already qualify under the
existing SRU policy anyway. However, other alternatives to the backports
pocket already exist.

For apps, we have snaps, which have the advantage of third party
developers being able to publish directly and safely, without manual
review being required. The problem we have with manual review shortages
doesn't exist with snaps.

For everything else, third party PPAs are still possible - they have
their own problems, but apart from an "official" stamp / trust anchor,
and therefore requiring a more explicit opt-in on a per-PPA basis, they
are exactly functionally equivalent to the backports pocket. An official
stamp for any kind of deb-based publishing necessarily requires manual
review. "Official" manual review is exactly the problem we're facing,
and it's the only property we'd lose if a backport went into a PPA
instead of the backports pocket. So either we figure out how to deal
with the manual review problem, or we lose nothing in sunsetting
backports.

Admittedly there's a nuance here which is that putting an official stamp
on things but with a more relaxed review might also be acceptable,
because that helps draw attention and fix problems by providing a common
coordination point. So that's possible too, and I have said I support,
in principle, keeping the backports pocket open if somebody wants to
drive such a change. But, to date, we have no volunteers for that, so
that's why I think it's time to sunset it now, rather than delaying
further for reform that experience shows us won't come.

> Specifically, I'm thinking of cases like this bug I've been working on:
> 
> https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1903204

As we discussed privately, I think this bug qualifies for an SRU under
our "hardware enablement" exception, and I recommend doing that in this
case.

HTH!

Robie


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Robie Basak]

On Mon, Jul 19, 2021 at 05:16:30PM +0200, Gunnar Hjalmarsson wrote:
> If I have upload rights for a package, I can also upload to the SRU queue.
> When doing so, I'm supposed to take pains that the upload and related bug
> report comply with the SRU policy, to facilitate the review by an SRU team
> member. Same ought to apply IMO when uploading to the backports queue. It's
> not about bypassing the review.

I think we're derailing ourselves on the minutae of the process here.
What matters is who is involved in getting packages all the way to being
released into the backports pockets. Right now, my understanding is that
the Ubuntu Backporters Team are the sole team ultimately responsible for
approving that, regardless of ACLs, and that's where contributors are
getting blocked.


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Gunnar Hjalmarsson]

On 2021-07-19 16:49, Robie Basak wrote:

On the social/governance side, as far as I understand, the Ubuntu
Backporters Team is delegated authority over the backports pocket,
and nobody should be uploading/approving to the backports pocket
without adherence to their process. If I'm wrong, I am happy to be
corrected. If any core dev is _supposed_ to be able to upload
backports, or otherwise bypass review by the Ubuntu Backporters Team,
then that should be documented and we need some process to at least
set some expectations around what qualifies, etc.


Is there any reason to treat backports different from SRUs in this respect?

If I have upload rights for a package, I can also upload to the SRU 
queue. When doing so, I'm supposed to take pains that the upload and 
related bug report comply with the SRU policy, to facilitate the review 
by an SRU team member. Same ought to apply IMO when uploading to the 
backports queue. It's not about bypassing the review.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

--
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Iain Lane]

On Mon, Jul 19, 2021 at 10:42:06AM -0400, Thomas Ward wrote:
> 
> On 7/19/21 9:48 AM, Robie Basak wrote:
> > 
> > Separately, I'm unhappy about continuing any process which gives some
> > set of privileged people access to upload to backports but is
> > effectively closed to everyone else. This isn't very Ubuntu. Either the
> > privileged people need to sort out an effective review process, or the
> > pocket should generally be closed to new uploads regardless of your
> > status.
> 
> 
> Have we actually confirmed this though, Robie?� If I remember right, I was
> able to push something to -backports with my coredev once, and it didn't
> complain on the upload permissions side of things.� Unless I am forgetting
> something, it LOOKS like upload rights from Core Dev still give backports
> access...

I believe the ACL to upload to the queue is ~motu. Backporters 
(~ubuntu-backporters) membership is required to approve from there.  
Every upload gets held, just like an SRU really. I think any sustainable 
policy would need to relax that requirement somewhat, which would imply 
a measure of engineering work either in Launchpad or in tooling to 
interact with the queue.

(Or something more creative, like giving everyone who can upload 
UNAPPROVED queue access, and creating an expectation of peer review. But 
we're close to starting to design a process here ;-) ...)

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Robie Basak]

On Mon, Jul 19, 2021 at 10:42:06AM -0400, Thomas Ward wrote:
> Have we actually confirmed this though, Robie?  If I remember right, I was
> able to push something to -backports with my coredev once, and it didn't
> complain on the upload permissions side of things.  Unless I am forgetting
> something, it LOOKS like upload rights from Core Dev still give backports
> access...

There's the ACL, and then there's the social/governance side.

On the ACL side I don't care much, because I trust that core devs and
others with similar ACL privilege will follow the policies and processes
set by our project.

On the social/governance side, as far as I understand, the Ubuntu
Backporters Team is delegated authority over the backports pocket, and
nobody should be uploading/approving to the backports pocket without
adherence to their process. If I'm wrong, I am happy to be corrected. If
any core dev is _supposed_ to be able to upload backports, or otherwise
bypass review by the Ubuntu Backporters Team, then that should be
documented and we need some process to at least set some expectations
around what qualifies, etc.


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Thomas Ward]

On 7/19/21 9:48 AM, Robie Basak wrote:


Separately, I'm unhappy about continuing any process which gives some
set of privileged people access to upload to backports but is
effectively closed to everyone else. This isn't very Ubuntu. Either the
privileged people need to sort out an effective review process, or the
pocket should generally be closed to new uploads regardless of your
status.



Have we actually confirmed this though, Robie?  If I remember right, I 
was able to push something to -backports with my coredev once, and it 
didn't complain on the upload permissions side of things.  Unless I am 
forgetting something, it LOOKS like upload rights from Core Dev still 
give backports access...


-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Thomas Ward]

On 7/19/21 8:05 AM, Robie Basak wrote:

Thomas Ward last proposed an effort to revitalise it over two
years ago, but with no response. I believe he's no longer available to
contribute now.


Mostly only because I now sit on the Community Council, and there's been 
pushback from certain community members (who will go unnamed) for me to 
continue pushing hard on certain fronts (technical or otherwise) as it's 
seen that the "Community Council is taking over".


I don't have the cycles to revamp Backports either right now, Community 
Council aside - FT job is in the middle of mass migrations and revamping 
of technical things that will otherwise take most of my during-the-week 
energy and time.



Thomas

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Jeffrey Lane]

Would it be worthwhile, (or possible) to keep it open quietly for
special cases?  Or perhaps amend the SRU process to incorporate bits
of Backports?

Specifically, I'm thinking of cases like this bug I've been working on:

https://bugs.launchpad.net/ubuntu/+source/ipmctl/+bug/1903204

Where I'm working on trying to get a package updated wholesale in
Focal.  SRU feels like the wrong approach here, but at the time I
didn't realise there may have been other avenues to pursue.  Backports
feels like cases like this one would be much easier and cleaner
resolve as it provides a means for a much larger update to a package.
Of course, I'm also viewing that as only for cases like this where
there's a package that needs to be updated, but is not a core piece
(mdadm, for example, is generic enough that changes there need to be
SRUs instead) and builds cleanly on the older toolchains.

That's just my 2 cents worth of opinion. I will work through whatever
processes I need to, but this seems like it could still be quite
useful, I just need to know who to bug to get a package uploaded (if
you choose to keep it available in some form).

Note, this is not a common thing for me, most of my work is in patch
pulls for kernel SRUs, I hardly ever touch user space, but there are
cases like ipmctl and ledmon that need updating and could benefit from
an easier process.

On Mon, Jul 19, 2021 at 9:49 AM Robie Basak  wrote:
>
> On Mon, Jul 19, 2021 at 02:33:58PM +0100, Iain Lane wrote:
> > The best way forward would be if someone had the spoons for that.
> > happy to help review, but I'm not likely to drive it, sorry. In the
> > absence of any of this happening, I would support notifying folks that
> > the current process is deprecated.
>
> Right - this is the problem. We all have ideas about how to improve
> things. But until/unless someone steps up and drives, I think we're
> actively harming our community by the broken process still existing.
> Given that nobody has managed reform in years, I think it's time we gave
> it up.
>
> Separately, I'm unhappy about continuing any process which gives some
> set of privileged people access to upload to backports but is
> effectively closed to everyone else. This isn't very Ubuntu. Either the
> privileged people need to sort out an effective review process, or the
> pocket should generally be closed to new uploads regardless of your
> status.
> --
> ubuntu-devel mailing list
> ubuntu-de...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



-- 
Jeff Lane
Engineering Manager
IHV/OEM Alliances and Server Certification

"Entropy isn't what it used to be."

-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Robie Basak]

On Mon, Jul 19, 2021 at 02:33:58PM +0100, Iain Lane wrote:
> The best way forward would be if someone had the spoons for that.
> happy to help review, but I'm not likely to drive it, sorry. In the 
> absence of any of this happening, I would support notifying folks that 
> the current process is deprecated.

Right - this is the problem. We all have ideas about how to improve
things. But until/unless someone steps up and drives, I think we're
actively harming our community by the broken process still existing.
Given that nobody has managed reform in years, I think it's time we gave
it up.

Separately, I'm unhappy about continuing any process which gives some
set of privileged people access to upload to backports but is
effectively closed to everyone else. This isn't very Ubuntu. Either the
privileged people need to sort out an effective review process, or the
pocket should generally be closed to new uploads regardless of your
status.


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Robie Basak]

On Mon, Jul 19, 2021 at 02:24:30PM +0200, Mattia Rizzolo wrote:
> I don't remember teward's proposals from 2 years ago...

For reference, here's that thread:

https://lists.ubuntu.com/archives/ubuntu-devel/2019-January/040575.html

and, from the following month:

https://lists.ubuntu.com/archives/ubuntu-devel/2019-February/040587.html


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Iain Lane]

On Mon, Jul 19, 2021 at 02:24:30PM +0200, Mattia Rizzolo wrote:
> On Mon, Jul 19, 2021 at 01:05:49PM +0100, Robie Basak wrote:
> > Any objections? If you do object, please provide an alternative proposal
> > that will mean that users stop getting misled.
> 
> I'd love to see it working the same way it works in Debian.  With
> random developers uploading (AND TAKING ON THEM THE RESPONSABILITY TO
> KEEP IT WORKING AND POSSIBLY UPDATED EVER AFTER), whilst a "team" is
> only tasked with basically verifying that the version string is sane and
> won't break update.
> 
> 
> I don't remember teward's proposals from 2 years ago, but I do realize
> the current way the backports pockets are handled just makes it not
> sustainable.

Yeah, this. Actually Thomas and I talked. I guess it was two years ago.  
I was probably responsible for discouraging any further people getting 
involved in the backports process as it is currently operating, because 
it's not sustainable for the people involved. When we talked we 
discussed reformulating it along the lines of Debian backports, but in 
the end neither of us stepped up to write the new policies and get them 
approved.

The best way forward would be if someone had the spoons for that. I'd be 
happy to help review, but I'm not likely to drive it, sorry. In the 
absence of any of this happening, I would support notifying folks that 
the current process is deprecated.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Gunnar Hjalmarsson]

Hi Robie!

Sadly I agree on your problem description.

On 2021-07-19 14:05, Robie Basak wrote:

I think it's time to ... shut the process down and document this
properly to stop misleading users about it.


As regards the documentation, yes, it should be dropped (or at least 
hidden for now) so users are not mislead to waste time with backports 
proposals and then are just met with silence.


But personally I would prefer that the backports pocket is still kept. I 
have found the feature to be very useful for certain new packages. It 
lets you make a new package instantly available in all the supported 
releases. These are two examples of what I'm talking about:


https://launchpad.net/ubuntu/+source/ibus-avro

https://launchpad.net/ubuntu/+source/ibus-typing-booster

New packages without reverse dependencies may be easily backported and 
are easy to review, and there is at least one member of the backports 
team around who may be willing to approve well prepared proposals.


--
Cheers,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

--
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Re: Proposal: sunset the backports pockets

[Mattia Rizzolo]

On Mon, Jul 19, 2021 at 01:05:49PM +0100, Robie Basak wrote:
> Any objections? If you do object, please provide an alternative proposal
> that will mean that users stop getting misled.

I'd love to see it working the same way it works in Debian.  With
random developers uploading (AND TAKING ON THEM THE RESPONSABILITY TO
KEEP IT WORKING AND POSSIBLY UPDATED EVER AFTER), whilst a "team" is
only tasked with basically verifying that the version string is sane and
won't break update.


I don't remember teward's proposals from 2 years ago, but I do realize
the current way the backports pockets are handled just makes it not
sustainable.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports

Proposal: sunset the backports pockets

[Robie Basak]

Dear Ubuntu Developers,

As far as I am aware, the Ubuntu Backports Team has been inactive for
years now, and backports requests and uploads just languish in
Launchpad. Thomas Ward last proposed an effort to revitalise it over two
years ago, but with no response. I believe he's no longer available to
contribute now.

My concern is that the backports documentation and process still exist,
so users and contributors are being misled into thinking that something
will happen, when it won't.

I would be very happy for the backports process to continue, but I think
it's time to accept that it isn't happening, call a spade a spade, and
shut the process down and document this properly to stop misleading
users about it.

For example, I just handled LP: #1902198 having received an out-of-band
ping, and looking at https://bugs.launchpad.net/focal-backports there
are multiple recent requests that we know are not going to be answered
from a backports pocket perspective.

Any objections? If you do object, please provide an alternative proposal
that will mean that users stop getting misled.

Robie


signature.asc
Description: PGP signature
-- 
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports