16:05 <schopin> #startmeeting Developer Membership Board
16:05 <meetingology> Meeting started at 16:05:17 UTC.  The chair is schopin.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
16:05 <meetingology> Available commands: action, commands, idea, info, link, nick
16:05 <adrien> so, I got a small issue on the wiki and got locked out a few days ago; I wasn't changing many things anyway but still, a small annoyance
16:07 <schopin> #topic Application Review: Core Dev application by Adrien Nader
16:07 <schopin> #link https://wiki.ubuntu.com/adrien/CoreDevApplication
16:08 <schopin> Hi adrien :) Would you mind starting off with a short introduction?
16:08 <tsimonq2> o/ sorry for the delay, time zones are tough, thanks for the ping schopin :)
16:08 <schopin> been there ;)
16:09 <rbasak> adrien: hello!
16:09 <rbasak> adrien: I'm not easily spotting a peer review for a complex merge. For example, where was https://launchpad.net/ubuntu/+source/openssl/3.2.2-1ubuntu1 reviewed please?
16:09 <adrien> Hey, so, Adrien Nader, living in Paris, started actively contributing to Ubuntu as I started at Canonical in the Foundations team. Mostly dealing with cryptography-related packages there.
16:10 <rbasak> Ah. I found https://code.launchpad.net/~adrien/ubuntu/+source/openssl/+git/openssl/+merge/466581 which is good enough for me.
16:10 <tsimonq2> rbasak: https://code.launchpad.net/~adrien/ubuntu/+source/openssl/+git/openssl/+merge/480582 too :)
16:11 <bdrung> Not having related bug reports that are mentioned in d/changelog makes it hard to find the merge requests.
16:11 <adrien> I'll take pride in saying that openssl has been complex to merge in the past but it's now much easier. I've cleaned a lot and moved everything to git-ubuntu too (in that order, I couldn't do it the other way round).
16:12 <rbasak> adrien: good to hear. Do you push any tags when asking for a git-ubuntu workflow merge?
16:13 <adrien> rbasak: No, because I think I'm not aware of that functionality but I think it could have been useful to me a couple times (does it preserve history/allow to store more data for later use?)
16:13 <adrien> but I'll look that up
16:13 <tsimonq2> adrien: On a pretty general note to start off (do your best :)), how do you see the cryptography packages in Ubuntu evolving and improving over the course of the next few years? Is there anything you're particularly excited for?
16:14 <rbasak> It's not a criterion for this application IMHO, but to review a merge, it's useful to validate the logical tag (git diff logical/... old/debian should be empty apart from metadata), then use git range-diff to compare that against the proposed merge branch.
16:14 <schopin> adrien: AFAIK the tags mostly makes the review easier.
16:14 <adrien> bdrung: I reckon that opening bugs is not my strong point. I think it's a weak spot when using git-ubuntu because it basically means having two places for the change which feels very weird to me (especially for openssl where I've done many merges now)
16:14 <rbasak> That's the most effective way of reviewing a package merge. It's basically impossible otherwise.
16:15 <rbasak> FWIW, I don't consider it a requirement for there to be a merge bug, but I do like to find peer reviews when assessing DMB applications, regardless of how I reach them :)
16:15 <tsimonq2> rbasak: ...FTR, *I* wouldn't have been able to answer that specific git-ubuntu question. heh. maybe I need to read up.
16:15 <rbasak> s/find/consider/ - it's not the finding that's important.
16:15 <adrien> tsimonq2: I think the post-quantum stuff is very interesting because it's not only post-quantum but also a lot of better approaches than the preceding decades. I guess, more rust too. And openssl, I think I like the new organization which is certainly a plus.
16:16 <tsimonq2> adrien: Great, thanks :) indeed, post-quantum stuff seems fascinating.
16:18 <bdrung> adrien, I agree that opening bug reports just for tracking merges is not needed.
16:18 <adrien> rbasak: I don't think someone raised that up with my MRs so far. I've been trying to do more git-ubuntu things with the "regular" git commands as an experiment and it's not a surprise I haven't yet reached 100% coverage yet (we can discuss that later probably if you want)
16:18 <tsimonq2> adrien: What's the difference between Feature Freeze and Beta Freeze, and how do you tell whether your New Shiny Upload breaks those freezes, or others?
16:18 <tsimonq2> bdrung: +1
16:19 <tsimonq2> (There has to be some halfway point between "we require a bug report for every merge in addition to a git-ubuntu merge" and "we require a git-ubuntu merge [or debdiff.... ;)]")
16:19 <rbasak> adrien: again not a issue for this application, but it does bother me that the range-diff technique for reviewing package merges isn't widely known, since for complex merges, AFAIK it's the *only* way of properly reviewing them, which suggests that sponsors and peer reviews do not properly review package merges :-/
16:20 <adrien> so, first, the release schedule at https://discourse.ubuntu.com/t/plucky-puffin-release-schedule/36461 ; it has links to the relevant wiki pages and generally speaking, feature freeze means, well, no more new features but we can still upload fixes and should focus on testing and bug fixing
16:21 * tsimonq2 just does local Git magic, or uses the debdiff from LP :) agreed that the defined process should probably be used more widely...
16:21 <adrien> it's also possible to ask for an FFe in case there's a high-importance roadmap entry associated with that, or if the gains are high enough basically (I can't word it shortly well enough, gah)
16:21 <tsimonq2> adrien: I get what you're saying :) if the rewards outweigh the risks?
16:21 <rbasak> adrien: what's the process for requesting an FFe (or alternatively, where is that documented?)
16:22 <adrien> rbasak: I've used range-diff just today, and I know schopin uses it; I think for these it's been done without the tags being pushed since they're not strictly needed for using the command
16:22 <adrien> The process is described at https://wiki.ubuntu.com/FreezeExceptionProcess
16:22 <rbasak> adrien: mostly that's true, but if you don't push the logical tag, the reviewer won't have that set of commits and will be forced to recreate it before using range-diff in the way I mean.
16:22 <schopin> the tags are useful when there has been uploads without rich history.
16:23 <rbasak> Ah, good point - if the previous commits were already broken out and in git-ubuntu then they are there, I guess.
16:23 <rbasak> My experience is tainted by the time when git-ubuntu wasn't so widely used, so that was rare. I guess it's more common now :)
16:23 <adrien> so, the FFe page has that sentence which is better than mine: "A request for an exception to FeatureFreeze should demonstrate that the benefit of new functionality, or the total benefit of a new upstream release which includes it, outweighs the risk of regressions and other potential disruption of the release process. "
16:23 <schopin> Yes, and that's a Good Thing™
16:25 <tsimonq2> adrien: I'm satisfied WRT Feature Freeze, thanks :) how about Beta Freeze?
16:25 <adrien> and back to the various kinds of freeze, for the beta freeze, since we're much closer to the release, uploads need manual approval from the release team
16:25 <adrien> everything should be bug fix at that point
16:26 <adrien> (it's also left to the discretion of the release team so it's possible to not have only bug fixes)
16:26 <tsimonq2> Indeed. That being said, what about Final Freeze? Are more packages frozen then, than in Beta Freeze?
16:26 <adrien> also, there's the kernel feature freeze which is at a different date and that has an impact on packages such as strace
16:27 <schopin> adrien: all uploads require manual approval, really?
16:27 <adrien> schopin: for beta freeze, I think
16:27 <adrien> let me check
16:28 <schopin> Unless my memory fails me (which is not that unlikely), non-seeded packages are auto-accepted.
16:28 <adrien> ah, I see where that's true but not a complete answer; not a situation I found myself in
16:28 <juliank> Complicated
16:29 <tsimonq2> schopin: Historically that's been true, yeah. Not sure if it's changed today given RT team membership changes.
16:29 <rbasak> Not sure if you missed this; sorry for the flood of messages: what's the process for requesting an FFe (or alternatively, where is that documented?)
16:29 <adrien> that's only for the time between beta freeze and beta itself, and after that it's feature freeze again but also https://wiki.ubuntu.com/BetaFreeze is maybe inconsistent for that
16:29 <schopin> rbasak: that was answered
16:29 <rbasak> Ah, yes, sorry.
16:30 <rbasak> *I* missed it :)
16:30 <tsimonq2> > Packages that do not affect images will generally be waved through the queue as time permits.
16:30 <rbasak> Are we done with questions on freezes and exceptions?
16:30 <tsimonq2> I've always read that as "seeded-in-ubuntu check buuuuuut the release team has discretion."
16:30 <adrien> tsimonq2: and post-final is only fixes
16:30 <tsimonq2> rbasak: >< this close :)
16:31 <rbasak> Next question from me: after you upload to the development series, what are your next steps?
16:31 <utkarsh2102> q: have you done any seed changes yet?
16:31 <adrien> utkarsh2102: I don't think I've touched the seeds so far
16:31 <bdrung> (I wanted to ask about seeds as well since it would fit nicely here)
16:32 <adrien> I don't think I had a need for that
16:32 <utkarsh2102> but you've done MIRs, no?
16:32 <rbasak> If you're granted core dev today, what would you do if you were asked to review a seed change tomorrow?
16:32 <tsimonq2> adrien: Right. So in terms of freezes, as mentioned above, Beta Freeze really goes for images and packages that are seeded, *generally* speaking. Final Freeze is for *all* packages in the archive, regardless of seeded status or not. Recently, if it's within a week of release, RT has preferred doing 0-day or verylow-day SRUs instead of including stuff like that last minute. Anyway, I'm happy with
16:33 <tsimonq2> the fact that you erred on the side of caution here, in terms of eligibility I think as long as you're able to find the links and do err on the side of caution, I'm satisfied with this point, thanks. :)
16:33 <tsimonq2> (SRUs within a week *unless* it affects the ability to grab updates post-install. Something like that.)
16:33 <rbasak> Sorry, take your time with the answers. Consider the questions queued up :)
16:33 <tsimonq2> ^^
16:33 * rbasak wonders if we could do this better with a move to Matrix, with threads.
16:34 <utkarsh2102> q: since you've done MIRs, what happens when you promote a package and it's not seeded in the image? will it stay in main? will it not? how can you make it stay in main if it's not to be seeded in any images?
16:34 <adrien> utkarsh2102: that's a good point but I didn't touch the seeds myself, maybe because the MIRs I've done were in answer to someone asking for them (and for the perl one, it was a new dep)
16:36 <adrien> rbasak: so, since I never had the need to do it, I've had limited exposure to their management, mostly by picking up on conversations here and there and that's probably one topic where I'd ask others around
16:36 <adrien> one thing though is that I'd wonder if we really want that change
16:37 <adrien> because seeds will affect every installation and can therefore have a huge impact (plus it should be in main)
16:38 <bdrung> regarding "affect every installation": is every seeded package installed on every system?
16:38 <adrien> tsimonq2: ah, TIL; now I'm wondering why I thought differently (but maybe because I've been working mostly on packages that are seeded, I'll check the numbers)
16:39 <adrien> rbasak: btw, I've heard people have strong opinions about matrix threads
16:41 <rbasak> ack - that's a longer discussion for another time :)
16:41 <adrien> utkarsh2102: so, there's https://ubuntu-archive-team.ubuntu.com/component-mismatches-proposed.html
16:41 <tsimonq2> adrien: seeds> Here's an edge case example (and this has actually happened, recently, with both installers). The installer needs package foo to be installed for X feature to work, for some reason not having that feature breaks the installation, you just did the changes to foo *and* the installer, and you want a select number of flavors to include foo now. (You'll notice there isn't a question
16:41 <tsimonq2> here; I hope I didn't give away bdrung's answer ;))
16:42 <adrien> and I think promotions and demotions are not automated and still need a manual operation but it's basically according to component-mismatches
16:42 <adrien> and if something isn't seeded but in main, it will appear in the report
16:42 <utkarsh2102> but will it stay in main if it's not seeded?
16:42 <utkarsh2102> or does it not?
16:43 <utkarsh2102> and what about a situation where I want a package in main but not seeded in any official image we produce, what then?
16:43 <adrien> I don't have the full answer because I'm not entirely sure because dependencies still need to be satistfied
16:44 <adrien> utkarsh2102: I don't have the answer for that
16:45 <rbasak> I think we need to move on from seeds otherwise we'll be out of time.
16:45 <schopin> that and I'll starve to death, too.
16:45 <adrien> but since the demotion isn't automated AFAIK, until someone does the demotion, it won't happen, but it will still appear in the report
16:46 <adrien> bdrung: there are several seeds and many installation types, as can be seen on https://ubuntu-archive-team.ubuntu.com/seeds/
16:46 * tsimonq2 passes schopin an American donut and agrees, noting that seeds are important but a small portion of *overall* coredev work, I'm satisfied re: seeds
16:46 <adrien> (and its subdirectories for the different seeds)
16:47 <juliank> Most core devs know about the same amount of stuff on seeds I think
16:47 <tsimonq2> adrien: Also https://code.launchpad.net/ubuntu-seeds/+git for your reference :)
16:47 <rbasak> If we're done with seeds: after you upload to the development series, what are your next steps?
16:49 <adrien> so, the upload itself does not mean the work for that upload is over because the package needs to be maybe accepted, built, the binaries may need to be accepted too, then it gets in -proposed and tests need to run and pass and then it can migrate if britney is happy
16:50 <rbasak> OK. So if the uploads gets "stuck in proposed", what's next? How do you determine which of the various reasons it's stuck for?
16:50 <bdrung> someone wanna ask about britney?
16:50 <adrien> where britney's happiness is almost a thesis topic but which includes the overall installability of packages
16:50 <rbasak> Oh, wait
16:51 <rbasak> You did https://ubuntu.dcln.fr/update_excuses.html so there's no point in asking you about that :)
16:51 <juliank> :)
16:51 <schopin> Hah! I was looking for that URL!
16:51 <bdrung> rbasak, you figured it out :D
16:51 <schopin> ALright. Any other question?
16:51 <utkarsh2102> what if no actual reason is showing up on update_excuses
16:51 <utkarsh2102> but it's still stuck?
16:51 <rbasak> What if the excuses page says "valid candidate" but it's still not migrating? Where do you look then? Was this covered by your work already?
16:51 <adrien> yes, I did that; the page is dead because people stole my copper line and I haven't migrated everything to my fiber line (that takes time!)
16:51 <utkarsh2102> where do i look? what do i do?
16:52 <utkarsh2102> rbasak: copy cat :)
16:52 <rbasak> :)
16:52 <tsimonq2> To queue after rbasak is happy, I'm really pleased to see three notes about sponsorship in the "why you're applying" section. Reducing burden on your sponsors, paying back review time you've benefited from, and helping people who seek sponsorship. Could you briefly expand on this, and talk about what kind of standards you'd apply before sponsoring a package?
16:52 <tsimonq2> (I started typing that question at 16:47, whoops :D)
16:53 <utkarsh2102> and it reached here at 22:22, tch tch
16:53 <utkarsh2102> :)
16:53 <adrien> rbasak: try to install packages like the result would be and see if it works and if it doesn't, try to get more details
16:53 <utkarsh2102> where do you get more details?
16:53 <adrien> I tried to do stuff with apt which I think is interesting, there's also u-a-r (is that it?) which does it too and also uses chdist
16:53 <rbasak> Can you point to more documentation on this topic?
16:54 <adrien> then I think it's a lot of poking and see where debugging gets you
16:54 <utkarsh2102> hm, not what we're looking for, i'm afraid but okeydokey
16:54 <rbasak> Could you describe exactly what it is that britney is trying to find, but failing, if it doesn't migrate a package that is a "valid candidate"?
16:55 <adrien> brtiney gives some hints already in the proposed migration page so that's a start
16:55 <rbasak> Sorry - which proposed migration page are you referring to?
16:56 <adrien> (sorry, I jumped steps directly to when that's not enough or britney doesn't state anything)
16:56 <utkarsh2102> :P
16:56 <adrien> https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html
16:56 <adrien> and the one I jumped to being https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt
16:56 <utkarsh2102> so close :)
16:56 <utkarsh2102> we're looking for https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output.txt
16:57 <utkarsh2102> this talks about uninstallability
16:58 <utkarsh2102> https://wiki.ubuntu.com/ProposedMigration/#The_update_output.txt_file_is_completely_unreadable.21
16:58 <utkarsh2102> https://wiki.ubuntu.com/ProposedMigration/#I_still_don.27t_understand.21__The_proposed-migration_scripts_say_that_this_package_is_a_valid_candidate.2C_but_it_still_hasn.27t_gone_into_the_release_pocket. before that :)
16:58 <tsimonq2> > The update_output.txt file is completely unreadable!  That is not a question. ;)
16:58 <tsimonq2> tsk tsk
16:59 <utkarsh2102> heh
16:59 <utkarsh2102> anyway, you had a question from tsimonq2 though
16:59 <adrien> yes, but the notest.txt one has the same information because the issue isn't with tests at that point
16:59 <utkarsh2102> rbasak: anything else from your side?
16:59 <rbasak> I don't think any further questions. I'm still reading.
17:00 <tsimonq2> That was my last question, and it's okay to keep it short and sweet. I'm ready to vote, personally.
17:00 <bdrung> i am ready to vote as well.
17:00 <adrien> tsimonq2: first quick checks, the changelog, making sure the version is correct and won't introduce issues later on (like version number being too high); changelog should also be correct wrt the actual changes
17:01 <adrien> tests should be run
17:01 <tsimonq2> adrien: autopkgtests?
17:01 <adrien> there should be a PPA to show the build; I'll be doing that myself too
17:02 <rbasak> I'm ready to vote.
17:02 <adrien> tsimonq2: yes, autopkgtests
17:02 <schopin> Alright, I'll start the vote.
17:02 <tsimonq2> adrien: Thanks :)
17:02 <adrien> and generally speaking, the more tests the better
17:02 <schopin> #startvote Grand adrien Core Dev rights
17:02 <rbasak> Just #vote I think
17:02 <schopin> #vote Grant adrien Core Dev rights
17:02 <meetingology> Please vote on: Grant adrien Core Dev rights
17:02 <meetingology> Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname')
17:03 <rbasak> +1 I think you're weak on understanding of seeds, but you acknowledged you'd ask around as needed, and I think you understand enough to know when you need to ask. I don't require knowledge of every little thing, just general coverage and to know when to ask, and I think you have that.
17:03 <meetingology> +1 I think you're weak on understanding of seeds, but you acknowledged you'd ask around as needed, and I think you understand enough to know when you need to ask. I don't require knowledge of every little thing, just general coverage and to know when to ask, and I think you have that. received from rbasak
17:03 <tsimonq2> +1 While we have answered a few questions for adrien, I believe he'll err on the side of caution and ask questions where appropriate, and his conduct is consistent with that of an Ubuntu Core Developer. While I'll openly admit, despite my totally positive interactions this is not my most confident +1 ever... that being said, I do believe it's the right call, and we should unblock him in his work.
17:03 <meetingology> +1 While we have answered a few questions for adrien, I believe he'll err on the side of caution and ask questions where appropriate, and his conduct is consistent with that of an Ubuntu Core Developer. While I'll openly admit, despite my totally positive interactions this is not my most confident +1 ever... that being said, I do believe it's the right call, and we should unblock him in his work. received from tsimonq2
17:03 * schopin blames low blood sugar
17:03 <schopin> +1
17:03 <meetingology> +1 received from schopin
17:04 <bdrung> +1 I trust adrien. He has a broad knowledge and knows when to ask. this meeting shows that he can learn more about seed (not the ones for pigeons!).
17:04 <meetingology> +1 I trust adrien. He has a broad knowledge and knows when to ask. this meeting shows that he can learn more about seed (not the ones for pigeons!). received from bdrung
17:04 <utkarsh2102> +1 with whatever has been said. :)
17:04 <meetingology> +1 with whatever has been said. :) received from utkarsh2102
17:04 * rbasak needs to run
17:04 <schopin> #endvote
17:04 <meetingology> Voting ended on: Grant adrien Core Dev rights
17:04 <meetingology> Votes for: 5, Votes against: 0, Abstentions: 0
17:04 <meetingology> Motion carried
17:04 <rbasak> Congrats!
17:04 <rbasak> And thank you for all your work.
17:04 <tsimonq2> adrien: Congratulations!
17:04 <adrien> thanks!
17:04 <juliank> Congrats
17:04 <Skia> adrien: congrats! :-)
17:04 <utkarsh2102> congrats!
17:04 <utkarsh2102> i'm happy to do the announcement and acl changes.
17:05 <schopin> Oh great, I was about to ask for that :)
17:05 <tsimonq2> #action utkarsh2102 to do the needful re: adrien
17:05 * meetingology utkarsh2102 to do the needful re: adrien
17:05 <bdrung> congrats adrien
17:05 <adrien> The discussion speed felt quite intense but also quite fun and also very interesting.
17:05 <tsimonq2> Indeed :)
17:05 <schopin> No AOB for tonight, we're already overtime.
17:05 <schopin> #endmeeting