[Bug 1962614] Re: [BPO] memtest86+/5.31b+dfsg-4 from Jammy to Focal
thanks for replies, unfortunately there are many patches that fix freezes, crashes, other major bugs and recent hardware support. also upstream at the moment does not have git (it will only have it from the next version barring unforeseen events) and this makes it even more complicated and time-consuming to extract parts from the changes between 5.01 and 5.31b. Not to mention the time to document everything, test etc... I don't have much time and I'm already too stressed at work. unfortunately I don't want to risk anything worse than what I had done with SRU of a few small nemo fixes that I had already tested and used for a long time in production and I wanted to do an official build but this took a long time to reach :( sorry for my bad english -- 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/1962614 Title: [BPO] memtest86+/5.31b+dfsg-4 from Jammy to Focal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/1962614/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
next team mtg
Pursuant to our mtg interval discussion, I scheduled our next meeting in 1 month, instead of in 2 weeks :) Let me know if you think we need an earlier mtg. Thanks! -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1962614] Re: [BPO] memtest86+/5.31b+dfsg-4 from Jammy to Focal
I agree with mapreri. Backports is not how to get bug fixes for crashes and such into older releases. Please follow the procedure for SRU, not Backports. -- 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/1962614 Title: [BPO] memtest86+/5.31b+dfsg-4 from Jammy to Focal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/memtest86+/+bug/1962614/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1951601] Re: [BPO] simplestreams/0.1.0-48-gb936edd4-0ubuntu1 from Jammy to bionic, focal
** Summary changed: - [BPO] backport 0.1.0-48-gb936edd4-0ubuntu1 to bionic, focal + [BPO] simplestreams/0.1.0-48-gb936edd4-0ubuntu1 from Jammy to bionic, focal -- 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/1951601 Title: [BPO] simplestreams/0.1.0-48-gb936edd4-0ubuntu1 from Jammy to bionic, focal To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/simplestreams/+bug/1951601/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: Team charter
On Wed, Mar 9, 2022 at 11:00 AM Mattia Rizzolo wrote: > > On Tue, Mar 08, 2022 at 04:53:27PM -0500, Dan Streetman wrote: > > > * you say that the chair can be replaced at any time, but I propose that > > > such change require a supermajority (3/4th of the team) and since the > > > team is owned by the TB, that also needs to be accepted by them > > > > agreed on requiring TB approval - but I'm not sure about requiring a > > supermajority of votes? > > > > I feel like if a majority of team members aren't happy with the chair, > > then the chair probably should be replaced, no? And the TB will have > > final approval to keep or allow replacement of the chair. > > For taking down the current chair, yes simple majority. It just felt > more normal to me that the election of the one would require a stronger > majority than that, but if both of you don't think so, thats fine by me. ah ok, i hadn't been thinking of separating chair removal from approving a new chair. I feel like it should be rather intentional for the team to be 'halted' from doing anything administrative as long as there's no chair (besides approving a new chair), so I was thinking that the removal of an existing chair would be tied to approving a new chair. It sounds like you're ok with leaving it as it is, but if you feel strongly I'm open to persuasion; although I will also add that I suspect if the situation ever arises that a chair would be approved by only a majority but not supermajority, there very likely would be enough animous in the team that some members would probably leave and/or the team would be dysfunctional in some other ways. > > > > * you haven't specified *who* can apply. I recommend to require MOTUs. > > > > i think we should move the specific membership requirements and > > process into simple team policies, don't you? there is the requirement > > in the charter for the team to document membership requirements and > > application process in our public docs. > > Not really, I think the set of membership requirements (at least when it > comes to the really strict requirements such as being an active dev > already) should be in the formal charter. > > Also a formal charter just saying "for more rules look at this > less-serious document" just sounds odd to me. > > If the only requirement we are writing down is 1) already member of a > team; 2) the current bpo team votes; then there is no need for an extra > document at all. Well, I think the reason for separating it from the charter is that specifics like this can change; for example, we may want to expand the team membership requirement, or add other requirements, or require a formal application wiki page, etc. If the specifics are in the charter, then we need to get TB approval for all changes; if it's just team policy changes, we don't need to wait for TB approval. Personally, I think TB approval should be restricted to only the most critical administrative functions of the team; if we need TB approval to change minute details of team administrative policies, I'm not sure what the point of having a charter is at all. In other words - the charter should lay out ONLY what and how the team will operate, in very broad terms. The details of the day-to-day operation of the team administration must be left to the team. To reverse the perspective on this - if the TB doesn't trust our team to decide on the specifics for managing membership, how can they possibly trust us to decide what should be accepted into the backports pocket? > > > re: MOTU, i agree, but also ~sru-developers I suggest? > > I'll admit that I've always found the concept of ~ubuntu-sru-developers > odd, I don't really get what's the point of it myself; I'd think > somebody interested in keeping up the stable releases should also > activily follow the dev releases.. plus the fact that looking at it it > feels (to me) a canonical-forced team just so that their employees can > bypass the sponsorship workflow :\ well, re: feeling ubuntu-sru-developers team is odd, I certainly join you in that boat. The team was created essentially by Robie as documented here: https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039652.html So yes, the team certainly was created in response to coredev applications by people from a specific canonical team (my team, btw). And it certainly is true that the vast majority of uploads from my team are to stable releases, not the development release; the entire point of our team is to 'sustain' ubuntu (hence, 'sustaining engineering team'). That's the primary reason I volunteered for the backports team; its main interest is to people who 'sustain' Ubuntu. Maybe that's the reason the backports team had problems in the past; it was driven by people who were *developing* Ubuntu, not *sustaining* it. Not everyone might realize it, but those are very, very different things. Does that mean the members of this team aren't capable of being coredevs? I'd like to think that's no
Re: Team charter
On Tue, Mar 08, 2022 at 04:53:27PM -0500, Dan Streetman wrote: > > * you say that the chair can be replaced at any time, but I propose that > > such change require a supermajority (3/4th of the team) and since the > > team is owned by the TB, that also needs to be accepted by them > > agreed on requiring TB approval - but I'm not sure about requiring a > supermajority of votes? > > I feel like if a majority of team members aren't happy with the chair, > then the chair probably should be replaced, no? And the TB will have > final approval to keep or allow replacement of the chair. For taking down the current chair, yes simple majority. It just felt more normal to me that the election of the one would require a stronger majority than that, but if both of you don't think so, thats fine by me. > > * you haven't specified *who* can apply. I recommend to require MOTUs. > > i think we should move the specific membership requirements and > process into simple team policies, don't you? there is the requirement > in the charter for the team to document membership requirements and > application process in our public docs. Not really, I think the set of membership requirements (at least when it comes to the really strict requirements such as being an active dev already) should be in the formal charter. Also a formal charter just saying "for more rules look at this less-serious document" just sounds odd to me. If the only requirement we are writing down is 1) already member of a team; 2) the current bpo team votes; then there is no need for an extra document at all. > re: MOTU, i agree, but also ~sru-developers I suggest? I'll admit that I've always found the concept of ~ubuntu-sru-developers odd, I don't really get what's the point of it myself; I'd think somebody interested in keeping up the stable releases should also activily follow the dev releases.. plus the fact that looking at it it feels (to me) a canonical-forced team just so that their employees can bypass the sponsorship workflow :\ Having said all that, I still don't think it makes sense: I could accept having that team be able to upload into the queue (I suspect their uploads currently would just be rejected?), but like (I… think) they can't be part of the ~ubuntu-sru team themeselves so to approve them; that ought to require some kind of higher level in my mind. TBH I already feel odd myself being able to deal with packages in main while being only a MOTU for now > > * what's with the "may 1st" thing about the chair? especially if > > somebody is "promoted" to chair, that would make for an awkward > > situation, so what's the reason behind that? > > * so you think we should vote to extend everybody's membership? That > > sounds like too much work, wouldn't it? also I don't really see a > > need for it. And if you think it'd be useful, then everybody should > > expire the same date so that we can just hold one yearly meeting > > renewing (or not) everybody at once. > > yeah all this isn't needed for our team - i was thinking more of > issues with some other teams. Alright, so… you dropped all changes related to expiry. I think something should stay. Like make the members expire yearly and having them to renew themeselves. FTR, I consider the current "Any team member may call for a public vote to remove any other team member." fine as a way to remove inactive people from the board. We can then police ourseleves whenever we feel like the inactivity of somebody is causing trouble. -- 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: Team charter
On Tue, Mar 8, 2022 at 6:37 PM Thomas Ward wrote: > > Notes in-line below. > > On 3/8/22 16:53, Dan Streetman wrote: > > On Mon, Mar 7, 2022 at 8:20 AM Mattia Rizzolo wrote: > > * you say that the chair can be replaced at any time, but I propose that > such change require a supermajority (3/4th of the team) and since the > team is owned by the TB, that also needs to be accepted by them > > agreed on requiring TB approval - but I'm not sure about requiring a > supermajority of votes? > > I feel like if a majority of team members aren't happy with the chair, > then the chair probably should be replaced, no? And the TB will have > final approval to keep or allow replacement of the chair. > > I don't think we need supermajority for this. TB vote on this just needs a > simple majority at the TB level to be a change. Just to add my clarification opinion on this - I don't think our charter should state anything about how the TB operates to provide approval (or rejection); the TB should decide how they want to do that, and our team should only care about the result. But I do agree that the TB should stick to a simple majority for decisions like this (but since I'm not on the TB or CC, my opinion is not relevant ;-) > > > * require that the team has at least a quarterly meeting (despite > currently being fortnight) > > ack, added. > > * you haven't specified *who* can apply. I recommend to require MOTUs. > > i think we should move the specific membership requirements and > process into simple team policies, don't you? there is the requirement > in the charter for the team to document membership requirements and > application process in our public docs. > > re: MOTU, i agree, but also ~sru-developers I suggest? > > MOTUs, Core Devs, SRU developers, my 2 cents. (This will be the vast > majority of people who will have tech skills to know if they can do the work > backporters needs) I set up a draft membership page: https://wiki.ubuntu.com/UbuntuBackports/Membership to be clear, I think this page is separate from the charter and changes to it may be made in the future without any consultation with the TB. > > > * what's with the "may 1st" thing about the chair? especially if > somebody is "promoted" to chair, that would make for an awkward > situation, so what's the reason behind that? > * so you think we should vote to extend everybody's membership? That > sounds like too much work, wouldn't it? also I don't really see a > need for it. And if you think it'd be useful, then everybody should > expire the same date so that we can just hold one yearly meeting > renewing (or not) everybody at once. > > yeah all this isn't needed for our team - i was thinking more of > issues with some other teams. > > * 7.1.5 "at the chair’s discretion" - here I suppose you are referring > to the meeting chair, not the team chair, right? (which could be > different) > > yep, added the clarification. > > overall if feels more complicated than it needs to be, but effectively > it's what we've been doing, so it should be fine. > > indeed, i agree it's unfortunately far more complicated than i would > like it to be. And yes, I basically just tried to write up in painful > detail what we already do. > > The draft is updated with these changes now, can you take another look? > > > > Thomas -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
