![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Conference invitation
I've got an invitation to the Open Source World Conference in Málaga, Spain for mid-February, to take part in a workgroup on Debian-based distributions and some related meetings, and the Junta de Andalucía is paying for my travel and accommodation. Cool! I was almost going to turn down the invitation on the grounds of lack of time until I noticed that it was paid-for (not something I expected at all - it's the first time that's happened to me), at which point I realized I really couldn't say no. Spain's weather stands a good chance of being better than here, and my only visit to Spain until now was to Mallorca.
Now I need to think of some sensible things to say about my ideas for the Debian release process. I've never been terribly much in favour of the "release base system and periphery separately" idea, although I know it's popular and it was mentioned in the invitation; I'll have to crystallize my thoughts on that a bit more and come up with counter-proposals. The core of my objection is that, from experience working on the testing distribution, I don't think our dependency structure is well-suited to running separate base and periphery release processes; every time we wanted to upgrade something like perl or python in base we'd effectively have to go through a release process about as painful as our current one to get all the reverse dependencies consistent again. To some extent, FreeBSD has this problem: it's apparently very difficult to upgrade the version of perl in their base system.
I really do think that the basic way to solve our release problems is extremely strict release engineering, with tighter controls on upgrades of libraries fundamental to subsystems and swift NMUing of packages depending on those libraries that are lagging. We've been getting better about this recently, but there are still major subsystems (naming no KDEs) that persistently lag behind for one reason or another. (As an aside, I think part of KDE's problem is that its source packages are so huge and scary and monolithic that an NMU is a major deal, whereas GNOME's more fine-grained structure lends itself to smaller-scale work on one problem at a time, at which Debian's maintenance structure generally does a better job.) However, I suspect that this answer won't come across terribly well at a conference, nor is it necessarily all that useful in the short-to-medium-term for augmented distributions like GuadaLinEx.
What we really need to do at this conference is to find a good way for third parties to hook into or branch some of our more interesting archive maintenance tools, like testing, and use them to construct their own augmented systems. Doing this without significant intervention by testing experts might be a tricky proposition, and that's what I need to think about over the next few weeks.
Now I need to think of some sensible things to say about my ideas for the Debian release process. I've never been terribly much in favour of the "release base system and periphery separately" idea, although I know it's popular and it was mentioned in the invitation; I'll have to crystallize my thoughts on that a bit more and come up with counter-proposals. The core of my objection is that, from experience working on the testing distribution, I don't think our dependency structure is well-suited to running separate base and periphery release processes; every time we wanted to upgrade something like perl or python in base we'd effectively have to go through a release process about as painful as our current one to get all the reverse dependencies consistent again. To some extent, FreeBSD has this problem: it's apparently very difficult to upgrade the version of perl in their base system.
I really do think that the basic way to solve our release problems is extremely strict release engineering, with tighter controls on upgrades of libraries fundamental to subsystems and swift NMUing of packages depending on those libraries that are lagging. We've been getting better about this recently, but there are still major subsystems (naming no KDEs) that persistently lag behind for one reason or another. (As an aside, I think part of KDE's problem is that its source packages are so huge and scary and monolithic that an NMU is a major deal, whereas GNOME's more fine-grained structure lends itself to smaller-scale work on one problem at a time, at which Debian's maintenance structure generally does a better job.) However, I suspect that this answer won't come across terribly well at a conference, nor is it necessarily all that useful in the short-to-medium-term for augmented distributions like GuadaLinEx.
What we really need to do at this conference is to find a good way for third parties to hook into or branch some of our more interesting archive maintenance tools, like testing, and use them to construct their own augmented systems. Doing this without significant intervention by testing experts might be a tricky proposition, and that's what I need to think about over the next few weeks.
no subject
Also, I really think you should be able to build everything on stable, but YMMV
no subject
Doing this without significant
intervention by testing experts might be a tricky proposition
why would you have to?
no subject
Ooh! Shiny! :-)
no subject