Re: Upload of Boost 1.38
Hey...
First things first:
> I realize the release team is one of the busiest in Debian, but I was
> hoping not to have to wait another 2 weeks for a response. Carrying a
> conversation at that speed is quite dispiriting. :-)
Yes, I realize that, and I’m verry sorry about it. I’m expecting things
will improve soon in that regard.
> If there's something for us Boost packagers to do in order
> that Boost 1.38 be accepted into Debian, I'd really like to
> know about it.
You can upload the “boost1.38” source package any time you want (which I
guess will be as soon as possible, which is good, since if where’re
going to do migration work, better do it against the latest version, so
that it’ll last more).
So, please upload boost1.38 to unstable at your earliest convenience,
with versioned package names for libraries and -dev packages just like
eg. boost1.37 has.
Once boost1.38 is built in all architectures and migrated to testing, we
can proceed with the boost-defaults plans, see below about this.
---
Now, to answer to your mail from last week, whose response I’ve had
half-ready for some time now...
> 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?
No, boost1.39 (and, in fact, boost-defaults) would be able to migrate to
testing on their own. Of course we’d have to keep an eye that packages
remaind buildable on testing, but I think that’s manageable on our side.
Basically, painful migrations happen when a source package *drops*
binary packages in order to introduce new ones. That is not the case
here, so it’s not a problem.
> 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.
As explained above, boost1.39 would be able to quickly migrate to
testing.
> > 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)?
I’d say let’s keep the “2 versions in each suite” objetcive as a goal,
and make concessions later. Inevitable, sid and possibly testing is
going to see more than two versions when new upstream releases happen,
but that should be ideally temporary. If a migration is particularly
tricky, we can make exceptions, okay?
> > 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.
Right. As said above, more than two versions will be necessary when
introducing a new one. And since this is each three months... heh.
> 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.
Indeed, the ability to rebuild against a new Boost without source
changes is the critical component of all this. This not only means
API-wise, but (I guess) about packages using appropriate compiler/linker
calls so that by that build-depending on unversioned package names,
they’ll get linked against that version, without it being hard-coded in
their build scripts.
I suggest that we get started by introducing boost1.38 in unstable, and
once it has migrated to testing, start the migration work. This means:
* an initial upload of boost-defaults providing versionless -dev
package names pointing at the 1.38 packages
* a mass bug filing for packages build-depending on versioned packages
to build-depend on the un-versioned ones instead
* an automatic rebuild of those packages already build-depending on
the un-versioned ones (from Boost 1.34), and file bugs for those
that fail
I’m foreseeing this won’t be a cup of tea, but it’s something that has
to be done just once. With a bit of luck, we’ll get rid of at least
boost 1.34 and 1.35, and ideally 1.37 as well.
Then, when Boost 1.39 comes along, please contact us again, and we’ll
figure out how to proceed.
Oh, another option I just thought of, is updating boost-defaults only
one out of two times. It may even the case that it was you who mentioned
this already. But this has the disadvantage that package maintainers
needing eg. 1.39 features will need to switch to build-dependencies with
versioned package names, which is not ideal. We’ll have to think about
this a bit more.
Thoughts?
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
Reply to: