Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
--- Comment #41 from Toshio Ernie Kuratomi <a.badger(a)gmail.com> 2009-06-09 19:55:39
(In reply to comment #38)
Toshio, I totally understand your points. We are well aware of all of
disadvantages of bundling/forking that you mentioned, but given our
circumstances we decided that bundling/forking Boost is the best solution,
despite all the aforementioned disadvantages. We made this decision a year ago,
and to date we still think that it's the right decision.
Bundling may be the right decision for an upstream development shop. However,
it is definitely not the right decision for software that is shipped in many
distributions or for the conscientious system administrators. Bundling shifts
the cost of forking so that developers bear less up front costs but
distributions and system administrators bear more costs later on. In the case
of embargoed security fixes the cost is paid when there is time pressure to get
a fix created before a certain deadline is reached. In the case of bug-fixes
and enhancements (features, performance), the cost penalty is less urgent but
still occurs in the form of duplicate bugs, analysis, and debugging against the
bundled version of the library when that work has already gone into the system
library and resolved there via a patch or upgrade.
Not only is the cost shifted around but the benefits are decreased when the
forked library is bundled instead of released separately. If the changes that
prompt you to bundle the library are useful for you, why won't they be useful
for others as well? If they're useful for others, then bundling the library
forces them to reinvent the same types of changes you've made instead of
working with you to get their make a better product overall.
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.