On Thu, May 24, 2012 at 3:34 PM, Alexander Larsson <alexl@xxxxxxxxxx> wrote:
> I don't think there has to be a specific "problem". In fact, I think
> Fedora shouldn't really care what *my* problem is. What is interesting
> is: I have this feature; It has a certain cost (increase in size) and it
> gives certain features. Is the price worth the features it gives?
It's only this simple if you are adding a new package.
Otherwise, there are two more questions:
- Is Fedora the right place for the feature?
- You contribute the initial code; do the people who would end up
maintaining it (if it is someone else than you) accept that code and
agree to maintain it?
For minidebuginfo, it is a "Fedora" decision whether to include
minidebuginfo in built RPMs - but the inclusion of gdb support is,
ideally, up to gdb upstream, or alternatively, up to gdb's package
maintainers (in this case, Jan and Sergio).
It's not infrequent that a feature happens in Fedora first and is
integrated upstream later - but it's not quite the preferred path.
Fairly frequently FESCo or FPC agrees to a feature and makes it
effectively required for all packages, even if some package
maintainers disagree (ideally after gathering input from interested
package maintainers first) - but that should IMHO be the case
primarily for system-wide features where individual agreement with all
affected parties is infeasible.
So, where to go from here? For the gdb change, I think the ideal case
would be to push the gdb support upstream (I have no idea what
upstream thinks, though), second best is to convince Jan and Sergio.
Only a third best is asking FESCo to overrule the gdb package
maintainers.
OTOH, FESCo will probably need to vote on the RPM packaging change in
any case, so it would be possible to start with this as well - with
the caveat that opposition from gdb package maintainers is an
additional risk for the feature and its acceptance.
My personal opinion is that this feature is net positive, but not
compelling enough to overrule the gdb maintainers and ask them to
maintain a Fedora-specific patch they don't like; of course, others on
FESCo may, and some probably do, disagree.
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
