On Thursday 03 April 2008, Philipp Kern wrote: > today members of the Release Team wondered on IRC about when to unblock > udebs in the "could be handled by britney" section of the freeze hints > file while not being in any d-i beta freezes.
For those who did not see the discussion on IRC, here's the log (note that this is a selection, not the full log). It started with a request from maks to unblock mklibs which phil acted on without waiting for an OK from a D-I RM. Cheers, FJP <fjp> maks: Because RMs don't have the knowledge needed to decide udeb unblocks and there's the need to get the udeb syncs done in time. <fjp> We can ease up on this for some packages if my britney proposal would get implemented, but not until that happens. <jcristau> i thought only some udebs needed a d-i ack? at least that's what the comments in ftp-master/testing/hints/freeze suggest... <aba> fjp: AFAIUI, we can unblock packages in the first section always <fjp> aba: No, you cannot. <aba> fjp: since when? <phil> fjp: Then please elaborate why not. <fjp> aba: Since always. <aba> fjp: that's not correct. <fjp> OK, this has been explained before, but apparently needs explaining again. <fjp> aba: It is correct. We only made an exception for the period when there was no Beta release. <fjp> The reasons are: <fjp> - if a udeb migrates without the D-I RM knowing about it, there is a big chance that the udebs will not be synced in time <fjp> - there is no dependency checking for udebs, so that needs to be done manually <fjp> - udebs that are not included in the initrd but loaded later can break the current D-I release if they contain incompatible changes <fjp> That also includes udebs from packages in the first section. <fjp> The reason it says could be handled by Britney assumes that Britney would do depency checking. <fjp> So, approving packages with udebs without doing the dependency checking is broken, even for components in the first section. <HE> So if the Release team handles udeb sync requests and checks dep, we can unblock the packages from the first section without ACKs from you, right? <fjp> That is why we ask you to wait for an ack from D-I RM. <phil> And d-i RMs are doing this dep check manually everytime? Using a tool? <fjp> phil: Generally we just know, based on deeper knowledge of relationships between components, whether or not a migration is safe. <phil> klibc looks selfcontained so there can't be broken deps? <fjp> HE: The first requires FTP-master; dependency checking is a bit more involved that just pure explicitly declared deps. <fjp> phil: Did you check that before you added the hint? <fjp> Please see my proposal for udeb migration handling. It's all in there. <HE> fjp: If it's too complex for a human, I don't see how britney could do it. Or you, for that matter. <phil> fjp: I checked the changes which did not announce an ABI change or something, but well, probably not enough then. <fjp> HE: Don't you think that it's possible D-I RMs know just a bit more about D-I internals than other DDs? <HE> fjp: I believe that, what I don't think is that you are crazy enough to say that the information is not all written down somewhere, but britney would be able to check it <HE> fjp: As long as you point out that a britney change can do it, I assume that manual from by the release team can do as well. <jcristau> fjp: isn't that true for any other package? yet other DDs can check deps. <fjp> HE: See my proposal. I'm not saying that Britney could check it all. <fjp> Even with implememtation in Britney, my proposal still has blocks by default for a lot of components. <HE> Yeah, but we were talking about those udebs you are willing to leave to britney. <fjp> However, some packages, including klibc, could then be handled automaticalyly. <fjp> HE: That list does not completely match the first section. <fjp> jcristau: Depends has a different meaning for udebs than it has for debs. <fjp> Yes, that is somewhat broken, but it's the way it was implemented way back. <fjp> The main point here is that there are complicating factors of which I don't expect everybody to be aware, but that is the main reason behind the request to not migrate packages with udebs without D-I approval. <fjp> And that's generally worked perfectly for the Etch lifetime. <HE> So, to sum it up: You would be willing to let some things done automatically by britney, but don't want the release team to do it manually, because we don't have the information available that would be available to britney. And until that changes, we will need get an ACK from you for every single package at the base of the dependency tree, as those usually provide udebs. Yay. <fjp> HE: That's not completely correct. Please read my proposal. <fjp> http://lists.debian.org/debian-release/2007/05/msg00086.html *fjp really wishes someone would implement that <HE> fjp: I read your proposal, twice actually. Besides being a proposal (and thus, not a solution), it does not point out why the release team isn't able to do something manually that a tool controlled by the release team could do automatically. <fjp> I looked at it, but it's over my head. <fjp> HE: The proposal includes setting of udeb unblock hints by the D-I RM. That's the part I don't think the release team can do. <HE> fjp: It includes a suggestion of that, I was never aware that you want to get d-i completly out of reach of the release team. Interesting to know. <fjp> HE: That's absolutely not what I want. <fjp> That's really nonsense. <fjp> The D-I RMs hints would come before any actions by RMs, not in place of them. <fjp> But for packages that need a D-I RM hint, that would be an additional requirement for migration, but translating that to "completly out of reach of the release team" is complete and utter bullshit. <HE> Ah. So what you are saying is that even if britney would support udebs, manual action from the d-i release team is still needed, so the only change would be that Jeroen wouldn't need to sync udebs manually from time to time? <fjp> And that a fair number of packages with udebs could then migrate automatically. <HE> ... given that a d-i RM has at some point allowed it? <fjp> And also an end to recurring discussions like this. <HE> Well, I would prefer the d-i team to create a technical solution that doesn't need human supervision to avoid breakage at any time, but, heh, that's probably just me. <fjp> Yes, because they would have a permanent "allow-udeb" hint. <fjp> Sure, I'd like that as well. But that needs structural changes in udeb control files. <fjp> Let's do this in steps. <fjp> From my PoV having that proposal implemented is way better then the current situation. <Rhonda> Sounds like a d-i maintained list that additional to an release team maintained list is checked and if it's in both, it moves? <fjp> Essentially, yes. The udeb hints and checks are incremental to regular hints and checks.
signature.asc
Description: This is a digitally signed message part.
