As reaction to approved MiniDebugInfo feature, we agreed on KDE SIG
meeting that we would have to break CD size limit (and the breaking
of CD size image was used as argument to accept this feature).

We agreed that 800 MiB is achievable target:
- all spins will still fit Multi Desktop Live DVD
- there's still space available for overlay for USB disks
- you can still get 800 MiB CD-Rs (may hit HW constraints...)

Other possibility is to go directly to 1 GiB but we are not sure
there's advantage (at least not now).

Contingency plan - at least for one release we'd like to have a 
700 MiB KS (with more compromises).

So we'd like to hear from rel-engs, QA etc. what's theirs position
here.

R.

----- Original Message -----
> Kevin Fenzi wrote:
> > 18:23:37 <nirik> #topic ticket 868 F18 Feature: MiniDebugInfo -
> > https://fedoraproject.org/wiki/Features/MiniDebugInfo
> > 18:23:37 <nirik> .fesco 868
> > 18:23:42 <zodbot> nirik: #868 (F18 Feature: MiniDebugInfo -
> > https://fedoraproject.org/wiki/Features/MiniDebugInfo) – FESCo -
> > https://fedorahosted.org/fesco/ticket/868
> > 18:24:03 <nirik> mmaslano was 0 in ticket.
> > 18:24:24 <nirik> I'm -1.
> 
> First of all, thank you Kevin for having been the only one stepping
> up
> against this nonsense!
> 
> > 18:24:28 <limburgher> Seemed. . .mildly contentious. . .
> > 18:24:34 <mitr> I think the only technical objection was that spins
> > won't
> > fit on a CD,
> 
> The "only" technical objection which is a blocker as far as we're
> concerned.
> Image sizes are even a release blocker! Nobody decided that spins
> should NOT
> be CD-sized.
> 
> There was also the additional objection that the feature brings no
> practical
> gain, because -debuginfo is already available and the Retrace Server
> is
> available. Later in the discussion, you also pointed out that ABRT
> probably
> won't even use this information! So why ship it? Bloat just for the
> sake of
> bloat?
> 
> > but when repeatedly asked nobody came up with an example
> > user/ambassador
> > saying that CDs are needed
> 
> Huh? Examples have been given in the mailing list threads. There's
> also the
> constraint that all the spins in both 32-bit and 64-bit editions need
> to fit
> on one DVD (the Multi DVD), which very much does matter to the
> ambassadors.
> 
> > 18:24:54 <mezcalero> nirik: out of curiosity, why do you say -1?
> > 18:25:17 <notting> i am +1. obviously would need to be coordinated
> > with
> > any dmz-related rebuilding
> > 18:25:21 * pjones is also +1
> > 18:25:33 <nirik> I don't think the extra size is worth the gain. I
> > think
> > we can/should work on making abrt better.
> 
> Right.
> 
> > 18:25:34 <hughsie> i don't know if i should comment, but from my
> > role as
> > an upstream maintainer, this would be really useful for real life
> > debugging from end users...
> 
> That's what -debuginfo packages are for!
> 
> > 18:25:44 <limburgher> mitr: Would dwarf compression help that?
> > 18:25:48 <jwb> i'm marginally +1
> > 18:25:55 <pjones> limburgher: no - different set of fields
> 
> Even if it were affecting the mini-debuginfo fields (it doesn't),
> compression wouldn't help at all because the live images are already
> compressed. Even special-case compression has at best a very small
> effect
> after xz is run on it.
> 
> > 18:25:56 <mitr> limburgher: jakub said above that it is orthogonal
> > 18:25:57 <t8m> as long as it does not replace full backtraces
> > reported in
> > ABRT I'm ok with it so marginally +1
> > 18:26:11 <mitr> AFAICS this "only" benefits developers and reading
> > crashes
> > in unexpected components, but given Fedora's target arudence, +21
> > 18:26:14 <mitr> +1 that is
> > 18:26:16 <limburgher> mitr, pjones:  Missed that, thanks.
> > 18:26:22 <limburgher> Ok.  +1
> > 18:26:24 <mjg59> I lean +1
> > 18:26:43 <mitr> nirik: My best guess is that abrt will just ignore
> > this.
> 
> So just useless bloat.
> 
> > 18:26:57 <nirik> #agreed Feature is approved. (+7/-1/0)
> > 18:27:01 <_jakub_> I don't see what minidebuginfo gives us as
> > advantage
> > for bugreporting, in theory all you need is addresses (relative to
> > start
> > of DSOs) and their build-ids, everything can be recomputed from
> > that
> 
> So there, THE expert on the domain tells you the bloat is totally
> useless,
> but it's too late, you already rushed out a vote of a bunch of
> "marginal"
> +1s. :-/
> 
> > 18:27:03 <limburgher> I wish spins could stay on CDs, but then I
> > still
> > want CD and floppy install media.  <stares wistfully into the past>
> 
> Floppies are clearly too small. CDs are not. They'd fit all we need
> if it
> weren't for the completely useless bloat added by "features" such as
> this.
> 
> 
> I also object to the fact that the feature owners have spun the
> feature
> proposal in a deliberately misleading way:
> * "increase quality of bug reports"? – ABRT won't even use this!
> * "allow easier support for profiling and user space tracing"? – Why
> wouldn't one just install -debuginfo for those tasks? It's not what a
> user
> needs to do every day.
> * misleading percentages – see Talk page
> * Also note that for shared objects, we already HAVE symbols for the
> exported functions (for free!), which is often enough!
> 
>         Kevin Kofler
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to