[pkg-boost-devel] Upload of Boost 1.38

[Steve M. Robbins]

Hello Adeodato et al.,

On Tue, Mar 10, 2009 at 09:31:39PM +0100, Adeodato Sim?? wrote:

> I have a couple concerns with your proposal, though. Let me start the
> first of these with a question: given a new version of boost, eg. 1.38,
> how likely is it that a package will rebuild just fine against this new
> version? In other words, what percentage of packages are expected to
> rebuild without changes?

That's a great question.  The answer is "it depends".  Boost contains
a large number of libraries, some of which (e.g. smart_ptr) are
basically stable and haven't changed in years, while others are more
of a work-in-progress and undergo API changes.  So it depends on what
part of boost a given package is using.

As another data point: before we (the Debian Boost packaging team)
adopted the strategy of multiple versions, I asked this question to
the Boost list:

	In practice is there a large amount of work adapting existing
	client code to a new release? I'm asking in order to gauge
	whether it is useful for a linux distribution (Debian) to keep
	multiple versions of Boost available simultaneously;
	e.g. 1.34.1 and 1.35. Currently Debian provides only the
	latest version of Boost.

  c.f. http://lists.boost.org/Archives/boost/2008/03/135212.php

That elicited 3 responses from library users:

  1. Not if you can recompile the client code.  Usually.
  2. I have found that modifications, most minors, in user code are
     very common when switching boost version.
  3. I think Debian (and other distributions) must keep multiple
     versions available.

I'll count that as 2.5/3 responders suggesting that some level of
source code modification is common when switching to a new Boost
release.


> If [no source changes are necessary for most boost-using packages], 
> the need for sourceful uploads should
> be minimized. For that, I???m going to recommend that you adopt for boost
> the common idiom in Debian for these situations, a "boost-defaults"
> source package.

  [...]

> So, say we???d have all of the archive build-depending on the unversioned
> names and built against boost 1.38, and then boost 1.39 comes along and
> gets uploaded as boost1.39. After which, boost-defaults gets uploaded??
> to point the unversioned names to the 1.39 versions, and then,a Bin-NMU
> campaign can begin.
> 
> In the best scenario, no package fails to build against boost 1.39, and
> boost 1.38 can be removed right away. Of course, we all know that???s not
> going to happen: there are failures, for which bugs at RC severity will
> be filed. Now, each of these bugs is very easily fixable by just going
> back and build-depending on libboost-date-time1.38-dev, etc., instead of
> the unversioned names. Or, with a bit of poking, maybe porting is
> trivial, or a new upstream version exists, etc.
> 
> Note that, of course, we???re trading severity:important bugs (???Please
> update your package to boost1.39???) for severity:serious ones (???Your
> package FTBFSes with the boost in unstable???), which is a trade-off to
> consider very carefully. I think it???s worth it if the number of RC bugs
> is going to be small. But let me tell you, if we go with the
> severity:important bugs, I???m pretty sure you (the boost maintainers)
> will have to do a lot of NMUing to meet your ???only 2 boost versions in
> the archive??? objective.
> 
> Additionally, we can just be smart and not bump boost-defaults to point
> at the new version immediately after it???s uploaded to unstable. You
> could (or ask Lucas to) rebuild all reverse-dependencies with a local
> version of the new boost-defaults, and see how many fail, and agree with
> us (the Release Team) what to do next. (I say agree with us, because
> depending on the stage of the development cycle, and/or the state of
> unstable, it may be wiser to do one thing or the other.)
> 
> So, please let me know what you think of this recommendation, particularly
> if you can think of any reasons it would be less appropriate than your
> initial proposal.

I think it is a great adjunct to our initial proposal.  I have had a
couple of Debian package maintainers ask to keep the unversioned -devs
precisely because they know that their package uses only the stable
core of Boost (e.g. smart_ptr).

Let me now ask you how transitions from sid to testing will work in
this scenario.  

One of the biggest issues with our previous strategy of having a
single boost source package is that boost (a) uses other complex
libraries like ICU and now MPI, and (b) complex libraries like KDE use
boost.  So a new version of boost in sid often got entangled in
transitions with other large packages like ICU, KDE, Qt, and the like,
leading to a long delay before reaching testing.

Naively, it seems like the same issue will reappear with the
boost-defaults package.  Let's say we upload boost-defaults with a
change from 1.38 to 1.39 and some packages fail to build against the
new version.  If I understand you right, the *build-deps* get a FTBFS
bug.  Wouldn't one such bug be enough to keep boost-defaults from
transitioning to testing?  If so, wouldn't that be enough to keep
boost1.39 from transitioning to testing?

You also propose a strategy of not updating boost-defaults
immediately, but investigate locally the reverse deps to see how many
fail to build.  That sounds like a mechanism where we could upload
boost1.39 and let it transition to testing while fixing all reverse
deps that fail to build.  Then update boost-defaults only after all
rdeps are fixed.  Is this a reasonable proposal, or would it be
frowned upon?  Note that one of our (unstated) goals is to get a new
boost into debian testing without undue delay; i.e. without getting
entagled in rdeps build problems.

What would the release team recommend doing in the general case?



> My second concern is related to the objective of keeping only two boost
> versions in the archive (well, in testing/unstable). As I said, this is
> a very desirable objective, and I???d really appreciate if we would not
> let it slip. When thinking about reasons why it could slip, it
> immediately comes to mind the situation where you have, say, boost 1.37
> and boost 1.38 in the archive, with most packages using 1.38 but a
> handful still at 1.37. Then boost 1.39 gets released and... what do you
> do? The interesting point is that those packages at 1.37 were not
> updated to 1.38 for a reason, most likely that they required porting and
> upstream was not ready. What if that???s still the case?

I agree that this is a concern.  To add to it, note that Boost
adopted, about a year ago, a policy of quarterly releases and they
have maintained that schedule in 2008.  Boost 1.39 is due out on May 1.
Keeping to just 2 Boost releases in Debian will be a challenge
indeed.  How do you feel about 3 or 4 releases (a year's worth)?


> Here, we mostly need your expertise in the area to determine how
> feasible it would be to just do the work of porting those apps to 1.38
> or even better 1.39, and if you think it is acceptable for you not
> uploading (to follow with our example) 1.39 to unstable until all 1.37
> applications have patches porting them to either 1.38 or (preferably)
> 1.39, and if you???re volunteering to do the porting job, or help the
> maintainers do it themselves with a bit of help.

I would suggest that the restriction to 2 versions of Boost would be a
goal for Debian/stable rather than for sid.  So in the scenario at
hand, I'd upload 1.39 to sid and encourage the packages using 1.37 to
port to 1.39 directly, skipping 1.38.  I don't know how to do that
without providing 1.39 in sid for them.  If you want to be strict
about 2 versions in sid, I guess you could remove 1.37 immediately
after the 1.39 upload and really cause them FTBFS.  I wouldn't choose
the strict policy myself.

As to the question of who will do the porting work, I'll be frank: it
won't be me.  I'll help out where I can, but I have a limited time for
Debian each week and am already overstretched.  I won't speak for the
rest of the Boost team, except to note that the Changelog will show
that for the past 7 years there has been only one active maintainer at
a time, alternating between Domenico Andreoli and myself.  There's
not a lot of spare cycles here; help is more than welcomed!  :-)

I'm open to release team suggestions on how to keep boost to a
reasonable number of versions, and what that reasonable number is.

Clearly, the strategies will depend on how much breakage is
encountered in a typical Boost relase.  As indicated, I don't have a
good handle on this.  I think that your proposal of boost-defaults --
especially the strategy of locally trying to build rdeps -- will help
to answer this question in the context of Debian packages.  So that
seems to me to be a good way forward.

Cheers, and thanks for engaging on this,
-Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-boost-devel/attachments/20090311/281d66c4/attachment.pgp