[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unblock of packages in "could be handled by britney"

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.


<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 
<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 
<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, 
<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 
<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 
<fjp> However, some packages, including klibc, could then be handled 
<fjp> HE: That list does not completely match the first section.
<fjp> jcristau: Depends has a different meaning for udebs than it has for 
<fjp> Yes, that is somewhat broken, but it's the way it was implemented way 
<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 
<fjp> And that a fair number of packages with udebs could then migrate 
<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.

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: