Re: [Technical Board] Feedback requested: draft policy on third party software sources included by Ubuntu
On Tue, Aug 27, 2024 at 04:35:45PM +0100, Robie Basak wrote: > Since there's no further feedback, I’ll ask the Technical Board to make > the draft policy above final at their (our) next meeting, which is later > today at 1900 UTC. See the agenda[1] for details (which I’ll update > shortly). FTR, the TB ratified this draft as policy[1]. This is now documented as policy here: https://canonical-ubuntu-governance-docs.readthedocs-hosted.com/en/latest/policy/3rd-party-software-sources/ This is a new Sphinx-based repository for this kind of documentation. There’s only this one document there now, but unless there are better ideas, we now have a place for this kind of thing in the future. Robie [1] https://irclogs.ubuntu.com/2024/08/27/%23ubuntu-meeting.html#t19:09 signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Cancel meeting: 2024-10-22
I suggest cancelling our meeting scheduled on 2024-10-22, since a number of Canonical staff who are TB members will be occupied at an internal event. Or are sufficient TB members not at that event such that it's worth holding a meeting anyway? Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: [Technical Board] Feedback requested: draft policy on third party software sources included by Ubuntu
On Thu, Aug 01, 2024 at 11:06:34AM +0100, Robie Basak wrote: > When this was raised to the Technical Board, we formed a view that we > should have some written policy that defines what users can expect from > snaps that are installed in this way, together with a process for > granting exceptions. Since we are working on this retrospectively, it > will be the case that some existing packaging does not comply with our > principles. In time, for each outlier we intend to figure out if we > should make exceptions, bring those packages into line, or something in > the middle. We are starting by defining where we want to be, then we can > apply that standard to new cases, and then we can work towards. Since there's no further feedback, I’ll ask the Technical Board to make the draft policy above final at their (our) next meeting, which is later today at 1900 UTC. See the agenda[1] for details (which I’ll update shortly). [1]: https://wiki.ubuntu.com/TechnicalBoardAgenda signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Skipping the meeting on May 7?
On Tue, Apr 30, 2024 at 01:28:03PM +0200, Sebastien Bacher wrote: > The next TB meeting should be on May 7 but there is a Canonical event on > that week and I expect most of the TB members are not going to be available. > Should we skip and have the next meeting on May 21? +1 -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Upcoming DMB election planning
Dear Technical Board, The DMB have agreed to my proposal below. Please could you now consider approving it? Thanks, Robie On Mon, Mar 18, 2024 at 08:18:38PM +, Robie Basak wrote: > Hi, > > The terms of three current DMB members will come to an end on > 2024-03-29, and the remaining four on 2024-06-16. > > Further to the DMB's meeting today, I propose the following: > > 1) Nobody else has volunteered so I will run the election (though if > someone else would like to do so instead, volunteers are still > welcome to step forward!). > > 2) I will combine the two elections to avoid having to run two DMB > elections a month apart. > > 3) To make that work, since the results are ranked, the top three ranked > candidates shall take their seats immediately, and the further four > shall take their seats on 2024-06-17. > > 4) We shall re-stagger the terms by giving the top three candidates a > (approximately) two year term, and the further four winning candidates a > one year term. We'll align the expiry dates a year apart by extending > the terms of the first batch as needed, so they'll end up being a little > over two years. (Rationale: better than reducing the terms of the second > batch to less than even a year and it makes sense to give the higher > ranked candidates the longer term). > > 5) We'll extend the terms of the existing DMB members until the election > is complete. If individual members wish to stand down, then we'll have > to run the board with a reduced number of members until the election is > complete. > > 6) If existing DMB members stand for election again (as I hope they > will!), it may happen that some or all of the top three ranked > candidates would end up with two seats at once. To avoid this > contradiction, if this situation does arise then we'll instead extend > the term of any affected expiring seats until 2024-06-17, assuming that > the incumbent agrees to serve on the board until then. If not, then the > elected candidate shall continue with only one seat, with a reduced > number on the DMB, until 2024-06-17. > > 7) Various specifics above are beyond the remit of the DMB to determine > and require TB approval. If the DMB agree to some or all of the above, > I'll then ask the TB on behalf of the DMB to approve. This is the > minimal effort resolution of the various issues that I think will work > fairly for everyone, but if you can think of a better way to do it, or > would prefer to defer some aspects for now, then please do speak up. > > Thanks, > > Robie > -- > technical-board mailing list > technical-board@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/technical-board signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Upcoming DMB election planning
Hi, The terms of three current DMB members will come to an end on 2024-03-29, and the remaining four on 2024-06-16. Further to the DMB's meeting today, I propose the following: 1) Nobody else has volunteered so I will run the election (though if someone else would like to do so instead, volunteers are still welcome to step forward!). 2) I will combine the two elections to avoid having to run two DMB elections a month apart. 3) To make that work, since the results are ranked, the top three ranked candidates shall take their seats immediately, and the further four shall take their seats on 2024-06-17. 4) We shall re-stagger the terms by giving the top three candidates a (approximately) two year term, and the further four winning candidates a one year term. We'll align the expiry dates a year apart by extending the terms of the first batch as needed, so they'll end up being a little over two years. (Rationale: better than reducing the terms of the second batch to less than even a year and it makes sense to give the higher ranked candidates the longer term). 5) We'll extend the terms of the existing DMB members until the election is complete. If individual members wish to stand down, then we'll have to run the board with a reduced number of members until the election is complete. 6) If existing DMB members stand for election again (as I hope they will!), it may happen that some or all of the top three ranked candidates would end up with two seats at once. To avoid this contradiction, if this situation does arise then we'll instead extend the term of any affected expiring seats until 2024-06-17, assuming that the incumbent agrees to serve on the board until then. If not, then the elected candidate shall continue with only one seat, with a reduced number on the DMB, until 2024-06-17. 7) Various specifics above are beyond the remit of the DMB to determine and require TB approval. If the DMB agree to some or all of the above, I'll then ask the TB on behalf of the DMB to approve. This is the minimal effort resolution of the various issues that I think will work fairly for everyone, but if you can think of a better way to do it, or would prefer to defer some aspects for now, then please do speak up. Thanks, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Upload of translation files
Hi, On Mon, Feb 26, 2024 at 08:04:50PM -, Jack wrote: > Dear langpack-team, > > I'm recently working on the Ladin Language Pack and I have some issues > uploading translation files. Sorry I don't know how to help you directly, but you could try the ubuntu-translators list here: https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Noble publication settings change
On Tue, Feb 06, 2024 at 09:56:05AM +, Dimitri John Ledkov wrote: > Can techboard please action the following request for Noble distro series > https://answers.launchpad.net/launchpad/+question/709163 ? > > It is acked by the apt repository format maintainer. That link refers to getting consent from (I think) archive admins? Do we have/need such an ack? Also, do we have someone who can take responsibility for dealing with any fallout, please? signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Delegation of LTS flavour qualification to the release team?
As a member of the Technical Board who is not on the Release Team, it always struck me as odd that the TB is responsible for determining which flavours qualify for the LTS label. Personally, if someone from the release team says it's OK, then I agree. I don't think I have anything to add or change. I don't think I have any expertise or considered opinion to add in this area that I'd routinely want to provide any input that the release team has not already done. Contrast with the new flavour process[1][2] where a requirement is "The flavour’s intention and goals are aligned with the goals of the Ubuntu project"[3] which doesn't seem to me like a release team thing. So in that case I think it makes sense to consult with the TB on just that point, but to leave everything else to the release team. Could the LTS designation decision for flavours be something that we could delegate entirely to the release team for future cycles? Of course technically the TB would retain the right to overrule anything, but that would be exceptional and I don't see any reason for the process to have to involve TB in the routine case. Robie [1] https://wiki.ubuntu.com/RecognizedFlavors/NewFlavorProcess [2] https://wiki.ubuntu.com/RecognizedFlavors [3] IIRC I was the one who suggested this, but my point remains that I think it makes sense for the TB to decide this, but not everything else routine, including the remaining logistics of new flavours and per-LTS-cycle individual flavour LTS qualification signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Call for vote Re: Ubuntu Unity participation in LTS
On Wed, Dec 20, 2023 at 08:24:46AM -0800, Steve Langasek wrote: > Based on the answers from the flavor leads in this thread, I am satisfied > that Ubuntu Unity meets the criteria for an LTS community flavor for 24.04 > and recommend that the Technical Board approve their plan for a 3-year LTS. > I am calling for a vote by email from the TB on this. +1 signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
I will be unable to attend the Technical Board meetings on 21 November and 5 December. The following meeting would be on 19 December, but this coincides with Canonical's end-of-year shutdown so I am unlikely to be available then either and I suspect that this also applies to others. Should we cancel that meeting, and in that case I'll see you all at the meeting on Tuesday 2 January? Robie -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Postpone next meeting?
+1, thanks. (for those not at Canonical, it's a Canonical internal event that follows the Ubuntu Summit in Riga) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: ubuntu-advantage-tools SRU exception policy review
On Fri, Oct 13, 2023 at 03:03:52PM -0300, Renan Rodrigo Barbosa wrote: > Great! Thank you very much Steve. > Now I think we are only missing a sign-off from the Release team, and the > document to be linked in > https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template right? Yes, but I think the release team are a little busy at the moment, so I wasn't going to chase them for a few weeks :-) -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: ubuntu-advantage-tools SRU exception policy review
[adding Technical Board to Cc] On Thu, Sep 14, 2023 at 05:39:50PM +0100, Robie Basak wrote: > This is now ready for feedback and review. We will need sign-offs from > the Pro client developers (the subset of the Server Team that is > maintaining this package) as well as the SRU team, Release Team and > Technical Board. Please see the wiki page for details. There's been no feedback, and I understand the SRU team are generally happy with this. So can we move to sign-offs, please? Release team: please sign off on "Feature freeze in the development release shall not apply". Technical board: please sign off on "Facilities that enable access to Ubuntu Pro may be added to the main Ubuntu archive and installed by default." and "Updates shall be permitted as usual for SRUs and additionally after EoSS." (IOW, that we do SRUs into the main archive after EoSS as an exception here at all). On behalf of the SRU team I can sign off on the SRU team bits. Reference document: https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates Thanks, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
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 -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Key Ubuntu teams should have an open process for new members
On Wed, Jun 14, 2023 at 01:17:01PM -0400, Jeremy Bícha wrote: > On Wed, Jun 14, 2023 at 1:05 PM Robie Basak wrote: > > But in general, I think we're doing OK, if you consider that a > > reasonable rate for SRU team onboarding might be one or two a year. > > The SRU team has only added one new member since the end of 2016 if I > am reading this page correctly: > https://launchpad.net/~ubuntu-sru/+members We started talking about adding new members around this time last year (15 Jul 2022 was the day I created a doc on it). signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Key Ubuntu teams should have an open process for new members
On Tue, Jun 13, 2023 at 09:57:51PM +0200, Sebastien Bacher wrote: > Le 13/06/2023 à 21:46, Robie Basak a écrit : > >IMHO, for the SRU team, it makes sense to actively approach uploaders > >who the existing SRU team considers to meet the criteria, rather than > >have an open application process. > > It does make sense for the team to approach those uploaders indeed. But in > practice do you feel like it is happening? Are the SRU team members managing > to find the time and energy to watch for those people and have the > discussion? Are you confident that they are no contributors that match the > criteria but haven't been noticed? There are a few candidates we decided did not meet the criteria or who are or have become unavailable for various reasons. It would be inappropriate to discuss their specific cases in public, so that makes it difficult for me to give specifics on exactly how well I think we're doing. But in general, I think we're doing OK, if you consider that a reasonable rate for SRU team onboarding might be one or two a year. I think it's also important to consider to what extent the SRU team _needs_ new members. It's easy to presume that we're overloaded and that the solution is to add team members. I think we certainly were overloaded at around the time of Canonical sprints which made many SRU team members unavailable. However, I don't think that's the real cause of the issue. I find that I spend 80% or more of my time on "difficult" cases. Sometimes these are genuinely complicated, but a lot of the time it's because of mismatched expectations. I think adding new members is going to make the problem of mismatched expectations worse, not better. So while we could do with one or two additional SRU team members, I think it would make a much more significant difference to ensure that uploaders are able to more effectively drive their SRUs. This includes being able to explain what the SRU team need to see, anticipating their questions, being able to unblock their own SRUs rather than asking the SRU team for help on process questions, setting the expectation on uploaders that special cases must be properly requested and documented instead of assuming that one SRU team member magically knows what to do because another SRU team member accepted it last time, and so forth. I think we'd free up significant SRU member time, and therefore review delays, if we could improve on these friction points. I'm actively working to improve the state of things on various fronts. Documented criteria for new members is in the works, as seen in the draft earlier in the thread. I am also working on revamping SRU process and policy documentation. For Unapproved queue review, I set up an automated Kanban board which helps reduce duplicate review effort. There are other things I haven't got to yet, too. Anyway, my point is just that while we do need one or two additional members, I really don't think that lack of new membership is the cause of the recent SRU team backlog, and I am working on what I believe are the real causes. This also feeds back to the team membership question: ideally, all regular SRU uploaders should meet our criteria. But right now, many seem to fall well short of that. If we can fix this, then we should automatically have more good candidates. Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Key Ubuntu teams should have an open process for new members
On Tue, Jun 13, 2023 at 07:11:15PM +0200, Sebastien Bacher wrote: > (for context that's an email I sent the techboard before I joined the board, > the discussion picked up recently and TB members agreed that we should have > it on the mailing list) (and this was my reply, with some minor copyediting) IMHO this is an important topic, since the CoC says "We invite anybody, from any company, to participate in any aspect of the project. Our community is open, and any responsibility can be carried by any contributor who demonstrates the required capacity and competence." and I think it would defeat the point of a community project to not have this. However, I think an appropriate method depends on a team-by-team basis, and it would be reasonable for a team to decide that they don't currently need any new members, or that some specific person isn't currently suitably qualified to be on that team. If the team is wrong, then the TB would be the appropriate point to escalate; my point is just that if the team is right then I think that's a perfectly acceptable situation from a governance perspective. Therefore, I think that if there's a problem with a team's position on 1) not delivering appropriately because of a perceived shortage of team members; or 2) choosing new team members in an inappropriate way, then that should normally be raised with the team first and escalated to the TB if required. It would be nice if teams documented their position on team membership (open or closed, how they decide if new members are required, the process for selecting new team members, etc). I'm open to the idea that the TB might require teams to document this; I think that would fit into my general push for documenting specifics of what the TB has delegated to teams. However, I don't think that necessarily means that all teams must have processes for candidates to _apply_ for membership, for the reasons above. It would depend on the team. On the SRU team, I tried to define some objective requirements for prospective new members, and other SRU team members have tweaked it. I hope this goes in the sort of direction you're seeking. I intend to document this publicly, but haven't yet. Here's the current text: Hard requirements * Recent track record of good quality SRUs * Recent uploads (whether sponsored or not) either met our expectations or successfully anticipated concerns that could reasonably have been predicted by existing SRU team members. * Few recent poor quality SRUs (nice to have: none). This includes uploads for issues that are unsuitable for SRU, as well as missing SRU information, missing bug references, poorly completed SRU information, etc. Exception: if an omission or concern is called out by the uploader and the upload was for the purpose of asking the SRU team about it. * Can they say no? Nice to haves * Demonstrated familiarity across existing SRU policies and procedures (rather than just having correctly submitted good SRUs that might be limited in parts of SRU policy and procedure that they exercise) * What about SRUs they've sponsored: do they successfully raise the quality of SRU submissions to our expected level before they sponsor them? If so, then this might be a good indicator that they'll be able to do similar at SRU review time. * Do they have a track record of spotting issues before they occur? How broadly do they look when determining "Where problems could occur"? Do they then make sure the Test Plan covers identified risks? * Do they seek to change general policy when appropriate, rather than ignoring it? Can they identify the difference between individual exceptions and the general case? IMHO, for the SRU team, it makes sense to actively approach uploaders who the existing SRU team considers to meet the criteria, rather than have an open application process. I wonder if the archive admin and release teams would think the same, or want a different approach. Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Request to flip weeks for future TB meetings
On Mon, Apr 24, 2023 at 02:36:52PM +0200, Steve Langasek wrote: > Following the roadmap + engineering sprints over the next few weeks, my > availability will flip to opposite weeks from where it is currently. Would > it be possible to move the next TB meeting after this week from May 9 to > May 16, and follow that schedule going forward? +1 from me. If agreed then please could you update the calendar as usual? Robie -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Regrets
On Mon, Apr 24, 2023 at 02:37:36PM +0200, Steve Langasek wrote: > Tomorrow's TB meeting conflicts with obligations at this week's roadmap > sprint and I will be unable to attend. Before the apologies flood in, at the last meeting we agreed to cancel the next meeting, so currently that's scheduled for 9 May. I'll reply to your other email though so that might change. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Code admin for LP Ubuntu project set to ~git-ubuntu-import
FYI, on my request Launchpad added a new "Code admin" role to its distribution model, and using my TB powers I've changed this from unset to ~git-ubuntu-import. This is to skip the current manual step required before a git-ubuntu repository becomes available for a new source package. It will allow the importer to set the default repository target for repositories corresponding to new source package uploads directly, instead of having to wait for a core dev (usually me, Bryce or Andreas) to do it manually. I believe that there's no other implication for this change since it was unset before, and created specifically for git-ubuntu to solve this issue, but thought it appropriate to mention that I've taken this action. See https://bugs.launchpad.net/launchpad/+bug/1992500 for details. Implementation in the git-ubuntu importer will be next. With thanks to Guruprasad, Colin and William for helping me with this. Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Ubuntu Cinnamon for Official Flavor Status
On Thu, Mar 16, 2023 at 04:29:29PM +0100, Lukasz Zemczak wrote: > Would it be possible for us to perform the vote online, via the ML? > I'd appreciate TB members to participate here with questions or votes. > From my side, as I already worked on the flavor bits from the > release-team POV, I am +1 on Ubuntu Cinnamon joining the official > flavors. +1, subject to approval from the Release Team. I appreciate that Steve and Łukasz are on the release team and have also approved; is that also the position of the release team as a whole? signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
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 -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
I won't be able to make the meeting today. Sorry for the late notice. Robie -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Ubuntu Flavours regular sync plan
Hi Mauro, Thank you for organising this! On Thu, Jan 05, 2023 at 10:30:49PM +0800, Mauro Gaspari wrote: > Please review the below details and schedule and email me names and email > addresses of those that are interested to join. Please specify which > session you would like to attend. I aim to join both meetings on 30 Jan. I can speak for the TB on the third party repository requirements topic. See you there! Robie -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Community flavors and new images
On Tue, Jan 10, 2023 at 09:17:29AM -0800, Steve Langasek wrote: > Where would you all like this documented? > https://wiki.ubuntu.com/RecognizedFlavors/AddingNew or > https://wiki.ubuntu.com/RecognizedFlavors/NewFlavorProcess ? I'd like to keep NewFlavorProcess minimal to keep things simple for prospective flavours, so I went ahead and documented this in AddingNew which I see more as internal documentation for the release team. But it's a wiki, so everyone should feel free to adjust as they think appropriate :-) Robie -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Community flavors and new images
My thinking is along the same lines. I'd like to avoid tying up things in bureaucracy, so I think it's fine to leave it to the Release Team to decide if it's obviously and uncontroversially aligned, or if they are unsure if the Technical Board would agree and therefore need to refer it. I'd like for these decisions to be documented though. Maybe we could ask that the technical-board@ list be copied in with an description of the goals of the new image and the Release Team's decision on it? That way, we can ensure that we all stay aligned, and minimise pain if we're not. > flavour process (the one in the works), I think we still need to make > sure we assess the type of the image that the given flavor is adding > and make sure that it's still in-line with the flavor that the TB > approved. The TB is responsible for making sure that the flavour, and > its images, are in line with the goals of the Ubuntu project. I don't > think it's needed to reaffirm this in every case when a new image is > to be added, but the release team needs to make sure to cycle back to > the TB in case there's doubts that this is still the case. > > Cheers, > > On Sun, 8 Jan 2023 at 07:27, Steve Langasek wrote: > > > > Hi folks, > > > > In light of the recent activity on clarifying policies and procedures for > > new flavors, I thought it was appropriate to bring this question to the TB > > for review. > > > > The Xubuntu team are proposing to have a new official Xubuntu image called > > Xubuntu Minimal (né Core) and have raised MPs to get it landed on the > > centralized build infrastructure > > (https://code.launchpad.net/~xubuntu-dev/debian-cd/+git/debian-cd/+merge/435314 > > et al). > > > > In the past, flavors (including Ubuntu) have introduced new images without > > requiring additional TB approval; e.g., Kubuntu Active, Lubuntu Next, and > > the Ubuntu Desktop canary image. These were all handled directly through > > the Release Team. > > > > I think this makes sense, because there are no governance questions here; if > > there is already a flavor team responsible for one image, we just need to > > make sure they're taking responsibility for 2, with the existing team, seed > > structure, etc. > > > > Do you agree? > > > > Thanks, > > -- > > Steve Langasek Give me a lever long enough and a Free OS > > Debian Developer to set it on, and I can move the world. > > Ubuntu Developer https://www.debian.org/ > > slanga...@ubuntu.com vor...@debian.org > > -- > > technical-board mailing list > > technical-board@lists.ubuntu.com > > https://lists.ubuntu.com/mailman/listinfo/technical-board > > > > -- > Łukasz 'sil2100' Zemczak > Foundations Team > Tools Squad Interim Engineering Manager > lukasz.zemc...@canonical.com > www.canonical.com > > -- > technical-board mailing list > technical-board@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/technical-board signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: New Official Flavor Process Issues (Was Re: Ubuntu Cinnamon Remix packages)
On behalf of the Technical Board, I've been working with the flavour leads, as well as prospective new flavour leads, to address the concerns raised in this thread. I think we reached a conclusion at the Ubuntu Summit in Prague, including on specific drafts for a documented process and specific edits to existing documentation. I intend for this email to serve to get everything down for the record, and to share with others who are interested. Scope of relevant teams === The distinction between what is covered by the Technical Board directly and what is delegated to the Release Team is not formally documented anywhere. Since I’m on the Technical Board but not on the Release Team, it’s probably worth clarifying this. In general, what I expect is that a new flavour will require final approval of the Technical Board, and there may be other points on which the Technical Board will make a decision without having delegated it. However, the specifics of the process including technical implementation and the provision of appropriate expertise will be the responsibility of the Release Team. This includes the maintenance of any documentation of these specifics as the Release Team feels appropriate. The flavour team is expected to “do the work” under the guidance and direction of the Release Team under this process. New flavour process === I've documented initial steps at https://wiki.ubuntu.com/RecognizedFlavors/NewFlavorProcess Any community member interested in starting a new flavour should start on this page. Please point them that way, and update any links as appropriate. These steps are intended to be minimal, mostly non-technical, and geared at connecting prospective new flavours with the Release Team, who will be able to specify relevant requirements as they apply at the time. General requirements to become and remain a recognized flavor = These are part of the Release Team's documentation at: https://wiki.ubuntu.com/RecognizedFlavors I've renamed and adjusted this section. Prospective flavours should use these requirements as a rough guide only. The Release Team and/or Technical Board may adjust the general requirements this from time to time, so it's essential to be in contact with the Release Team by following the process mentioned above to avoid surprises. What I've not covered = A wide range of concerns were raised by various people. To make progress, I've tried to better define and improve what I perceived to be the major issue that led to this thread, which was mainly involving communication and mismatched expectations. On specific technical questions and issues related to the rolling of flavour images, I think these should primarily be the concern of the Release Team and not the Technical Board directly. By making sure that prospective flavours have a point of contact on the Release Team, I hope these can be addressed, and any general process documented as needed, on a case-by-case basis and through that point of contact. On concerns about lack of documentation, I make the observation that new flavours are rare, engineering time is scarce, and therefore any documentation in this area is likely to be out of date soon after it is written. The Technical Board is not in a position to assign a documentation author to maintain new flavour process documentation, and in any case if we had that resource I think it would better assigned in other areas lacking documentation in Ubuntu since new flavours are rare. So I hope that I've found a reasonable compromise: the process I've documented should be general enough to survive most technical process changes, and will lead to a connection with a member of the Release Team who will be able to answer questions and help with any of the rest. However, that's just my opinion, and I don't intend to discourage anyone who wants to write documentation for this process, or any other! Certainly the Release Team should continue to document processes as they feel appropriate, and I also encourage flavours to help coordinate and contribute to that effort. signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Apologies
On Sun, Oct 30, 2022 at 12:00:14PM +, Robie Basak wrote: > I won't be able to attend our meeting tomorrow due to a company event. Copy and paste fail. I meant Tuesday. signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
I won't be able to attend our meeting tomorrow due to a company event. signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Changes to the TB meeting schedule
+1. Steve, please could you edit the calendar accordingly? I think only you have access. On Mon, Oct 10, 2022 at 10:58:42PM -0700, Steve Langasek wrote: > Apologies for not mailing about this sooner, but my schedule has flipped > again (effective as of the last meeting) so I will not be able to make it to > tomorrow's meeting (Oct 11) and would like to ask that we flip weeks again > after that. Because Canonical folks have an engineering sprint the week of > November 1, I'd like to suggest we have meetings both October 11 and October > 18, with the expectation of skipping November 1. > > On Wed, Jun 08, 2022 at 12:30:08PM +0100, Robie Basak wrote: > > Hi, > > > > I'm sure you're aware that Steve's availability to attend TB meetings is > > limited at the moment. He's offline at the moment, and needs the meeting > > "phase" to flip again to be able to continue attending. > > > > The next TB meeting is currently scheduled for 14 June. To help Steve > > attend I'd like to change this to 21 June, and then continue every other > > week after that (5 July, 19 July, etc). > > > > Personally I may miss 5 July because of a prior commitment, but I still > > prefer to switch weeks so that Steve doesn't lose his opportunity to > > attend all meetings. > > > > There wasn't an issue with this last time we had to flip it so I'll > > consider this change done unless a TB member objects. > > > > The next TB meeting dates therefore will be: > > > > 21 June > > 5 July > > 19 July > > etc > > > > Thanks, > > > > Robie > > > > > -- > > technical-board mailing list > > technical-board@lists.ubuntu.com > > https://lists.ubuntu.com/mailman/listinfo/technical-board > > > -- > Steve Langasek Give me a lever long enough and a Free OS > Debian Developer to set it on, and I can move the world. > Ubuntu Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Technical Board Elections Schedule
On Fri, Sep 09, 2022 at 11:53:31AM +0200, Philipp Kewisch wrote: > On 9/9/22 11:27 AM, Robie Basak wrote: > >On Thu, Sep 08, 2022 at 03:37:39PM +0200, Philipp Kewisch wrote: > >>2022-11-24 Nominations close, send to Mark for shortlisting > >>2022-12-01 Voting announced > >>2022-12-08 Voting closes, results are announced > >Please can there be a gap between the candidates being announced, and > >the voting beginning? Otherwise there's no opportunity between > >candidates receiving confirmation that they're standing, and the vote > >beginning, for candidates to present their platforms (should they so > >choose) or for there to be any public questioning or discussion. > > > >This isn't something that's been done before, admittedly, but I've felt > >that this has been a flaw at most previous elections operated this way. > That works fine for me, if we get started now we could do this for all the > elections. How much time do you think we need, maybe add another week there? > José does this work for you as well? I think a week would be fine - thanks! signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Technical Board Elections Schedule
Hi Philipp, Thank you for organising this! On Thu, Sep 08, 2022 at 03:37:39PM +0200, Philipp Kewisch wrote: > 2022-11-24 Nominations close, send to Mark for shortlisting > 2022-12-01 Voting announced > 2022-12-08 Voting closes, results are announced Please can there be a gap between the candidates being announced, and the voting beginning? Otherwise there's no opportunity between candidates receiving confirmation that they're standing, and the vote beginning, for candidates to present their platforms (should they so choose) or for there to be any public questioning or discussion. This isn't something that's been done before, admittedly, but I've felt that this has been a flaw at most previous elections operated this way. Thanks, RObie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: [vote] Re: Ubuntu Unity as an official flavor
+1 for inclusion as a daily flavour. Thank you for your contributions to Ubuntu! Please note that this is subject to any future requests or requirements from the Release Team, and the same applies for inclusion in a future Ubuntu release. On Wed, Aug 31, 2022 at 01:12:20PM -0700, Steve Langasek wrote: > Thanks again for your constructive engagement in pursuing official flavor > status. > > I am satisfied that your team has met the requirements for inclusion as a > daily flavor and am voting +1 for Ubuntu Unity moving forward with daily > builds. Becoming a recognized release flavor for 22.10 is contingent on > successfully participating in the 22.10 Beta milestone. > > On Tue, Aug 30, 2022 at 10:47:31PM +0530, Rudra Saraswat wrote: > > Hi Steve, > > > > Thanks for considering our proposal for official flavor status for Ubuntu > > Unity. > > > > - Sorry, didn't mention the MOTU in the Considerations section of the > > proposal (I actually mentioned the MOTU in the Support Plan section). > > seb128's the MOTU, who's been uploading the Unity package updates to > > universe since a really long time. Added this info to the Considerations > > section of our proposal. > > > > - Sure, I've added `ubuntu-unity-meta` to the package list. We'll switch > > over from bzr to git for the seed, no problem. > > > > - Like I mentioned on IRC, I accidentally added VLC to the list when > > replacing Totem with VLC. I've removed it now. > > > > Thank you very much for your feedback. > > > > Kind regards, > > Rudra Saraswat > > > > On Tue, Aug 30, 2022 at 10:33 PM Steve Langasek > > wrote: > > > > > Hi Rudra, > > > > > > Thank you for your interest in becoming an official flavor. > > > > > > Some initial feedback on > > > https://wiki.ubuntu.com/UbuntuUnity/22.10/Proposal: > > > > > > - You mention that you have a MOTU supporting the team but don't say who > > > it > > > is. Please call out explicitly who the uploaders are on your team so we > > > know who to contact in case of issues (and also to confirm with them > > > they > > > are on board with being represented as part of the official flavor > > > effort!). > > > > > > - You list individual desktop components which is important. I think > > > ubuntu-unity-meta should also be listed here (it's important that this > > > package exists, it's to your credit that it is already in the archive > > > and > > > being maintained.) > > > > > > - I notice that the seeds used for building this metapackage are in bzr. > > > Can you please migrate these to git? While it's not a stated policy > > > for > > > new flavors, as a member of the release team I am generally unwilling > > > to > > > add new references to bzr branches in our code; we are in a long-term > > > migration from bzr to git and dealing with bzr branches for seeds for > > > the small number of flavors still using them is an awkward wart on our > > > workflow. > > > > > > - ~ubuntu-core-dev is already a member of ~unity7maintainers, perfect! > > > > > > - It strikes me as odd that you include vlc on the proposal wiki page. I > > > don't think application selection is relevant to flavor approval, as > > > long > > > as the applications you're selecting are from the Ubuntu archive; and I > > > would not expect vlc to be included in a package set that unity7 > > > developers are given per-package upload rights to merely because it's > > > included in your image by default. (It is included by several other > > > flavors, for example, so any issues with that package's maintenance > > > would > > > affect more than just Ubuntu Unity.) > > > > > > Overall this looks like a fine proposal, and I expect we'll discuss more > > > at > > > today's TB IRC meeting. > > > > > > On Mon, Aug 29, 2022 at 11:55:50PM +0530, Rudra Saraswat wrote: > > > > Hi, > > > > > > > > I'm Rudra Saraswat, the dev of Ubuntu Unity ( > > > > https://twitter.com/ubuntu_unity, https://ubuntuunity.org). We are > > > > interested in applying for official flavor status, after having > > > maintained > > > > and developed Ubuntu Unity and Unity7 for over two years (we've had six > > > > releases so far, including two LTS releases). Here's our flavor > > > > proposal: > > > > https://wiki.ubuntu.com/UbuntuUnity/22.10/Proposal > > > > > > > > We also recently released Unity 7.6, the latest version of the Unity7 > > > > desktop environment, which includes a number of new features and a > > > revamped > > > > UI. We've also been collaborating with the UBports team and are > > > interested > > > > in maintaining a Lomiri variant of Ubuntu Unity with the release of the > > > > 24.04 LTS (by which time most of the Lomiri/Unity8 packages should be > > > > present in Ubuntu). > > > > > > > > We have a number of people on-board, including Khurshid Alam, who's been > > > > maintaining Unity7 really well all these years. There's also Maik (who's > > > > also an Ubuntu Member),Tobiyo (also involv
Apologies
On Wed, Jun 08, 2022 at 12:30:08PM +0100, Robie Basak wrote: > Personally I may miss 5 July because of a prior commitment, but I still > prefer to switch weeks so that Steve doesn't lose his opportunity to > attend all meetings. Sorry, as above I will miss today's TB meeting as I had an existing commitment before we switched the meeting times. signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Changes to the TB meeting schedule
Hi, I'm sure you're aware that Steve's availability to attend TB meetings is limited at the moment. He's offline at the moment, and needs the meeting "phase" to flip again to be able to continue attending. The next TB meeting is currently scheduled for 14 June. To help Steve attend I'd like to change this to 21 June, and then continue every other week after that (5 July, 19 July, etc). Personally I may miss 5 July because of a prior commitment, but I still prefer to switch weeks so that Steve doesn't lose his opportunity to attend all meetings. There wasn't an issue with this last time we had to flip it so I'll consider this change done unless a TB member objects. The next TB meeting dates therefore will be: 21 June 5 July 19 July etc Thanks, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Application to form delegated team for sosreport
The code of conduct says: "The poorest decision of all is no decision: clarity of direction has value in itself. Sometimes all the data are not available, or consensus is elusive. A decision must still be made. There is no guarantee of a perfect decision every time - we prefer to err, learn, and err less in future than to postpone action indefinitely." The next scheduled DMB meeting is in less than one hour. So I'm going to put on my TB hat and call it. I am hereby extending the terms of the expired DMB members for two months, starting today. I will proceed with running the DMB election as soon as I can. As soon as the election results are announced, the extension will end, and the newly elected members will take their place. I understand this action to be supported by at least two other TB members and one CC member anyway, so I trust that this is the appropriate thing to do. Robie On Mon, May 16, 2022 at 01:27:20PM -0400, Thomas Ward wrote: > I will point out also from an actionable-policy perspective: > > While the DMB is unstaffed thanks to Dan holding up the request for a new > election to be run by the TB, **the DMB cannot action any requests for > package permissions, packagesets, etc. until a new election happens and the > DMB is restaffed**. > > This is a problem that will break any packageset decisions and any current > technical operations/policies. As long as the DMB is unstaffed, decisions > such as these on delegated packagesets, etc. cannot move forward without a > TB vote since the TB is the only one capable of making these decisions when > the DMB is unstaffed. (Which is why the TB created and delegated membership > rights decisions and such to the DMB) > > The Technical Board and/or SABDFL should take a "Just Do It" approach and, > despite any objections about the existing DMB vote, go forward with the > election for DMB members. Because, without a DMB, nothing will get done. > No new coredevs, no new SRU developers, no new contributing devs, no new > MOTUs, etc. > > > > Thomas > > CC'd: Technical Board > > > On 5/16/22 10:27, Robie Basak wrote: > >On Wed, Mar 30, 2022 at 06:34:58AM -0400, Dan Streetman wrote: > >>I am applying for creation of a delegated team for upload access of > >>(initially) the sosreport package. > >> > >>The suggested name for the packageset is 'ubuntu-support', and > >>criteria for package membership in the packageset is packages used for > >>debugging and supporting Ubuntu. > >> > >>The set of packages, initially, is only the sosreport package, though > >>it is likely we will apply to add more packages in the future. > >> > >>The initial list of members is only me, ddstreet, though after team > >>creation individual members will apply to join. > >To clarify, I understand that what Dan is requesting to be a new > >packageset, defined as "packages used for debugging and supporting > >Ubuntu", to what a new ~ubuntu-support-uploaders LP team would be able > >to upload. The team would be owned and membership managed by the DMB, > >and membership of the team (to be able to upload to the packageset) > >would require an application to the DMB under the usual process. > > > >Dan belonging to the team would be a no-op since he's already a core > >dev. Therefore I don't see the point in him being in this team from an > >ACL perspective. I also don't think there'd be any difference from a DMB > >process perspective if Dan were a member or not. It might be useful from > >a social perspective though, so I have no objection to that part. > > > >However, for there to be a useful point in having this packageset and > >uploading team, we need an actual applicant who can't already upload > >sosreport. And for there to be any point in this being a packageset over > >a simple PPU for sosreport, we'd need a second applicant or a second > >package. > > > >I suggest there's only any point in proceeding once we have either a > >second applicant and a second package to add to the packageset. When > >there's a first applicant, we can simply grant PPU. We can convert it to > >a packageset when there's an actual need. > > > >*** > >The key thing is that we grant uploaders what they need to unblock them. > >*** > > > >It's our job to make sure that a qualified uploaders gets an ACL "+1" > >when they upload what we agree they should be able to upload. Whether > >this is through PPU or a packageset is really just about administrative > >convenience for us. > > > >Separate
Re: Fwd: Expiry of 4 DMB members on the 12th of May - election needed?
On Fri, May 06, 2022 at 03:41:59PM -0400, Thomas Ward wrote: > The Developer Membership Board members (myself included) expire from the DMB > in under six days - is an election required for new DMB members, or will the > TB simply extend our current expirations until an election can be held? Thanks Thomas for raising this. We need to run another election. We can arrange the details at our next DMB meeting I guess. From the TB end, I assume it's fine for the DMB just to go ahead and run their own election again unless there is any objection? In the meantime, I (acting for the TB) can just extend the current DMB memberships for as has been done in the past - unless there is any objection? Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Regrets
On Mon, May 02, 2022 at 06:43:18PM +0200, Steve Langasek wrote: > I'm at a Canonical sprint this week and will be unable to attend the TB > meeting this week. I'm at the same event and also unable to attend, sorry. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
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
--
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board
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 -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
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
--
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: TB: Urgent Escalation of DMB Member Removal / New Vote Decision due to DMB Stalemate
On Tue, Feb 08, 2022 at 08:10:58AM -0500, Daniel Streetman wrote: > Personally, I think this issue isn't really about when or if we hold > an election for empty seats - I think this issue is about if a single > DMB member can prevent the board from following its written policies > due to disagreement with the written policies. I'm disappointed to hear that you see the situation this way. Reading your interpretation of the situation, I remain unconvinced that you actually understand my position. So let me try again. It is *not possible* procedurally for the DMB to take any action that violates the CoC. Doing so is not within the remit of any team in Ubuntu. The only way to interpret any policy is one that observes the CoC. Therefore there cannot, by definition, be any conflict here with the written policy. Either the written policy follows the CoC, or it is invalid. This is what I meant by my assumption that respectfulness was implied. Therefore I am not seeking to prevent the DMB from following its written policy; only that the DMB continue following the CoC and remain respectful to everyone. Further, I am not preventing the board from doing anything. I remain in favour of removing the absent members. I just ask that you do it respectfully. I think it is a gross misrepresentation for you to frame this as me "prevent"ing the board from doing anything. From my perspective, I don't even disagree with the policy! I remain astonished that this is something that others want to push back on. The easiest thing to do would have been to just do it respectfully, and from my perspective you're the one dragging this out. You still have my support in making it happen. Just do it respectfully. And please stop framing this as me blocking you. I maintain that I am not, since all I'm asking for you to do differently is send some emails, and you still achieve what we are both in favour of doing. Really: how hard is this? Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: TB: Urgent Escalation of DMB Member Removal / New Vote Decision due to DMB Stalemate
Thank you Thomas for stepping in to mediate in the meeting and for your
time in writing this up.
On Mon, Feb 07, 2022 at 12:34:07PM -0500, Thomas Ward wrote:
> Robie Basak is against any action until both aforementioned individuals have
> had a chance to respond before we remove them. He is also of the position
> that any response from the absent members would not necessarily affect any
> decision on their removal, however Robie is of the opinion that all
> individuals must be contacted first and must have a chance to respond before
> we simply remove any absent members.
Wearing my DMB hat:
I'm simply saying that it's inappropriate and disrespectful for someone
to find out that they've been removed from the board by reading a call
for nominations for their (now vacated) seat, or from an automated email
from Launchpad. Therefore we must contact them privately first. This is
particularly important in this case since it's their very absence that
triggered this action, so they're more likely to be unaware of it.
I didn't think that the DMB's (passed) motion ("...shall be considered
inactive and removed from membership in the DMB") meant that this would
happen with no other contact with them. I had assumed that a requirement
to do this respectfully was implied. And procedurally, the DMB can't do
anything that violates the CoC anyway, so *if* you agree that removing
them without further contact is not the respectful thing to do, then how
the DMB's passed motion is to be interpreted is moot. So I think the
only question that needs to be answered here is: "what is a respectful
way to proceed?"
I don't think contacting them is hard; nor that giving them time to
respond (say a week) makes any difference in the grand scheme of
progress[1]. It's simply the respectful thing to do. So I'm surprised
that Dan pushed back so hard on this that it had to be escalated. I do
appreciate his impatience, since DMB absenteeism has been a practical
problem for many years. But I don't think that excuses our duty to treat
everyone well, especially members who aren't being paid to support their
activities in Ubuntu. It turned out that they weren't able to contribute
the time. We should be grateful and thankful for what they could
contribute, not treat them badly now.
To be clear, I am in general in favour of the principle of having
absentee DMB members be required to step aside. It is just the
disrespectful manner it is proposed to be done that I am objecting to.
Wearing my TB hat:
I was asked if I was going to recuse myself and abstain from any TB
decision. I'm not sure that makes sense here. This isn't about me. I'm
involved only because I object procedurally. I don't stand to benefit,
nor have any friends or associates benefit, from any TB decision. Were I
not also on the DMB, I'd still object to Dan's proposed course of action
wearing my TB hat only. So for now I am not recusing myself, and
obviously I am in favour of my own position. However if anyone wants to
argue that I should not participate further, I will consider that
argument carefully.
Robie
[1] I say that they should be given the opportunity to respond because
1) people make mistakes; and 2) there may be a valid procedural
objection they wish to make. This gives an opportunity for that to be
considered, and corrected if necessary, before damage to personal
reputations is done. It is not my intention to extend an invitation for
them to remain on the board despite their previous absence; that time
has already passed.
signature.asc
Description: PGP signature
--
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Setting NotAutomatic for hirsute+1-proposed
On Thu, Dec 09, 2021 at 04:27:31PM +, Colin Watson wrote: > This is now ready to use from the Launchpad point of view. There's a > "proposed_not_automatic" flag on distro series exported over the API; if > this is set to True, Launchpad writes "NotAutomatic: yes" and > "ButAutomaticUpgrades: yes" to the Release file. We've also arranged > for *-proposed to be pinned to 500 in launchpad-buildd, so Launchpad > builds will ignore this; I can't speak for other build environments. > > Thus, from the Launchpad point of view this is ready to use, although > somebody may want to check the behaviour of things like sbuild and > pbuilder first. Thank you Colin for the work! If sbuild/pbuilder need adjusting, then maybe we need to do that and then give developers some time to update their chroots so that we don't break them (in non-obvious ways) all at once. Another thought is that if there turns out to be an unintended consequence for users enabling jammy-proposed (after Jammy's release), then we'll have done that to them in an LTS instead of hitting an interim release first. That might adversely affect SRU verification workflow. But given that jammy-proposed is (after release) specifically for opt-in and more-risky-than-stable testing, perhaps that doesn't warrant delaying until Keen. -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies
I'm unable to attend today's meeting. signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: flatpak installation permissions
On Thu, Jun 24, 2021 at 01:30:18AM +, Seth Arnold wrote: > This is in contrast to our apt and snap configuration, where only updates > can be installed without authentication, but new packages require using > sudo or a polkit 'admin' authentication to ensure a human is in the loop. I just had update-manager pop up and prompt me to accept some updates, including some kernel updates. It then asked me for my password before proceeding. Having read your description of what is supposed to happen above, I found this surprising. I assume this happened because kernel updates always involve installing "new" packages. So it seems to me that I may or may not be prompted for authentication on a regular update, depending on what apt has decided is required. This isn't a rare occurrence, presumably because kernel updates are frequent. This behaviour seems surprising to me and it occurs to me that it sort of defeats the point of allowing package upgrades without authentication anyway. It'd be nice if things could be arranged not to require authentication for new packages if and only if those new packages are suggested by apt as part of dependency resolution (as opposed to extra packages by user request). Failing that, maybe it'd be better to either always require authentication, or never require authentication? Because otherwise it's just inconsistent and it therefore becomes meaningless from a user's perspective to sometimes skip authentication. And from the other side it'd be better not to train users to just enter their password whenever they're prompted by automatic "pop-up" machinery. The danger here is that a malicious app could pretend to be update-manager and then request something more nefarious via polkit. If the configuration is changed, then this might also change your view on what Flatpak on Ubuntu should do by default. I think the TB's request for Ubuntu Security Team input still stands; I just thought I'd add this additional feedback. Thanks, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Standing conflict with TB IRC meetings
On Tue, Jul 20, 2021 at 06:32:32AM -0700, Steve Langasek wrote: > I've realized that I now have a standing conflict that will prevent me from > attending the Technical Board IRC meetings for the foreseeable future and > would like to propose that we move it to alternate weeks. That works for me. signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
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 -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: [Packaging] Repackaged DisplayCAL as Dummy Package
Hi Erich, We discussed this at the Technical Board meeting yesterday. We don't have a full answer yet, but the general thought is that there are a set of expectations for: 1) third party repositories enabled by default; and 2) packages installed from third party repositories via the archive; that we'd require to be met for arrangements of this kind. We think we need to enumerate these specifically, and we're working on creating a clear and unambiguous list for you. Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: flatpak installation permissions
Hi Seth and the Ubuntu Security Team, On Thu, Jun 24, 2021 at 01:30:18AM +, Seth Arnold wrote: > The flatpak tools in Ubuntu have different rules for installing packages > than we use in our software center or snap tools: > https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1812456/comments/14 Thank you for raising this, and for your detailed assessment. We discussed this at the technical board meeting yesterday. We'd like to hear the Ubuntu Security Team's opinion on this please; we have little reason to think that we'd want to decide something different from them. Could the Ubuntu Security team please take a look into this and provide an opinion? Seth's original email can be found at: https://lists.ubuntu.com/archives/technical-board/2021-June/002560.html Thanks! On behalf of the Ubuntu Technical Board, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Apologies, missing meeting of 18 May
Sorry, I am unlikely to make tomorrow evening's meeting. On action items, I have tried to reach Martin a couple of times about the MATE Boutique item, but have had no luck. I'm hoping to catch him and get latest contact details if/when he responds to the flavor sync request in ubuntu-devel@. If that doesn't happen, I guess the MATE Boutique question will become moot anyway. I don't see anything else new in the agenda so I hope my absence won't hold anything up. Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Ubuntu MATE's Software Boutique and third party sources
Hi Martin, On Wed, Feb 21, 2018 at 05:26:45PM +, Martin Wimpress wrote: > I can attend the TB meeting on the 27th, I've rearranged some personal > commitments so I can be free in the evening. If there is anything we > can discuss prior to the meeting via email, then we can do that too. > I'm certainly open to suggestions as to what we can modify to retain > features that our users find extremely valuable. > > We are currently re-working Welcome and de-coupling the Software > Boutique into it's own application. Along the way we are cleaning up > how AptDaemon/PackageKit are used, so the calls to external utilities > are not required. We also adding support for snaps and Welcome and > Boutique are going to be delivered as snaps, initially classic but I'm > talking with the security team to determine what interfaces are > required so that we can strictly confine both applications yet still > be able to install software via apt and snap. The TB has an outstanding action item that apparently awaits a response from you. It's been languishing a long time, and I suspect is out of date or missing further action that was already taken. Maybe the email I'm replying to is actually the expected response from you? Could you update us on your understanding of the current status of this, please? Thanks, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Documenting significant decisions in Ubuntu
Dear list, I asked[1] that we document our decision about Thunderbird, and this led to a Discourse post[2] aimed at our community to explain what we decided and why. In the TB meeting of 26 January[3], we talked at some length on what we'd like to do in general, and I took the action to put together a proposal. Here it is. # What we'd like to improve 1. The Ubuntu support community sometimes finds itself in the dark when some changes start affecting users. 2. Although logs and mailing list archives exist, there is no clearly identifible record of decisions that have been made by the Technical Board. # Proposal When we make a significant decision, we document a summary somewhere public. It should: 1. Be reasonably self-contained, so that readers don't have to read through discussions to be able to understand the conclusion. 2. Be directly linkable. When it's a TB decision, we will additionally link to it from an index that we will maintain somewhere. For other Ubuntu developer teams, I'd like to simply encourage that they do the same. We will lead by example. I should note that some teams have already been doing this, and I think communication about things so far in 2021 has been a great start compared to how we did last year. I'd like more of the same! # Out of Scope We did discuss at length where we might document things, where we'd link to things from, what process to follow, what to recommend, and so forth. I expect there will also be a question on what "significant" means in my proposal above. I suggest that for now we leave all of that open. It'd be an improvement just to consistently have the above, and we can start to recommend things by example as good patterns emerge. For the TB, we can just do what we did with Thunderbird: decide when something is significant and request documentation on individual occasions as we feel appropriate. # Examples https://discourse.ubuntu.com/t/thunderbird-lts-update/20819 Here we used the form "Decision, Rationale, Known Downsides, Available Workarounds" which I think works well to address the community should they wonder what happened and why. https://discourse.ubuntu.com/t/psa-20-04-2-install-failure-bug-images-soon-to-be-recreated/20846 Not exactly a "decision", but this is exactly the sort of thing I think is really useful for the community. Thanks Laney! https://ubuntu.com/blog/private-home-directories-for-ubuntu-21-04 On switching to private home directories by default. Thanks Alex! [1] https://lists.ubuntu.com/archives/technical-board/2021-January/002531.html [2] https://discourse.ubuntu.com/t/thunderbird-lts-update/20819 [3] https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-01-26-19.59.html signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Updating thunderbird from 68 to 78 in focal
Just to wrap this up from a TB perspective, we've taken the TB's consensus to be what Marc suggested in this thread, and this was discussed at the TB meeting of 26 January[0]. We further agreed in that meeting that we would like the decision to be documented, but left open exactly how that would happen. Olivier and I worked together on some documentation and Olivier posted this to Discourse[1] yesterday. Wearing my SRU team hat, I've been working on a few review iterations on the updated packages with Olivier, and should be able to land this soon into focal-proposed and then, assuming SRU verification goes well, into focal-updates. Thanks Olivier for driving this! Robie [0] https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-01-26-19.59.html [1] https://discourse.ubuntu.com/t/thunderbird-lts-update/20819 signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: What is this list for?
A couple of people have pointed out to me that the list description isn't clear. It currently just says[1]: > This is a list for the members of the Ubuntu Technical Board so they > may be contacted directly. To help prevent future accidents and following the example set by the list descriptions for ubuntu-devel@ and ubuntu-devel-discuss@ (copy below for reference) I propose that we change this to: --- * Deliberations between Ubuntu Technical Board members * Point of contact to reach the Ubuntu Technical Board * Open to all to subscribe, posting moderated for non-subscribers Most decisions in Ubuntu are made directly by consensus between Ubuntu developers, discussed on the ubuntu-devel mailing list as necessary. The technical board mailing list is intended for use only when the usual decision-making routes are inappropriate, have been exhausted, or decisiveness is otherwise required. --- (I'm not sure I'm happy with the wording in the last paragraph; suggestions appreciated) For reference, ubuntu-devel@ and ubuntu-devel-discuss@ are described as follows: ubuntu-devel@ list description[2]: --- * Discussions among Ubuntu developers about their projects * Developer questions about Ubuntu policies and procedures * Discussions seeking consensus among Ubuntu developers * Point of contact for upstream developers to reach Ubuntu developers * Open to all to subscribe, posting moderated for people who are not Ubuntu developers See the ubuntu-devel-discuss mailing list for unmoderated discussion about the development of Ubuntu. --- ubuntu-devel-discuss@ list description[3]: --- * Sharing of experiences with the current development branch of Ubuntu * Technical questions about new features in the development branch * Ideas and suggestions about future development of Ubuntu * Point of contact for Ubuntu users to reach Ubuntu developers * Open to all to subscribe, posting moderated for non-subscribers --- [1] https://lists.ubuntu.com/mailman/listinfo/technical-board [2] https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel [3] https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Updating thunderbird from 68 to 78 in focal
Thanks Marc! I think this is resolved then? Comments inline, and one request at the bottom. On Mon, Jan 18, 2021 at 09:13:38AM -0500, Marc Deslauriers wrote: > Since the packages contain software that is meant to run specifically > in firefox and thunderbird, and the only reverse-depends seems to be > enigmail which is now obsolete, I think it is appropriate to simply > SRU empty packages. I assume this will be done with enigmail too since > it is no longer compatible or required with the newer thunderbird? > > While I can't recall the exact details, I'm pretty sure we did > something similar to firefox plugins when we switched to shipping new > upstream versions instead of > backporting patches. > > As for documenting the breakage...adding a note to the NEWS file in > the empty packages should be sufficient. Do you expect this to > actually break something? > > If any other member of the tech board disagrees with this, we can add > it as a topic for our next meeting. That perfectly answers my questions. Thanks! On Mon, Jan 18, 2021 at 03:37:48PM +0100, Olivier Tilloy wrote: > That's right, but the enigmail maintainer released an update that is > compatible with thunderbird 78 and shows a wizard on first run after > the update to import settings and keys into thunderbird's built-in PGP > support. > This is enigmail 2:2.2.4-0ubuntu0.20.04.1 currently in focal-proposed, > and it goes hand-in-hand with the thunderbird update. Excellent. Thank you! I have just one request, which to be clear is new and open to discussion, not a mandate. I've seen various changes we've made deliberately over the years cause a great deal of confusion in the Ubuntu support community, but I haven't been able to link to a single straightforward explanation. Usually, I think if our rationale were known, our users would be able to work with our changes better. So can we have a single authoritative explanation somewhere please, that explains what we're doing, why we're doing it, and the downsides of the trade-off we've chosen to accept? In this case, I suppose the downsides are some user disruption for former Enigmail users, and the removal of the two plugins - but we're doing it for good reason. I don't have a strong opinion on where we should document this (whether for example it's in a mailing list, a blog post, the wiki, a long bug comment or a Discourse post) - just as long as it's documented somewhere that can be linked to. I appreciate this mailing list and the bug might serve as a record that explains everything, but I think it's hard for others to dig through to find what actually happened amongst all the noise - hence my request specifically for a summary somewhere that can easily be linked to. This is something I propose that we start doing for _any_ significant user-disrupting change. Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
[TB/DMB] New packageset canonical-oem-metapackages
Filed: https://bugs.launchpad.net/ubuntu-community/+bug/1891166 Please: for series in $(distro-info --supported); do edit-acl -P canonical-oem-metapackages -S $series -p developer-membership-board create edit-acl -p canonical-oem-metapackage-uploaders -P canonical-oem-metapackages -S $series add done # Use "Packages matching glob oem-*-meta" for the description when # prompted please Thanks! signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Fwd: [Bug 1881261] Re: [SRU] v1.0.2 service release for budgie-extras
On Wed, Jul 15, 2020 at 03:08:26PM +0100, David Mohammed wrote: > These are fixed issues for GUI based applets to budgie-desktop and > cannot have automatic type tests - hence the manual test steps in the > SRU itself. Ah - sorry. Are you saying that you are covering _every_ change you're making in the proposed SRU with a manual test that you will perform during SRU verification? If so, sorry I didn't realise this was the case - usually there'd be a separate bug reference for each one. In that case, I don't think this is a TB item - we (SRU team) can just accept that because it achieves the spirit of what the TB have said they want. Please could you confirm the above is correct, and if so, I can just proceed, unless someone objects. Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Developer Membership Board Election Results
Dear Technical Board, Following the DMB election, please adjust membership of ~developer-membership-board in Launchpad as follows: Add ~rafaeldtinoco, ~ddstreet, and ~teward, all with an expiry date of 2022-05-12. Extend ~racb, ~slashd, ~tsimonq2 and ~sil2100 to 2022-05-12. Retire ~micahg (the other two stepping down have already had their terms expire, so do not need any further action). Please also adjust the membership of developer-membership-bo...@lists.ubuntu.com accordingly. For the record, I'm aligning everyone to the 2022-05-12 date. Since the dates are all close enough together anyway this seems easier administratively. Micah has agreed to stand down a little early to help with the convenience of this - thank you! Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Core dev requirement for developer membership board seats?
On Wed, Jan 15, 2020 at 02:41:21PM +, Robie Basak wrote: > So here's the question: how should we define the set of people who are > eligible for a seat on the developer membership board? Following this discussion I polled the DMB. Our majority opinion is that candidates should be either core dev or MOTU, so I will proceed with a call for nominations on that basis. signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Core dev requirement for developer membership board seats?
On Sun, Jan 19, 2020 at 02:40:10PM -0300, Rafael David Tinoco wrote: > Quick orthogonal question: What if... joining CoreDev obligates one to > be a DMB member (or, at least, applicant) in that same year ? Or 1 year > later, after one is a bit more experienced ? I appreciate you thinking outside the box on this. I'm not sure about such a mandatory requirement on volunteers though. It might put off core dev applications, or lead to more DMB members simply being absent at meetings, which is already a problem. Community Free Software projects have traditionally always held a "volunteer what you can" philosophy with no forcing of any volunteer to do any additional work. I think that's a great and appropriate way to treat all volunteers, and this would go against that. However, there's nothing to stop an interested employer mandating that any of its employees who get core dev must then stand for the the DMB for one term or something like that. Since the employees get paid and therefore the employer would be in a position to tell them what to do as part of that job. That might help :) Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Core dev requirement for developer membership board seats?
On Fri, Jan 17, 2020 at 09:18:51AM -0500, Dan Streetman wrote: > The SRU process is most certainly not 'narrow' ;-) It covers the vast > majority of what coredevs need to know, at least IMHO. I disagree. Core devs and MOTUs need (at least) to be able to do package merges, understand[1] the development release cycle, freeze milestones and exception processes, proposed migration and transitions, and the main/universe split and how it affects dependencies. Core devs additionally need to understand[1] seed handling and MIRs. SRU developers don't need to know anything about those areas, nor even know that they exist. When considering an SRU developer application, I don't consider any of these areas. In fact that was the point of creating the SRU developer team: to allow developers to make progress _without_ having to learn or demostrate the wider stuff. [1] I don't necessarily expect detailed direct experience in all of these, but I do expect to see direct and deep experience of at least some of them and a general understanding of most of them. signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Core dev requirement for developer membership board seats?
On Wed, Jan 15, 2020 at 11:43:53AM -0500, Dan Streetman wrote: > As DMB members are expected to have familiarity with the process, I > think it's reasonable to limit eligibility to members of > ~ubuntu-core-dev, ~ubuntu-sru-developers, or ~motu. Why ~ubuntu-sru-developers? They have a narrow focus (SRU process only), so I don't understand how this would fit if the justification for limiting the eligible set is "must have a wide set of experience and knowledge to effectively assess core dev competencies". signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Core dev requirement for developer membership board seats?
[Note that this email is public; I see no reason to keep it private. I'm asking the current DMB and TB for advice, but I'm also interested in hearing the opinions of other Ubuntu developers (ie. the electorate)] I am preparing a call for nomimations for the developer membership board as some members' terms have expired and others' are expiring soon. I seem to recall that there was a question last time about whether there should be a core dev requirement to serve on the board, as otherwise we end up in a situation where non core devs vote to grant core dev membership to others or even themselves. This may or may not be perfectly fine depending on your point of view. I believe this happened to Simon - but as we expected at the time he applied and got core dev shortly afterwards (I believe he recused himself from that vote) and so the situation was resolved that way. It's also worth noting that the DMB is usually short of nominees when it comes to board elections, and attendance from quite a few board members has been very low for the last few years, causing much frustration amongst applicants when we have not been able to make quorum. Therefore, from the other side, limiting eligibility has the potential to be harmful. So here's the question: how should we define the set of people who are eligible for a seat on the developer membership board? In case this ends up being contentious, I should note that organisationally I believe this is ultimately a matter for the current DMB and current TB to decide between themselves. But it seems appropriate to invite comment from the electorate to help them form an opinion. Thanks, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Expiry policy for flavor developer team membership
On Tue, Jul 16, 2019 at 12:22:26PM -0700, Steve Langasek wrote: > Do you agree with this proposal, and if so could you put it into effect? I'm interested to hear what the flavour leads and teams themselves think of this proposal. Though the rationale sounds good to me, I wouldn't want to commit without giving them the opportunity to provide feedback, in case there's anything we haven't considered. Is there a definitive way of contacting them for feedback? The best I can think of is ubuntu-release@, but that doesn't seem quite suitable. Or just ubuntu-devel@? Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
FYI: switch of default Launchpad VCS to git
Now that we have experimental "git-ubuntu" git repositories available for most packages in main, we (the server/git-ubuntu team) will be switching the default VCS for the Launchpad "ubuntu" distribution over to git. This would mean that the git-ubuntu repositories would be visible directly at URLs such as: https://code.launchpad.net/ubuntu/+source/hello ...instead of seeing the out-of-date Bazaar repositories and having to click specifically on "View Git repositories" from there. However, please note that the git-ubuntu repositories are still experimental and we expect to "reimport the world" at least once before declaring the branches stable. When we do this, users will see non-fast-forward pushes to all branches. Despite this, we think that this is objectively better than the current situation since the git-ubuntu repositories, where present, are generally current, and this enables the ability for anyone to point to particlar parts of the Ubuntu source as well as investigate how it has changed. On behalf of the TB, Steve has agreed to make the change, so please take this as an FYI to expect this change soon. Thanks, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Poll: Ubuntu Technical Board election 2018
On Fri, Oct 05, 2018 at 12:51:39AM -0400, Ubuntu Community Council (CIVS poll supervisor) wrote: > A special thank you goes out to Marc Deslauriers and Stéphane Graber who will > both be stepping down. Marc is in the poll. Is there a mistake? Separately, I remember someone (Laney?) asking for an opportunity to question the candidates. Is there a plan for this please? In any case, as a nominee I invite questions now if anyone wants to ask anything. Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
[TB/DMB] PPU addition for ~unit193
Filed: https://bugs.launchpad.net/ubuntu-community/+bug/1786861 Please: edit-acl -p unit193 -s irssi -t upload add Thanks! signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
[TB/DMB] PPU additions for ~chad.smith
Filed: https://bugs.launchpad.net/ubuntu-community/+bug/1784421 Please: for p in curtin cloud-init; do edit-acl -p chad.smith -s $p -t upload add done Thanks! signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Call for nominations for the Technical Board
This is my self-nomination for the Technical Board. Thanks, Robie On Wed, May 23, 2018 at 11:19:18AM -0700, Walter Lapchynski wrote: > Hello Ubuntu developers, > > The current 2-year term of the [Technical Board][1] is over, and it's > time for electing a new one. For the next two weeks (until 6 June 2018) > we are collecting nominations, then our SABDFL will shortlist the > candidates and confirm their candidacy with them, and finally the > shortlist will be put to a vote by [~ubuntu-dev][2]. > > Anyone from the Ubuntu community can nominate someone. > > Please send nominations (of yourself or someone else) to > Mark Shuttleworth and CC: the nominee. > You can optionally CC: the [Technical Board mailing list][3], but as > this is public, you *must* get the agreement of the nominated person > before you CC: the list. > > The current board can be seen at [~techboard][4]. > > Thank you, > > Walter Lapchynski > Ubuntu Community Council > > [1]: https://wiki.ubuntu.com/TechnicalBoard > [2]: https://launchpad.net/~ubuntu-dev > [3]: https://lists.ubuntu.com/mailman/listinfo/technical-board > [4]: https://launchpad.net/~techboard/+members > > -- >@wxl | polka.bike > C563 CAC5 8BE1 2F22 A49D > 68F6 8B57 A48B C4F2 051A > > -- > ubuntu-devel-announce mailing list > ubuntu-devel-annou...@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: xchat and hexchat
On Thu, Mar 08, 2018 at 10:01:32PM +, Robie Basak wrote: > I'd like to bring the release team's attention to this bug: > > https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1753169 > > This seems like a matter where people are getting quite personally > and emotionally involved, so I think it's probably best for most of us > to stay out of it and leave it to our designated leaders to make a > decision, per our CoC. > > I'm not sure if it's an archive admin thing, a release team thing, or a > tech board thing. If it isn't obvious which team should make the > decision, perhaps it should be left to the TB to decide that first. But > if a decision needs to be made, that decision should probably be made > before Bionic's release, so I thought it'd be appropriate to bring it to > attention on this list now. > > As the only one of these three teams that has regular meetings is the > TB, should this be added to the TB agenda? I've added this to the TB agenda. I imagine it'll take quite a bit of reading of the various references (I've added them to the agenda item) so appreciate you may not be able to decide by tomorrow's meeting. Please note that I have no horse in this race. I have my opinions but either way would be fine with me, as long as the bug gets closed with _some_ resolution. I'm bringing this to the TB as I think we need _a_ decision and it would be helpful to the community to not let it languish. Thanks, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
[TB/DMB] PPU additions for ~feng-kylin
Filed: https://bugs.launchpad.net/ubuntu-community/+bug/1736353 Please: for p in ukui-menu ukui-indicators ukui-control-center ukui-session-manager ukui-screensaver peony ukui-desktop-environment; do edit-acl -p feng-kylin -s $p -t upload add done Thanks! signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
[TB/DMB] PPU addition for ~osomon
Filed: https://bugs.launchpad.net/ubuntu-community/+bug/1733351 Please: edit-acl -p osomon -s chromium-browser -t upload add Thanks! signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU exception for snapd-glib
On Tue, Jun 06, 2017 at 08:59:43AM -0700, Steve Langasek wrote: > With my SRU team hat on, the process now is: > > - draft a wiki page, such as the ones you reference >(https://wiki.ubuntu.com/SnapdUpdates), outlining what you believe should >be the exception > - submit it to the SRU team for approval. This can be done to any >individual member of the SRU team directly, or you can send it to >ubuntu-rele...@lists.ubuntu.com for review. I gave exactly these instructions to another team a couple of weeks ago, so I've just gone ahead and documented this at: https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases I'm not sure it's the best place. Where would people expect to find this information? Suggestions welcome. Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
[TB/DMB] PPU additions for ~happyaron
Filed: https://bugs.launchpad.net/ubuntu-community/+bug/1689351 Please: edit-acl -p happyaron -s ocserv -t upload add Thanks! signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: [TB/DMB] ACL for ~ubuntu-sru-developers
On Mon, Mar 20, 2017 at 05:53:09PM +, Robie Basak wrote: > Please give the ~ubuntu-sru-developers team permission to upload > packages to stable releases. Details at: > https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039702.html Can someone look at this please? I think you missed this item in the last TB meeting, and with today's TB meeting cancelled, it looks like this new uploader may be waiting six weeks or more otherwise. Thanks, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: [TB/DMB] PPU additions for ~paelzer
NFI what I just managed to do. Take 2:
Filed: https://bugs.launchpad.net/ubuntu-community/+bug/1681871
Please:
for p in multipath-tools postgresql-9.{1,3,5,6}; do
edit-acl -p paelzer -s $p -t upload add
done
Thanks!
signature.asc
Description: PGP signature
--
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board
[TB/DMB] PPU additions for ~paelzer
-- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Define a package-set for Ubuntu Budgie
Hi, On Tue, Mar 28, 2017 at 04:23:57PM +0100, foss.freedom wrote: > This cause a lot of confusion and DMB have redirected me back to the TB. We did? This doesn't match my understanding. Please can you tell us what gave you this impression? Usually the DMB decides and defines packagesets, not the TB. Since I'm pretty sure the TB doesn't expect to have any involvement in this, I'm moving this thread back to the devel-permissions@ list, with the TB in Bcc only. > Please can a packageset be officially defined for Ubuntu Budgie? We (the DMB) deferred defining a packageset because packagesets are only used for access control, and we currently don't have anyone approved to be in that access control list anyway. So it shouldn't make any difference whether a packageset is defined right now or not. Have I missed something? Is there any other reason you need a packageset defined right now? Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
[TB/DMB] ACL for ~ubuntu-sru-developers
Filed: https://bugs.launchpad.net/ubuntu-community/+bug/1674440 Please give the ~ubuntu-sru-developers team permission to upload packages to stable releases. Details at: https://lists.ubuntu.com/archives/ubuntu-devel/2017-February/039702.html I believe the command I want is: for series in precise trusty xenial yakkety; do edit-acl -p ubuntu-sru-developers -S $series --pocket proposed -t upload add done If this works, then I will need to add this to the new release cycle process. Thanks! signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Please clarify: SRU team accepting NEW?
Dear Technical Board, Now that the SRU team directly handles new things hitting LTS releases, we're getting a number of things appearing in the NEW queue for Xenial. There seems to be some confusion about whether these need AA review or not. IMHO, the confusion itself is slowing things down as different SRU team members hold different opinions on whether they're OK to accept these without an AA. Current examples are: chrome-gnome-shell (ready now), and some letsencrypt-related pieces (need review changes, but the question came up). The queue also currently contains flatpak and bubblewrap. Please could you clarify? Perhaps in the specific case of straight backports from the development release, where an archive admin (or Debian ftpmaster) has already accepted the package? Is it OK for the SRU team to review and accept these packages themselves when satisified, or must an archive admin review first? Thanks, Robie signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: Tracking DMB->TB admin requests
On Tue, Nov 22, 2016 at 11:35:10AM -0500, Stéphane Graber wrote: > I'd say, just send us a PGP-signed e-mail to the mailing-list with the > list of edit-acl commands you want us to run. On Tue, Nov 22, 2016 at 08:44:41AM -0800, Steve Langasek wrote: > For a process, I think the community bugs are a better option overall than > email. What was the conclusion, please? Here'a a bug: https://bugs.launchpad.net/ubuntu-community/+bug/1661171 and here's a PGP-signed email :-) signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Tracking DMB->TB admin requests
Hello! Please can we have a process to make sure DMB ACL changes requested from the TB get done? IMHO, we've had some delays getting changes approved by the DMB implemented where they require (mechanical) TB action. These are PPU ACL changes as well as the creation of packagesets. infinity is the only person on both boards. I appreciate his input and presence on the DMB when needed as a senior representative. But we know that he's generally busy wearing all of his other hats. In practice this means that DMB requests slide, which is bad for newly approved applicants who get blocked. And then the DMB have to follow up, which we're bad at too. Can we have a process for tracking in-flight requests? We could provide the edit-acl commands to run. I'd like a system where we throw things in at one end, and you do them at the other end, without manual followups which slow things down. Perhaps you could have an agenda item to check and run any outstanding changes from wherever we agree that the DMB should put them? I started filing "community bugs" to see if that might work[1][2], but in hindsight this probably isn't the right place. Some options: 1) One bug per request. But against what project, with what tags, etc? 2) Request by PGP-signed email to technical-board@ and add individual references to the TB meeting agenda so that they get tracked by being turned into actions. Thoughts? Thanks, Robie [1] https://launchpad.net/bugs/1643648 [2] https://launchpad.net/bugs/1643859 signature.asc Description: PGP signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU policy: Allow new features in LTSes under certain conditions
Hi Martin, On Wed, Sep 16, 2015 at 06:58:13AM +0200, Martin Pitt wrote: >...so if as a sponsor you are > convinced that SRUing that new feature is a good idea, safe, and > matches the above policy, then go ahead. The SRU team will review the > change anyway. OK, so the sponsor and SRU team will between them end up deciding whether a new feature is in principle acceptable to SRU? That's clear to me then - thanks. Robie -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU policy: Allow new features in LTSes under certain conditions
Hi Martin, Could you please provide some clarification on one aspect of your proposal? On Tue, Sep 01, 2015 at 05:45:26PM +0200, Martin Pitt wrote: > They must not change the behaviour on existing installations > (e. g. entirely new packages are usually fine). If existing software > needs to be modified to make use of the new feature, it must be > demonstrated that these changes are unintrusive, have a minimal > regression potential, and have been tested properly. For clarity, let me call the above requirements "the quality criteria". Consider a new feature where the proposed LTS update does meet the quality criteria. Who will decide whether this feature is acceptable to SRU to the LTS? Would each proposed feature still need to go individually to the TB for approval? Or would this new policy give uploaders the ability to add new features to the LTS directly, since the SRU team would simply approve it under this new policy? For example, what should a sponsor do to handle a new feature in the sponsorship queue? Just upload if it meets the quality criteria, to be accepted by the SRU team after they have double-checked? Or should extra steps be taken to determine if we want the new feature in the LTS? Thanks, Robie -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: MRE for juju-core/juju-mongodb
On Wed, Apr 09, 2014 at 06:58:06PM +0200, Martin Pitt wrote: > Ordinarily I trust the SRU team to decide whether a new microrelease > with a couple of bug fixes fits the normal SRU criteria; if there is a > case where there are tons of changes, or new features, I'd rather > bring this up again as a concrete case. I believe we have a concrete case now, so I'd like to bring this up again on the basis that we have tons of changes. I've taken over some juju-core packaging work from James. In particular: Trusty is on 1.18.1-0ubuntu1, and I want to bump this to 1.18.4. I've uploaded 1.18.4-0ubuntu1 to utopic-proposed. It's blocked from migration due to a powerpc FTBFS, which we've determined doesn't affect Trusty (bug 1329295). I'd like to push ahead with an SRU to Trusty for 1.18.4 even though the FTBFS isn't resolved yet. This involves around 20 bugs and some minor metadata changes which it made sense for upstream to commit to 1.18 (IMHO). I have filed bug 1329302 to track this SRU and have placed the full bzr changelog for all 1.18.1 -> 1.18.4 upstream commits in the bug description. How should I proceed? Will you consider granting at least a one-time MRE for this, please? On Tue, Apr 15, 2014 at 11:03:47AM +0100, James Page wrote: > > My gut feeling is that provided enough testing (automatic or > > manual), this looks like an adequate SRU for an LTS. I think it's > > too intrusive/too much work for saucy as that's not an attractive > > server platform and will go EOL in 3 months anyway, but I'd be okay > > with going through that exercise as a kind of test run for this > > MRE request. > > My thinking as well - I've been trying to use the 1.16.x series on > saucy as drill practice for a LTS release to get both the server team > and upstream juju-core into a common understanding of how the process > should work. > > > All individual bugs have been prepared with the SRU info and test > > cases, yay for that! > > Yup - just finished up those so that we can push onwards with this SRU > and hopefully help support the MRE request. So this test run was successful, AIUI, and involved 11 bugs that James had addressed individually. Will you consider granting a provisional MRE for juju-core based on this past performance, please? Thanks, Robie signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
MRE request: mysql-5.5
Application drafted by MySQL upstream: I would like to apply for a micro release exception for MySQL Server. Upstream: - Micro releases happen from low-volume stable branches, approximately once every two months. - Stable branches are supported with bug fixes for 8 years. - Upstream commits are reviewed by members of the MySQL Server Engineering team. - All commits to stable branches are evaluated wrt. potential regressions and signed off by the MySQL Support team. - Unit tests and regression tests are run on multiple platforms per push to the source code repository. In addition, there are more extensive test suites run daily and weekly. - Unit and regression tests are run on both debug and optimized builds. - Each micro release receives extensive testing between code freeze and release. This includes the full functional test suite, performance regression testing, load and stress testing and compatibility and upgrade testing from previous micro and minor/major releases. - Tests are run on all supported platforms. In Ubuntu: - Unit and regression tests are run as part of the package build process, and the package FTBFS if tests fail. - Micro releases for MySQL Server 5.1 and 5.5 have routinely been accepted as security updates since Ubuntu 12.04 without known regressions. Additional notes (by rbasak): +1 from the Ubuntu Server team. We've been in regular contact with upstream for a while now, including their attendance at a number of past vUDSs. I met them last weekend at FOSDEM, and we discussed this exception. Upstream do not make security patches publicly available, instead releasing a new stable release each time security updates are required. Thus, the security team have had no choice but to bump to the latest release for mysql-5.5 security updates anyway. So users get a micro release bump that includes bugfixes when there is a security update, but do not get bugfixes if there is an upstream stable release that do not include any security updates. Given that this happens, it is an odd situation that users end up effectively waiting for a security vulnerability to get any intermediate bugfixes. An MRE would make the experience for users more consistent. Thanks, Robie signature.asc Description: Digital signature -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
