Full log can be found at http://tiber.tauware.de/~sistpoty/motuminutes/motu_minutes_2006_01_12.log
1) Use of /usr/share/common-licenses/GPL vs /usr/share/common-licenses/GPL-2 for GPLed apps packages. (raphink)
Reference in Policy : http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
2) TODOs: (sistpoty)
http://people.ubuntu.com/~doko/libstdc++5-deps.txt - Packages still depending on libstdc++5
http://people.ubuntu.com/~doko/libstdc++-allocator-change.txt - packages not yet rebuilt for libstc++ allocator change
3) UVF (sistpoty)
- extra time for universe?
- how to handle packages on revu?
4) What's next todo? (sistpoty)
- unmet dependencies
- bug triage
- packages, that ftbfs (who will run an automated test ? when ?)
5) Reorganization of MOTU-related Launchpad teams. See MOTUMeetingTeamReorg (lucas)
6) Code of conduct for REVU-uploaders : Currently, a lot of packages are uploaded to Ubuntu through REVU. What will happen to them in a year ? Will the first REVU-uploader still has to take care of them ? We don't want a universe filled with unmaintained packages. + Policy regarding unmaintained and useless packages which are only in Ubuntu. Should we remove them ? What's the procedure ?
7) Collaborative maintenance on tiber via svn or other means
8) Brainstorming/Ideas how to organize divergence in our universe
- Stefan Potyra (sistpoty)
- Daniel Holbach (dholbach)
- Stephan Hermann (\sh)
- Daniel Chen (crimsun)
- Yann Rouillard (chninkel)
- Raphael Pinson (raphink)
Jordan Mantha (LaserJock)
- Jani Monoses (janimo)
- Lucas Duailibe (lucasd)
- Jonathan Ridell (Ridell)
- Charles Short (zul)
- Oliver Gravert (ogra_ibook)
- Reinhard Tartler (siretart)
- Tolleg Fog Heen, but not really present (Mithrandir)
1) raphink wanted to know, whether packages that are GPL-2 should refer to /usr/share/common-licenses/GPL-2 instead of the link /usr/share/common-licenses/GPL, which points to the latest version of the gpl. This might lead to some trouble once GPL-3 is out for packages which don't state the "or any later version" term. \sh pointed out, that there are two licensing issues involved: The license of the packaged software and the work done by the maintainer. After a short discussions, common agreement was that this issue should be adressed in front of TB.
2) sistpoty mentioned two outstanding todo-points: packages still depending on libstdc++5 and packages that didn't get rebuilt for the libstdc++ allocator change. doko prepared two lists of packages which still depended on libstdc++5 and which didn't get rebuilt for the libstdc++ allocator change. These packages were already uploaded to be rebuilt, but FTBFS'd. siretart said, that the libstdc++5 depending packages might be the result of gcc-transition with some of these packages not build-depending on a particular gcc-version. sistpoty stated, that we need to build these packages at least with gcc-3.4. raphing wanted to know, what should be done with these packages: We should try to make them build again, either fix the issues or try new upstream versions. \sh pointed out, that some weren't properly maintained any longer; dholbach stated, that for some upstream stopped working as well. In a small side-discussion, it was asked what exactly will be frozen on UVF. [editors note: dholbach made that clear in a mail to ubuntu-motu, so I will skip that part]. Later during the meeting, doko stated, that his lists are regenerated on demand.
3) UVF and packages on revu There was some discussion how to handle UVF-exceptions. [editor's note: I will skip this part. See https://lists.ubuntu.com/archives/ubuntu-motu/2006-January/000177.html]. The item packages on revu was deferred as well, since we have time until FeatureFreeze to get these in.
4) What's next todo? \sh summarized our priorities quite good: "prio 1) bugs, prio 2) unmet deps prio 3) poke buildd when it's necessary to rebuild universe?". siretart pointed out, that 3) should be done ASAP, since it doesn't need direct human interaction. sistpoty pointed out, that reviewing packages on revu should also get a high priority. dholbach stated, that a review day might get many new packages reviewed. It was shortly discussed to have some automation for unmet dependency checking.
5) lucas made a proposal to reorganize motu-teams of LP, to make it easier to understand the team structure: https://wiki.ubuntu.com/MOTUMeetingTeamReorg Unfortunately no other MOTU seemed to have reviewed his proposal properly, so the discussion about this topic was a little bit confusing. lucas finally made the proposal to remove relationships between team, which nobody objected to.
6) lucas stated that packages gone through revu might not be proper maintained, once the person who uploaded a package to revu which was accepted ceased to work on it any longer. He pointed out, that there might be security related problems with these packages. Almost everyone held the opinion, that it is better to have possibly unmaintained packages than to drop those. Apart from that, it's MOTU work to fix these packages. ogra_ibook pointed out, that it was sabdfl's declared target to have everything in.
7) siretart proposed to maintain ubuntu specific packages via svn on tiber. The goal of the proposal was to have a central place where MOTU's and MOTU hopefuls can work on packages. There was a short discussion between the usage of svn or bzr. It was also mentioned, that buxy had setup svn on alioth.debian.org to handle collaborative maintenance, including work from MOTU's. However the common feeling was, that cooperative work that can be done between debian and ubuntu should not be discussed at a motu-meeting. Generelly the present MOTU's didn't express a need for svn on tiber.
8) siretart wanted to gather ideas how to handle the divergence between debian and ubuntu siretart noted, lucas' rocking MultiDistriTools which has a note for individual packages that can be edited via the wiki. siretart proposed to write a web-interface that is able to categorize the type of difference between debian and ubuntu on a per-package basis. An agreement was made, that this webtool (with some mode of authentication) would be our tool of choice.