On Tue, Apr 05, 2005 at 03:57:15PM +0000, Thaddeus H. Black wrote: > On Tue, Apr 05, 2005 at 05:06:11AM -0700, Steve Langasek wrote: > > On Mon, Apr 04, 2005 at 07:48:16PM +0000, Thaddeus H. Black wrote: > > > This mail is somewhat lengthy, and most of you do not > > > need to read it. You want to read this mail if you > > > maintain packages which (as of 2 April) sarge > > > temporarily lacks. These are packages which used to be > > > in sarge and still have hope to join the official sarge > > > release but, for whatever reason (probably RC bugs), are > > > not in sarge at the moment. If you do not have this > > > problem, you can safely skip this mail. > > > On Thursday night, I intend to update debram-data for > > > the last time before the freeze, purging metadata on all > > > binaries not in sarge main (i386) 2 April. > > Wouldn't you want the debram shipping with sarge to be maximally > > useful with packages in etch/sid? > Hm. Perhaps so. For historical reasons peculiar to debram, the matter > had not occurred in quite this light. > Now that you mention it, I can think of no substantial objection to your > suggestion. Because of the kind of thing debram is, one is loath to > disregard a Release Manager's advice in the matter---but even were it > not so, your idea still has merit. not commenting as an RM here, fwiw, just a developer on the sidelines. > Purging is fast and easy, so I can implement your suggestion easily in > either of two ways: > (1) to leave debram-data as it is, purging nothing; or > (2) to purge metadata for packages not presently in sid. > These options contrast against my earlier plan: > (3) to purge metadata for packages not presently in sarge. > Now, some sarge stable users might prefer debram to list only packages > actually available in sarge stable. The debram(1) executable does not > differentiate, and there is no time to make it differentiate now. Any > metadata we decide not to purge, the user is going to see on his screen. Ah, so debram doesn't actually check against the available package list when displaying information? That seems suboptimal, but I guess if this is how it is, it's probably better to not display metadata for a few available packages than to show metadata for a bunch of packages that aren't actually available. > Would you advise option (1) or option (2)? (Or even option 3?) The > same question goes to the Debtags team and other stakeholders. Sans > further feedback, I guess that debram would now take option (2)---but > all the options seem acceptable: we can go any way with this. If you don't have the option of hiding packages that aren't actually available, then I guess option 3 is really the best from a usability standpoint... Cheesr, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature