Jeff Licquia (LF), Mats Wichmann (Intel), Stew Benedict (LF), Darren Davis (Novell)
Jeff: just to let people what's going on, 4.1 release announcement went out. At some point we'll need to fork off the 4.1 branches in bzr
Jeff: we expect any distro that's 4.0 compliant will probably be 4.1 compliant with the possible exception of alsa
Jeff: Updated buildbot today to a newer release, now that we're not trying to do production builds at the moment
Jeff: Doing some work on the website. May be doing some distribution upgrades on the build machines. Possibly move the x86, x86_64 VMs from opensuse to sles11
Jeff: Any questions on recent activities?
Mats: Doing maintenance. What are we going to do with the version independent packages rollup bug?
Jeff: It doesn't really matter either way, as I understand
Jeff: Lets moved the closed bugs to the 4.1 rollup
Jeff: On 4.2, we don't have anything coming down from above as something we *must* do for the next release. We have several requests for things that we can work out
Mats: So, should we do 4.2 or possibly a 5.0?
Jeff: If we wanted to do something where we broke compatibilty, we might consider a 5.0. Like some of the drops (qt3, pax, sendmail)
Jeff: For qt3, if we dropped it, paradoxically, we'd still be compatible with 3.0, but not 3.1->4.1
Jeff: So if we drop qt3, does that justify a 5.0 version? Or if we have things to deprecate?
Darren: What's the policy the dictates what constitutes a minor vs major version bump?
Mats: Don't ask. We had written one, then broke from it shortly afterward
Jeff: I think we've basically followed it
Darren: For deprecations, I'm more concerned
Darren: Aren't you targeting what the major enterprise distributions are doing?
Mats: We are, but if one of the several wants to break, then we have to decide what to do
Robert: Well, we know qt3 is in the current enterprise distributions, and we're in line with our deprecation policy, then we should be OK
Robert: We also have to think about how long it might take us to get to 4.2
Mats: Right, I added an item to the tracker about the timetable, and then we need to load distro data into the database so we can look at where we're at
Mats: Keep in mind that taking it out, won't impact a distribution that chooses to keep it
Mats: Would we be willing to say 1 year from now as a reasonable target, absent of information that might impact that?
Jeff: That sounds reasonable
Robert: I'm happy to go to 5.0 if we want drop Qt3
some discussion gtk2 vs 3, missed all the details, similar situation similar to Qt3/4
Robert: Keep in mind that to follow our deprecation policy we need to plan ahead to deprecate at the right time
Jeff: To sum up. Removal of Qt3 is an important thing to decide on, and if we go to 5.0, it would be good to think about other things to deprecate, like gtk2 and possibly python2
Darren: I'd consider that premature (python)
Mats: Does raise the question of whether such things (gtk3, python3) shouldn't go into the trial use
Jeff: Want to talk about dbus. It's becoming a core part of a Linux system. Seems that it's prime for inclusion. Other things we're interested in, like accessibility, depend on dbus. Any opinions?
Robert: systemd requires dbus
Jeff: Which brings up another potential issue. Situation with init. 3 different systems in use: systemd, upstart, sysv. Lowest comment denominator is the LSB init script. Although I've heard noise from the upstart and systemd folks that they want to deprecated old-style init-scripts. Is there a common denominator we can include in LSB?
Jeff: We don't care whether it's upstart or systemd, as long as ISVs can write an init script that will work on both
Mats: We don't care about the implementation. The purpose is for someone who wants to write an app, and how they install themselves into the system to be started/stopped. But more and more, from the desktop and down, people are being encouraged to start things on demand, per user. We're completely silent on that model. Do we need to say anything about that situation?
Jeff: Isn't start on demand stuff driven by dbus?
Robert: If it's xdg related, we just added that
Mats: We didn't include that part
Robert: Problem is on a server, is it really there? Now we're into the difference between a desktop system or server
Jeff: Dbus should be able to control system or user level autostart demand
Robert: xdg-autostart is on a base SLES11 system, I imagine RHEL has it too, so it meets that requirement
End Of Call