Re: New proposal for Ubuntu Backporters Team Charter
On Wed, Jun 07, 2023 at 05:35:21PM +0200, Mattia Rizzolo wrote: > Today we had a Backporters meeting, and indeed we don't have any > opposition to this latest proposal, thank you for the prods, and I'm > happy that this topic is finally coming to a close! Thanks! > Please do email us a bit more "formally" once it's done, so that we have > a good authoritative reference to link to later on :) Consider this the formal email then please? > I think following this ratification the next question would be: where is > a good place to collect them? Personally I'm going to copy it under > our "wiki space" (and perhaps under launchpad as well? It's short > enough…), but the final goal was for the TB to define a bunch of > these for all the other interesting teams too, so I wonder if you > already have something good in mind? I've documented this at https://wiki.ubuntu.com/TechnicalBoard#Backporters_Team for now. As it grows, it could move to its own page. 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: New proposal for Ubuntu Backporters Team Charter
Hi! Thank you for your time on this. On Wed, Mar 01, 2023 at 04:22:13PM +0100, Mattia Rizzolo wrote: > > > So I think we are starting to get to the crux of the difference in > > > viewpoints from the TB to the backporters team. Due to the past history > > > of some perceived dysfunction within the backporters team, I feel it is > > > important to try and set some more specific expectations for how the > > > newly rebooted team would function - particularly to an outsider wishing > > > to contribute. > > The problem in my opinion is that also your (rbasak's) original proposal > is also "useless" for an aspiring contributor. Also, what's > "contributor" here? Somebody wanting to propose a backport update is > really not served by these documents (either Charter or Policies)... I wonder if it's worth first discussing what the text would actually be used *for*, since your reply suggests to me that we might not have the same view on this here. I see the (my) proposed text as a point of reference between the backporters team and the rest of the project, but generally only for use to guide the backporters team in defining their own policies, procedures and documentation, cases where it was unclear what their responsibilities are, or in case of some kind of unhappiness (eg. we hope it won't happen, but a repeat of the previous team being unable to review submissions at all). What I *don't* expect it to be used for directly is for anything to do with aspiring contributors. I would expect that to be covered by documentation that the backporters team controls and defines as they feel appropriate. Similarly you'd be free to adjust that documentation as the need arises, rather than having a "locked in" document that requires negotiation with a board to have changed. I think aspiring contributors would still benefit from having things clearly defined in this text, because that clarity would then filter down into your own processes, procedures and documentation. But I wouldn't expect them to actually _use_ the formal text directly (unless they were asking for changes in those processes, or wanted to escalate something). 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: Ubuntu Backports charter
On Tue, Mar 22, 2022 at 04:46:45PM -0400, Dan Streetman wrote: > > However the equivalent text you have now only says "The mission of the > > Ubuntu Backporters Team is to maintain the backports pocket of all > > stable Ubuntu releases." with no mention of that. > > > > In fact that's the case for basically everything I proposed previously. > > > > Is this deliberate? Would you consider replacing your "Mission > > Statement" with the text I suggested previously? > > I don't think so, no. > > > And if not, why not? > > Because your statements aren't a mission, they are policy; and your > statements are not objective. For example, "all requests receive an > appropriate answer in a reasonable amount of time" is not at all > objective and so has no actual meaning in a charter. I'm not sure if we're arguing semantics here in terms of what we each mean by "mission", "policy" and "charter". I'd like to avoid that. I am suggesting that we (both the TB and the backporters team) agree to these statements because they would be able to form the documented terms of reference between the rest of Ubuntu and backporters team. They would be the reason for the existence of the backporters team. If a future problem were to arise like the one we had in the past that led to the recent revitalization, then we would be able to use these statements to quickly identify the problem. I agree that "reasonable amount of time" is subjective. However I don't think it's a problem for there to be subjectivity here. Objectively, it was the fact that requests _weren't_ being processed in a reasonable amount of time that was the problem last time. Stating and agreeing to this helps set expectations. Consider what would happen if the backporters team stopped responding to requests, or became unreasonably slow in doing so. That would obviously be a problem - just as it was previously. If it couldn't be resolved directly between everyone involved, somebody might escalate to the TB, and the TB would probably agree that some intervention is required. In other words, it's *already* a hard expectation that "all requests receive an appropriate answer in a reasonable amount of time" whether or not it's written down and directly agreed to. So why don't we agree and write it down to help set everyone's expectation to what the reality is anyway? Isn't that the point of documenting this kind of thing, and exactly the sort of documentation you've said elsewhere you think is lacking? > > > > IMHO it's best if each team - including the backporters team - decides > > > > for themselves how they want to operate, and are free to change things > > > > as and when they want. To that extent, if the backporters team wants > > > > have a detailed document like the one you have written, then that's > > > > absolutely fine. > > > > > > > > But why are you looking for the TB to "ratify" it > > > > > > So that the powers delegated to the team are explicitly stated... > > > > I agree that this part makes sense. > > > > > that the "main" rules are also explicitly stated (with "main" being > > > subjective, and decided by our team). > > > > Why do you want this to be part of the TB's ratification? > > Because it's completely unclear what powers/policies/rules the TB > reserves for itself. Am I right in understanding that your concern is that the TB will later tell you that you aren't allowed to do something that you've written down in your rules already? Would it work for you if the TB were to look at your document and agree just that the set of rules you've written for yourself seem reasonable and are all within the remit of the backporters team to perform, rather than also formally binding anyone to anything? I would still like to talk about having a documented delegation in the form that I proposed, but this suggestion would address my separate concern that you're asking the TB to lock the backporters team down in a way that I don't think is appropriate. > There is no section called "team responsibilities" nor "powers > delegated to the team" so I'm not 100% clear on what you *do* think > the TB needs to ratify, vs. what you *do not* think the TB should be > involved in...can you clarify? "powers delegated to the team" were your words. "team responsibilities" are a heading in my email here: https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041559.html Specifically what I think would be useful for the TB to ratify is what I wrote in my email here: https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022687.html > Any sections that you feel should be removed from the Charter (i.e. > moved into the team official policies document: > https://wiki.ubuntu.com/UbuntuBackports/Policies), please let me know. > Assuming you are speaking for the TB, of course. I think it's premature to "speak for the TB" at this stage. Let's first try and figure out a way forward that everyone agrees upon. If we can achieve that, then "speaking for" any partic
Re: Ubuntu Backports charter
On Tue, Mar 22, 2022 at 04:10:38PM -0400, Dan Streetman wrote:
> The team has had previous discussions around governance, yes, and of
> course those discussions played a part in forming this document. I
> don't really know what exactly you mean by any/all discussions being
> 'incorporated' into the document?
For example, I had suggested the text "Any review process must accept or
reject every backport request on its technical merit, and be neutral to
who is requesting it" with a footnote that explained the rationale as
"the process must avoid the current situation where only privileged
people can get their uploads reviewed, and everyone else is blocked"
("current" there is now, I believe, "past")
However the equivalent text you have now only says "The mission of the
Ubuntu Backporters Team is to maintain the backports pocket of all
stable Ubuntu releases." with no mention of that.
In fact that's the case for basically everything I proposed previously.
Is this deliberate? Would you consider replacing your "Mission
Statement" with the text I suggested previously? And if not, why not?
> > IMHO it's best if each team - including the backporters team - decides
> > for themselves how they want to operate, and are free to change things
> > as and when they want. To that extent, if the backporters team wants
> > have a detailed document like the one you have written, then that's
> > absolutely fine.
> >
> > But why are you looking for the TB to "ratify" it
>
> So that the powers delegated to the team are explicitly stated...
I agree that this part makes sense.
> that the "main" rules are also explicitly stated (with "main" being
> subjective, and decided by our team).
Why do you want this to be part of the TB's ratification?
> > and lock in the
> > requirement that the TB must approve any changes? For example, you've
> > said "This charter, and any changes to it, must be approved by the TB
> > before taking effect" but also you've got minutiae in there such as
> > which IRC channel is used and on what network. Won't causing the TB to
> > "lock this in" be excessively beaurocratic? And what if you need a minor
> > change? Are you expecting to go to the TB every time? Won't that be
> > impractical?
>
> Sorry, these questions seem subjective and rhetorical - I'm not sure
> if you intend for our team to answer them? Do they need to be answered
> for the TB to review and/or ratify this charter?
I don't think the questions are rhetorical. I do think they need
answering because if unanswered then I don't understand why it's within
scope for the TB to consider ratifying these details at all.
Summary:
1) Details of team responsibilities and "powers delegated to the team"
make sense for the TB to ratify.
2) Details of how the team carries out their responsibilities seem like
matters for the team to manage themselves and I currently don't see why
they're any business of the TB unless some kind of conflict or other
problem arises (and I don't know of any). I invite further discussion
and argument to why they should be within the scope of the TB today, but
in the absence of any explanation or argument, I'm inclined to consider
this part out of scope and therefore (wearing my TB hat) decline to get
involved.
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: Ubuntu Backports charter
On Mon, Mar 21, 2022 at 12:44:43PM -0400, Dan Streetman wrote: > I see this charter as the one and only official document (except where > the charter specifically delegates to other document(s)) for guiding > what the team does and how the team does it. It supersedes any > previous discussion. Is that what you are asking? I'm asking to what extent you consider the previous discussion to have been incorporated into your current document, if at all. IMHO it's best if each team - including the backporters team - decides for themselves how they want to operate, and are free to change things as and when they want. To that extent, if the backporters team wants have a detailed document like the one you have written, then that's absolutely fine. But why are you looking for the TB to "ratify" it and lock in the requirement that the TB must approve any changes? For example, you've said "This charter, and any changes to it, must be approved by the TB before taking effect" but also you've got minutiae in there such as which IRC channel is used and on what network. Won't causing the TB to "lock this in" be excessively beaurocratic? And what if you need a minor change? Are you expecting to go to the TB every time? Won't that be impractical? In case it's not clear, I think what you're proposing is rather different from my suggestion. I was focusing on the team responsibilities only - very deliberately leaving *how* the team might choose to fulfil those responsibilities out of it. 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: Ubuntu Backports charter
On Mon, Mar 21, 2022 at 10:21:19AM -0400, Dan Streetman wrote:
> The Ubuntu Backports team has drafted a Charter and we request that
> you review it and, if you approve, please provide your approval
> ("ratification") by email. If you have any concerns or comments,
> please let us know.
Related discussions:
https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041559.html
(under "Team Responsibilities")
https://irclogs.ubuntu.com/2022/02/09/%23ubuntu-meeting.html#t17:56
https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022687.html
https://irclogs.ubuntu.com/2022/02/23/%23ubuntu-meeting.html#t17:39
Dan, how do you see that fitting in here?
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
Ratifying a formal delegation
Dear Backporters Team, Thank you for your work in restoring the team and a functional process, and congratulations on your recent announcement on the reopening of the backports pocket. There is one thing I'd like to wrap up relating to the reboot please. In my email that kicked this off (https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041559.html), I had a section of text under the heading "Team Responsibilities"). Is this text something you would be willing to accept as a formal delegation from the Technical Board? If so, I'd like to next propose to the TB that they ratify it as such. Here's the text again, with one minor edit (s/defined/decided/) for clarity, and I've also removed the last sentence because that's not really an essential part of the description. ---8<--- * 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 decided 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. ---8<--- My motivation for requesting this is that I hope that with a more formal delegation, then should the same situation arise again, it'd be less painful to address that time. Another currently relevant point is that this would make it clear that the team will manage its own membership. We will need to see if the TB concurs. 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]
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]
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]
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]
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]
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
Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]
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
[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
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
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
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
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
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
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
Proposal: sunset the backports pockets
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
[Bug 1422417] Re: ceph radosgw needs mod-proxy-fcgi for apache 2.2
Thanks. Let's close the bug then, so it's clear that nobody is expecting this to ever happen in Trusty. The bug is valid, so rather than Invalid I'll mark it Won't Fix (as we don't intend to fix it). This isn't intended to exclude anyone else doing it. If you want to work on this, please raise it in this bug and we can reopen. -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to Precise Backports. https://bugs.launchpad.net/bugs/1422417 Title: ceph radosgw needs mod-proxy-fcgi for apache 2.2 To manage notifications about this bug go to: https://bugs.launchpad.net/precise-backports/+bug/1422417/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1422417] Re: ceph radosgw needs mod-proxy-fcgi for apache 2.2
(still subject to SRU team approval, etc) ** Changed in: apache2 (Ubuntu Trusty) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to Precise Backports. https://bugs.launchpad.net/bugs/1422417 Title: ceph radosgw needs mod-proxy-fcgi for apache 2.2 To manage notifications about this bug go to: https://bugs.launchpad.net/precise-backports/+bug/1422417/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1604209] Re: apache2 in trusty-backports is vulnerable to CVE-2016-5387
No action for the main apache2 package. This affects the Trusty backports project only. ** Changed in: apache2 (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to trusty-backports. Matching subscriptions: ubuntu-backporters https://bugs.launchpad.net/bugs/1604209 Title: apache2 in trusty-backports is vulnerable to CVE-2016-5387 To manage notifications about this bug go to: https://bugs.launchpad.net/trusty-backports/+bug/1604209/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1512688] Re: service haproxy stop does not work
Thank you for taking the time to report this bug and helping to make Ubuntu better. Does this issue affect the backport only, or does it also affect haproxy on Trusty or the release the backport was from? Since you've reported this as affecting the backport I'll reassign to the backports project, but if it also affects an Ubuntu release without backports then we need a bug task for that and should fix it there too. ** Package changed: haproxy (Ubuntu) => trusty-backports -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to trusty-backports. Matching subscriptions: ubuntu-backporters https://bugs.launchpad.net/bugs/1512688 Title: service haproxy stop does not work To manage notifications about this bug go to: https://bugs.launchpad.net/trusty-backports/+bug/1512688/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1494141] Re: HAProxy 1.5 init script does not terminate processes
Louis, I can't sponsor your debdiff into backports, but be careful of ordering issues in your patch. clean() should be defined before the trap is set, and tmp should be defined before any point that clean() could be called. In general you should quote "$tmp" as well in case it ends up with spaces (eg. if $TMPDIR has a space in it). -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to trusty-backports. Matching subscriptions: ubuntu-backporters https://bugs.launchpad.net/bugs/1494141 Title: HAProxy 1.5 init script does not terminate processes To manage notifications about this bug go to: https://bugs.launchpad.net/trusty-backports/+bug/1494141/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1414482] Re: Backport xtables-addons 2.6-1 to trusty
As discussed, this bug needs a justification against SRU policy to make any progress, so marking this as Incomplete for Trusty. Alternatively (sorry I failed to mention this on IRC) you can seek a backport via the backports pocket so users can opt in to using it. See https://wiki.ubuntu.com/UbuntuBackports for process details. ** Changed in: xtables-addons (Ubuntu Trusty) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1414482 Title: Backport xtables-addons 2.6-1 to trusty To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xtables-addons/+bug/1414482/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1472713] Re: HAProxy 1.5.3 requires security updates
** Package changed: haproxy (Ubuntu) => trusty-backports -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to trusty-backports. Matching subscriptions: ubuntu-backporters https://bugs.launchpad.net/bugs/1472713 Title: HAProxy 1.5.3 requires security updates To manage notifications about this bug go to: https://bugs.launchpad.net/trusty-backports/+bug/1472713/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1451412] Re: Please backport to trusty
Thank you for taking the time to report this bug and helping to make Ubuntu better. In case you are not familiar, https://wiki.ubuntu.com/UbuntuBackports documents the process that needs to be followed for this. Volunteers welcome. ** Package changed: bcache-tools (Ubuntu) => trusty-backports ** Changed in: trusty-backports Status: New => Incomplete ** Summary changed: - Please backport to trusty + Please backport bcache-tools to trusty -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to trusty-backports. Matching subscriptions: ubuntu-backporters https://bugs.launchpad.net/bugs/1451412 Title: Please backport bcache-tools to trusty To manage notifications about this bug go to: https://bugs.launchpad.net/trusty-backports/+bug/1451412/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1175049] Re: Please merge squid3 3.3.3-2 (main) from Debian unstable (main)
** Changed in: squid3 (Ubuntu) Status: New => Triaged ** Changed in: squid3 (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to Precise Backports. https://bugs.launchpad.net/bugs/1175049 Title: Please merge squid3 3.3.3-2 (main) from Debian unstable (main) To manage notifications about this bug go to: https://bugs.launchpad.net/precise-backports/+bug/1175049/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 986649] Re: puppet agent can't obtain catalogs
** Also affects: maverick-backports Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to maverick-backports. https://bugs.launchpad.net/bugs/986649 Title: puppet agent can't obtain catalogs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/986649/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
