Re: Future of MOTU
On Thu, Mar 25, 2010 at 9:04 AM, Stephan Hermann s...@sourcecode.de wrote: Moins, On Thu, 25 Mar 2010 06:33:45 +0100 Morten Kjeldgaard m...@bioxray.dk wrote: On 23/03/2010, at 22.32, Benjamin Drung wrote: How many people working on that task and how many Ubuntu packages needs to be ported to Debian? Can we rely on the folks who port Ubuntu packages back into Debian or is this more only a wish? Porting is not the problem, it's getting the package sponsored in Debian. I think it's not a problem of sponsoring...many MOTUs are as well DDs and if this is not the case, we could ask for sponsorship from pitti, doko or whoever. This is really not the problem. REVU is a nice tool, but the real problem is, then when it comes to updates, noone is back on that. Pushing software into ubuntu is not a difficult problem. But who takes care about it afterwards? MOTUs/Ubuntu developers who are pushing self made packages taking care about them afterwards, but drive by contributors don't. And what is a package worth who nobody cares about? Regards, \sh -- | Stephan '\sh' Hermann| OSS Dev / SysAdmin | | JID: s...@linux-server.org | http://www.sourcecode.de/ | | GPG ID: 0xC098EFA8 | http://leonov.tv/ | | FP: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 | I have run my own (K)Ubuntu repository for four years so your stereotype must not be completely true. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
Moins, On Thu, 25 Mar 2010 12:15:45 -0600 Brian J Mingus brian.min...@colorado.edu wrote: I have run my own (K)Ubuntu repository for four years so your stereotype must not be completely true. Oh well, this is really...the usual way of doing things. I#m working with software stacks, which aren't inside Debian, Ubuntu, RedHat or OpenSuSE. I'm maintaining repositories with those software for months and years. That's a normal thing. This comes with someones job. Not all software will be pushed into Ubuntu or Debian or whatever distro you use. Maintaining repositories outside the distro landscape is really not the problem. The problem are software packages, where someone wants it in Ubuntu or Debian or whatever distro someone uses. This software package needs to be well maintained and updated/upgraded over time. And this is exactly the problem. A software packager who maintains this package can apply as well for Ubuntu Developer or Debian Developer or Fedora Maintainer or OpenSuSE developer if he or she is ready for that. This implies normally that the newly approved developer will take care about the self made package and about other software packages we have in universe and multiverse. But someone who just wants his or her special software pushed to ubuntu is normally not the type of person who supports it after its pushed to ubuntu. And those packages are rotting in our archives, and after some time, when it doesn't build anymore, we need to find a solution or we remove it from the archive. This is more workload for Ubuntu Developers. If you take care about your packages, you could as well apply as Ubuntu developer, if you want to see your software inside Ubuntu. But from what I see since the last years we have REVU in place, that many packages are not maintained well enough, and many Ubuntu Developers are busy with the packages we merge/sync from Debian during release cycles, so there is no time or no desire to deal with ubuntu only uploaded packages (minus the packages who are ubuntu only but are needed for the Ubuntu OS in general). And really, this is no stereotype, but reality. And it does not only apply for Ubuntu, but for Debian, Fedora or openSuSE or whatever distro is out there. Regards, \sh -- | Stephan '\sh' Hermann| OSS Dev / SysAdmin | | JID: s...@linux-server.org | http://www.sourcecode.de/ | | GPG ID: 0xC098EFA8 | http://leonov.tv/ | | FP: 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 | -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On Tue, Mar 23, 2010 at 3:32 PM, Benjamin Drung bdr...@ubuntu.com wrote: I have to admit that the barrier is high to get new packages into Ubuntu and that creating new packages is not the best way to start/learn packaging. It seems to be that folks manage to create a package but it's not good enough. Then a motu or someone looks at it and you basically get a human being standing in the shoes of lintian telling you to fix insanely nuanced things which turns people away. I think its a question that we need to answer with someone's practical experience or statistics: How far away from ready are these packages? How long would it take a motu to go the final distance? Apparently there is not an adequate reward system setup for the motu - they must not feel like adding this software to ubuntu is worth their time. This is a bug. The REVU system and the whole MOTU concept seems to be designed to solve this problem, but we forgot that they are human beings.. it does seem worth it to me though to get this software in. There is one concern when uploading a new package: Who maintains the package afterwards? The (unwritten) rule (?) is that the person that did the initial packaging should take care of it. When there is no MOTU using the package and the initial packager disappears, then the package will probably get outdated and buggy. When the initial packagers get their packages into Debian, then they are the maintainers of the packages and they are responsible for them. Therefore it's not only a philosophy concern and not totally unreasonable. I think the most natural thing is that it is co-maintained by motu and the package submitter. Bugs relating to the packaging are handled by motu, bugs related to the software itself are handled by the developer. I think motu just has to ask the question, is there someone out there who cares about this piece of software and is going to make sure it is basically working and periodically updated and willing to fix bug reports? If so then it should be a candidate for inclusion in Ubuntu irregardless of Debian status or that developers ability to create a perfect package, whether that ability be due to knowledge or lack of investible time. After the package gets into Ubuntu almost all of the work is done for the folks who are experts at porting Ubuntu packages back into Debian. How many people working on that task and how many Ubuntu packages needs to be ported to Debian? Can we rely on the folks who port Ubuntu packages back into Debian or is this more only a wish? I don't know actually but I have heard that stuff is getting backported. There are tools that automatically do this. They can automatically figure out the right dependencies by basically running ldd on the libs and figuring out the right stuff. So I think this happens already semi-automatically at least. It should not be the concern of people who write awesome software and just want to make it available in the distribution they actually use. I agree that people who write awesome software shouldn't be bothered with packaging and all the distribution's processes. In an ideal world there would be a packager that work closely with the upstream developer and do all the packaging. Yep! And since this is not a democracy I wonder who at Ubuntu has authorized the demise of the REVU system? Isn't it part of Canonical's Ubuntu vision and hasn't at least one paid employee been asked to do it? Wasn't that person supervised by someone and did they drop the ball? Not to point fingers I have no idea how those things work - I just think its an unfortunate thing. Cheers, Brian -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
Brian J Mingus wrote: Yep! And since this is not a democracy I wonder who at Ubuntu has authorized the demise of the REVU system? Isn't it part of Canonical's Ubuntu vision and hasn't at least one paid employee been asked to do it? Wasn't that person supervised by someone and did they drop the ball? Not to point fingers I have no idea how those things work - I just think its an unfortunate thing. Nobody authorised the demise of the REVU system. It was created by volunteers to facilitate review of packages. REVU has never been overseen by Canonical, and I do not believe that any Canonical staff have ever been assigned to ensure it goes smoothly (although I may be mistaken). REVU's infastructue is provided by UbuntuWire, as a result of support from Department of Computer Science 4, Friedrich-Alexander University, Erlangen-Nuremberg. The key consideration is that MOTU consists *entirely* of volunteers. Some of us happen to also be paid for other work they do in open source or in Ubuntu, but nobody is paid to be MOTU. So long as MOTU remains the group that oversees REVU, REVU processing by MOTU will only happen when individual MOTU are sufficiently interested in processing that queue. As Eliot pointed out, one of the best ways to help keep this queue in shape is to participate in the review of submitted packages. As Benjamin pointed out, working *also* with Debian is a great way to get packages into Ubuntu. If you'd like to help, please set to reviewing and improving packages on REVU, and helping get them assigned a maintainer and in Debian. If you've questions along the way, please join us in #ubuntu-motu on freenode: it's a rare time of day someone won't be happy to help with any questions you have. -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On Wed, Mar 24, 2010 at 7:20 AM, Emmet Hikory per...@ubuntu.com wrote: Brian J Mingus wrote: Yep! And since this is not a democracy I wonder who at Ubuntu has authorized the demise of the REVU system? Isn't it part of Canonical's Ubuntu vision and hasn't at least one paid employee been asked to do it? Wasn't that person supervised by someone and did they drop the ball? Not to point fingers I have no idea how those things work - I just think its an unfortunate thing. Nobody authorised the demise of the REVU system. It was created by volunteers to facilitate review of packages. REVU has never been overseen by Canonical, and I do not believe that any Canonical staff have ever been assigned to ensure it goes smoothly (although I may be mistaken). REVU's infastructue is provided by UbuntuWire, as a result of support from Department of Computer Science 4, Friedrich-Alexander University, Erlangen-Nuremberg. The key consideration is that MOTU consists *entirely* of volunteers. Some of us happen to also be paid for other work they do in open source or in Ubuntu, but nobody is paid to be MOTU. So long as MOTU remains the group that oversees REVU, REVU processing by MOTU will only happen when individual MOTU are sufficiently interested in processing that queue. As Eliot pointed out, one of the best ways to help keep this queue in shape is to participate in the review of submitted packages. As Benjamin pointed out, working *also* with Debian is a great way to get packages into Ubuntu. If you'd like to help, please set to reviewing and improving packages on REVU, and helping get them assigned a maintainer and in Debian. If you've questions along the way, please join us in #ubuntu-motu on freenode: it's a rare time of day someone won't be happy to help with any questions you have. -- Emmet HIKORY I have plenty of IRC logs of me asking questions in #ubuntu-motu and never getting a reply that beg to differ. And I find it discouraging that this is the best sort of vision that you can muster. /Brian -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 23/03/2010, at 10.02, jdetaeye wrote: The tools and the intention of the REVU process are right. But if there aren't any reviewers working on the list, the process will remain broken. One problem is that we have no active REVU-coordinator for the time being, and that REVU-days have not been regularly organized since a very long time. -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 23/03/2010, at 22.32, Benjamin Drung wrote: How many people working on that task and how many Ubuntu packages needs to be ported to Debian? Can we rely on the folks who port Ubuntu packages back into Debian or is this more only a wish? Porting is not the problem, it's getting the package sponsored in Debian. -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
With REVU, there is a problem if it takes to long to get a package reviewed. It takes too long, no if statement required. A quick look at the current list of review backlog is devastating: http://revu.ubuntuwire.com/. People wait for more than a year to get their contribution reviewed. The tools and the intention of the REVU process are right. But if there aren't any reviewers working on the list, the process will remain broken. The uploaders become unmotivated and disappear. The package is left in the needs work state, and that list is even longer than the needs review list. Add me in this category: http://revu.ubuntuwire.com/p/frepple Johan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On Tue, Mar 23, 2010 at 3:02 AM, jdetaeye jdeta...@users.sourceforge.netwrote: With REVU, there is a problem if it takes to long to get a package reviewed. It takes too long, no if statement required. A quick look at the current list of review backlog is devastating: http://revu.ubuntuwire.com/. People wait for more than a year to get their contribution reviewed. The tools and the intention of the REVU process are right. But if there aren't any reviewers working on the list, the process will remain broken. The uploaders become unmotivated and disappear. The package is left in the needs work state, and that list is even longer than the needs review list. Add me in this category: http://revu.ubuntuwire.com/p/frepple Johan Yeah I'm on that list. I asked on REVU, in IRC, on this list and on Launchpad and I couldn't any MOTU to care one iota about my package. If there was even anyone in the process who cared they would have at least replied. Brian Mingus Professional Research Assistant Computational Cognitive Neuroscience Lab University of Colorado at Boulder http://grey.colorado.edu/emergent -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
Brian J Mingus brian.min...@colorado.edu wrote: On Tue, Mar 23, 2010 at 3:02 AM, jdetaeye jdeta...@users.sourceforge.netwrote: With REVU, there is a problem if it takes to long to get a package reviewed. It takes too long, no if statement required. A quick look at the current list of review backlog is devastating: http://revu.ubuntuwire.com/. People wait for more than a year to get their contribution reviewed. The tools and the intention of the REVU process are right. But if there aren't any reviewers working on the list, the process will remain broken. The uploaders become unmotivated and disappear. The package is left in the needs work state, and that list is even longer than the needs review list. Add me in this category: http://revu.ubuntuwire.com/p/frepple Johan Yeah I'm on that list. I asked on REVU, in IRC, on this list and on Launchpad and I couldn't any MOTU to care one iota about my package. If there was even anyone in the process who cared they would have at least replied. We get far more package submissions than we can review every cycle. I generally recommend getting your package into Debian and then it will be sync'ed into Ubuntu. There are a lot more developers in Debian. Scott K-- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On Tue, Mar 23, 2010 at 2:27 PM, Johan De Taeye johan_de_ta...@yahoo.com wrote: We get far more package submissions than we can review every cycle. I generally recommend getting your package into Debian and then it will be sync'ed into Ubuntu. There are a lot more developers in Debian. But, could this be documented? When people submit their package they know what they are up to. It'ld avoid people (like me) trying to learn the process, uploading their package in good faith and getting (a bit) frustrated. I fully understand and appreciate all the work the team is doing. Just trying to be positive and see how things can be improved... As Scott has pointed out, it's a problem of having enough volunteers to do the work. I am trying to improve the situation personally by working with Debian teams instead of Ubuntu for my own packages that I want to get in, reviewing packages and giving advice now and then on REVU, and working towards becoming a MOTU myself, but it's slow going. The best way to improve is for more people to do the same. Even if you are not yet MOTU, I think one of the best ways to learn is to review other peoples packages. I have learned many things to improve my own packages by carefully looking at other peoples packages, reading the existing reviews, and trying to see what things would need to be fixed before I would consider the package fine to upload. Doing code review is a really fantastic way to learn. -- Elliot Murphy | https://launchpad.net/~statik/ -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On Tue, Mar 23, 2010 at 2:12 PM, Elliot Murphy ell...@canonical.com wrote: On Tue, Mar 23, 2010 at 2:27 PM, Johan De Taeye johan_de_ta...@yahoo.com wrote: We get far more package submissions than we can review every cycle. I generally recommend getting your package into Debian and then it will be sync'ed into Ubuntu. There are a lot more developers in Debian. But, could this be documented? When people submit their package they know what they are up to. It'ld avoid people (like me) trying to learn the process, uploading their package in good faith and getting (a bit) frustrated. I fully understand and appreciate all the work the team is doing. Just trying to be positive and see how things can be improved... As Scott has pointed out, it's a problem of having enough volunteers to do the work. I am trying to improve the situation personally by working with Debian teams instead of Ubuntu for my own packages that I want to get in, reviewing packages and giving advice now and then on REVU, and working towards becoming a MOTU myself, but it's slow going. The best way to improve is for more people to do the same. Even if you are not yet MOTU, I think one of the best ways to learn is to review other peoples packages. I have learned many things to improve my own packages by carefully looking at other peoples packages, reading the existing reviews, and trying to see what things would need to be fixed before I would consider the package fine to upload. Doing code review is a really fantastic way to learn. -- Elliot Murphy | https://launchpad.net/~statik/https://launchpad.net/%7Estatik/ This really just doesn't click for me. These are Masters of the Universe after all. They know everything about creating packages and they have a highly efficient and streamlined package testing paradigm. They know what bugs in packages are and they know how to fix them more quickly than anyone else. Why is there no one who oversees the MOTUs (Master of the Masters of the Universe) and says this package should be in Universe and they say ok, I will spend the next couple of hours getting it ready. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
Am Dienstag, den 23.03.2010, 14:24 -0600 schrieb Brian J Mingus: On Tue, Mar 23, 2010 at 2:12 PM, Elliot Murphy ell...@canonical.com wrote: On Tue, Mar 23, 2010 at 2:27 PM, Johan De Taeye johan_de_ta...@yahoo.com wrote: We get far more package submissions than we can review every cycle. I generally recommend getting your package into Debian and then it will be sync'ed into Ubuntu. There are a lot more developers in Debian. But, could this be documented? When people submit their package they know what they are up to. It'ld avoid people (like me) trying to learn the process, uploading their package in good faith and getting (a bit) frustrated. I fully understand and appreciate all the work the team is doing. Just trying to be positive and see how things can be improved... As Scott has pointed out, it's a problem of having enough volunteers to do the work. I am trying to improve the situation personally by working with Debian teams instead of Ubuntu for my own packages that I want to get in, reviewing packages and giving advice now and then on REVU, and working towards becoming a MOTU myself, but it's slow going. The best way to improve is for more people to do the same. Even if you are not yet MOTU, I think one of the best ways to learn is to review other peoples packages. I have learned many things to improve my own packages by carefully looking at other peoples packages, reading the existing reviews, and trying to see what things would need to be fixed before I would consider the package fine to upload. Doing code review is a really fantastic way to learn. -- Elliot Murphy | https://launchpad.net/~statik/ This really just doesn't click for me. These are Masters of the Universe after all. They know everything about creating packages and they have a highly efficient and streamlined package testing paradigm. They know what bugs in packages are and they know how to fix them more quickly than anyone else. Why is there no one who oversees the MOTUs (Master of the Masters of the Universe) and says this package should be in Universe and they say ok, I will spend the next couple of hours getting it ready. Many MOTUs are busy with updating, syncing, merging packages and fixing bugs. Then there is the sponsors queue, which needs love too. I uploaded a few package from REVU. There were two ways to get my attention: Either someone ask in the #ubuntu-motu channel, when I had time for it or i searched the need-packaging bugs on Launchpad. Which package should I review? I sorted the need-packaging bugs by affected users and found openshot. I think that having a importance indicator would be a good idea. What do you think about promoting the use of Affects me too on Launchpad for that? BTW I sponsored only packages, where the packager worked on getting the package into Debian, too. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On Tue, Mar 23, 2010 at 2:45 PM, Benjamin Drung bdr...@ubuntu.com wrote: Am Dienstag, den 23.03.2010, 14:24 -0600 schrieb Brian J Mingus: On Tue, Mar 23, 2010 at 2:12 PM, Elliot Murphy ell...@canonical.com wrote: On Tue, Mar 23, 2010 at 2:27 PM, Johan De Taeye johan_de_ta...@yahoo.com wrote: We get far more package submissions than we can review every cycle. I generally recommend getting your package into Debian and then it will be sync'ed into Ubuntu. There are a lot more developers in Debian. But, could this be documented? When people submit their package they know what they are up to. It'ld avoid people (like me) trying to learn the process, uploading their package in good faith and getting (a bit) frustrated. I fully understand and appreciate all the work the team is doing. Just trying to be positive and see how things can be improved... As Scott has pointed out, it's a problem of having enough volunteers to do the work. I am trying to improve the situation personally by working with Debian teams instead of Ubuntu for my own packages that I want to get in, reviewing packages and giving advice now and then on REVU, and working towards becoming a MOTU myself, but it's slow going. The best way to improve is for more people to do the same. Even if you are not yet MOTU, I think one of the best ways to learn is to review other peoples packages. I have learned many things to improve my own packages by carefully looking at other peoples packages, reading the existing reviews, and trying to see what things would need to be fixed before I would consider the package fine to upload. Doing code review is a really fantastic way to learn. -- Elliot Murphy | https://launchpad.net/~statik/https://launchpad.net/%7Estatik/ This really just doesn't click for me. These are Masters of the Universe after all. They know everything about creating packages and they have a highly efficient and streamlined package testing paradigm. They know what bugs in packages are and they know how to fix them more quickly than anyone else. Why is there no one who oversees the MOTUs (Master of the Masters of the Universe) and says this package should be in Universe and they say ok, I will spend the next couple of hours getting it ready. Many MOTUs are busy with updating, syncing, merging packages and fixing bugs. Then there is the sponsors queue, which needs love too. I uploaded a few package from REVU. There were two ways to get my attention: Either someone ask in the #ubuntu-motu channel, when I had time for it or i searched the need-packaging bugs on Launchpad. Which package should I review? I sorted the need-packaging bugs by affected users and found openshot. I think that having a importance indicator would be a good idea. What do you think about promoting the use of Affects me too on Launchpad for that? BTW I sponsored only packages, where the packager worked on getting the package into Debian, too. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) In my opinion the decision should be made not based on some advanced philosophy concerning how many distributions the person tried to get the package into, but rather the quality of the software and how much it would improve Ubuntu. After the package gets into Ubuntu almost all of the work is done for the folks who are experts at porting Ubuntu packages back into Debian. It should not be the concern of people who write awesome software and just want to make it available in the distribution they actually use. The MOTUs have already raised the standard so high (you must admit there is a lot of prerequisite knowledge for creating a high quality package) and they are already so unavailable to provide assistance (meaning folks have to figure it out themselves) that your Debian requirement can only be considered completely unreasonable. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
Am Dienstag, den 23.03.2010, 14:55 -0600 schrieb Brian J Mingus: On Tue, Mar 23, 2010 at 2:45 PM, Benjamin Drung bdr...@ubuntu.com wrote: Am Dienstag, den 23.03.2010, 14:24 -0600 schrieb Brian J Mingus: On Tue, Mar 23, 2010 at 2:12 PM, Elliot Murphy ell...@canonical.com wrote: On Tue, Mar 23, 2010 at 2:27 PM, Johan De Taeye johan_de_ta...@yahoo.com wrote: We get far more package submissions than we can review every cycle. I generally recommend getting your package into Debian and then it will be sync'ed into Ubuntu. There are a lot more developers in Debian. But, could this be documented? When people submit their package they know what they are up to. It'ld avoid people (like me) trying to learn the process, uploading their package in good faith and getting (a bit) frustrated. I fully understand and appreciate all the work the team is doing. Just trying to be positive and see how things can be improved... As Scott has pointed out, it's a problem of having enough volunteers to do the work. I am trying to improve the situation personally by working with Debian teams instead of Ubuntu for my own packages that I want to get in, reviewing packages and giving advice now and then on REVU, and working towards becoming a MOTU myself, but it's slow going. The best way to improve is for more people to do the same. Even if you are not yet MOTU, I think one of the best ways to learn is to review other peoples packages. I have learned many things to improve my own packages by carefully looking at other peoples packages, reading the existing reviews, and trying to see what things would need to be fixed before I would consider the package fine to upload. Doing code review is a really fantastic way to learn. -- Elliot Murphy | https://launchpad.net/~statik/ This really just doesn't click for me. These are Masters of the Universe after all. They know everything about creating packages and they have a highly efficient and streamlined package testing paradigm. They know what bugs in packages are and they know how to fix them more quickly than anyone else. Why is there no one who oversees the MOTUs (Master of the Masters of the Universe) and says this package should be in Universe and they say ok, I will spend the next couple of hours getting it ready. Many MOTUs are busy with updating, syncing, merging packages and fixing bugs. Then there is the sponsors queue, which needs love too. I uploaded a few package from REVU. There were two ways to get my attention: Either someone ask in the #ubuntu-motu channel, when I had time for it or i searched the need-packaging bugs on Launchpad. Which package should I review? I sorted the need-packaging bugs by affected users and found openshot. I think that having a importance indicator would be a good idea. What do you think about promoting the use of Affects me too on Launchpad for that? BTW I sponsored only packages, where the packager worked on getting the package into Debian, too. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) In my opinion the decision should be made not based on some advanced philosophy concerning how many distributions the person tried to get the package into, but rather the quality of the software and how much it would improve Ubuntu. After the package gets into Ubuntu almost all of the work is done for the folks who are experts at porting Ubuntu packages back into Debian. It should not be the concern of people who write awesome software and just want to make it available in the distribution
Re: Future of MOTU
On 2010-03-02 12:55:00 +0900, Emmet Hikory wrote: Michael Bienia wrote: On 2010-02-22 12:53:09 +0900, Emmet Hikory wrote: [MOTU Leaders] My main rationale for retaining it was in hopes that new folk would step forward to lead various aspects of what we do and help shape best practices and clear documentation in those areas. I suppose this could be left to the several MOTU, but I think having the means to honor those who step forward helps provide tangible representation of our only currency: respect. I fully understand that but do you have an idea how to keep this list of Leaders open so that no impression of a fixed list of Leader (positions) arises and nobody dares to propose a new Leader (position)? We should respect each others independent of holding any Leader position or not. Some get more respected because of their expierence and expertise and this shouldn't be traded for respecting them because they are Leaders (who they become because of their expierence and expertise). But a list of persons with their field of expierence and expertise would be helpful to be able to know who to ask about certain problems. But I wouldn't call them Leaders. [MOTU meetings] While I'd would like to see regular MOTU meetings happen again, I also see that it's will be a hard task (sorry for sounding pessimistic). Without much to discuss I assume only a few people will attending a meeting (and stay up late or wake up early) just to hear status reports and prefer to read those status reports in the minutes. Are there any other strategies that you could suggest that would help to improve communication and accountability within the team? My experience with other teams is that when meetings aren't being held, growth and activity slow. Sorry no other ideas. And didn't want to stop you (or anybody else) from reviving the MOTU meetings. We should also try to get the ubuntu-motu ML more active again e.g. with those status reports (transitions: active, finished, planned; QA efforts; current health of universe; etc). When I look at my ubuntu-motu mailbox I mostly see only request originated from MOTU being set as the maintainer in packages. Have we a rough number of how many active MOTUs we currently have? (with a loose definition of active as at least one upload/merge/sync for lucid) We can certainly parse -changes to see who uploaded and who didn't. We can even cross-check this to see where uploads happened to unseeded packages. I'm not at all convinced this measures activity as MOTU rather than just uploads. I know that most of what I personally do doesn't result in me uploading something (but rather someone else uploading something, sometimes to Debian). I suspect similar is true for others active in new developer training or developer support. I also think this poorty serves those who spend lots of time on the hard stuff, and unfairly encourages those who have 1000 trivial uploads (e.g. I don't want to wait for it to reach Debian testing). We can measure mailing list and IRC traffic, but that's also not necessarily a good indicator. I think we'd have to deinfe active MOTU in some objective way prior to being able to get a count. That said, we *can* discover which MOTU have no mailing list posts, no IRC traffic, no uploads, no REVU comments, etc. during a given cycle. Depending on whether we account for package sets, this list will either be skewed to imply many active MOTU who have done nothing in target packages or artifically suggest that most developers are inactive in MOTU (even if they are active in other areas). I don't want hard numbers (e.g. 42 MOTUs were active during the karmic cycle) or even a list of names. I'm just interested in a rough estimate of which percentage from those over 100 direct members LP lists seems to be active in universe (what ever active might actually means being it direct or indirect (e.g. through Debian)). As this might explain why there is only few communication. 20 active MOTUs have much less to discuss than 80 active MOTUs (in which case I'd wonder myself why there is nothing to discuss). Something like we have around 30-40 active MOTUs or we have around 70-90 active MOTUs would be fully sufficient for me as I don't have an idea how big MOTU actually is we try here to reform. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On Tuesday 02 March 2010 16:27:36 Morten Kjeldgaard wrote: I my opinion, REVU is a hugely useful tool. A lot of work has quietly been done on the software lately, in large part thanks to RainCT, and I now think it is quite close to ideal: easy to use, and robust. Uhm, well OK, it still needs be taught to understand source package format: 3.0 (quilt) :-) -- Morten -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 2010-03-02 16:27:36 +0100, Morten Kjeldgaard wrote: On Tuesday 02 March 2010 00:06:49 Michael Bienia wrote: ii) Coordinate with all the other Ubuntu Developer Teams to set up a distribution-wide REVU Coordination team, with representatatives from each development group helping to ensure that packages of interest to each area are well tracked, and REVU again becomes considered a useful tool. I'd like to call on the REVU Hackers to support this team, potentially extending REVU to better support tracking of claimed vs. unclaimed packages, etc. The current tags functionality may be enough, but it may not. Although REVU is a nice tool, I'm not sure that is fits well in the MOTU workflow. It might work better for other teams where the packager and the team is really interested in getting the package into the archive and (more important) continue to maintain the package (ideally it ends in the package set for that team). I my opinion, REVU is a hugely useful tool. A lot of work has quietly been done on the software lately, in large part thanks to RainCT, and I now think it is quite close to ideal: easy to use, and robust. I didn't want it imply that REVU is not a useful tool. REVU is really good for the intended purpose (reviewing new packages). But I'm not sure if that purpose (reviewing/adding new packages) fits well into the MOTU work which is mostly QA based. With REVU, there is a problem if it takes to long to get a package reviewed. The uploaders become unmotivated and disappear. The package is left in the needs work state, and that list is even longer than the needs review list. I personally don't do any reviews on REVU for some time now, not because REVU is not useful, but because I don't believe that's currently the right way to encourage new contributors to contribute to MOTU. Other teams might feel different as they review and add new packages which are of real interest for them and which they continue to maintain. But I don't have the feeling that the packager or MOTU do really care about those packages once they are in the archive, and I don't want to contribute to this package-rot. I believe that we either should do it right and continue to maintain the packages afterwards so it's a benefit for all (for user, for upstream and for Ubuntu's reputation) or to be honest that we don't have that resources to maintain it properly and not package it at all. That way everyone knows what's to expect and don't get disappointed later. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
Michael Bienia wrote: On 2010-03-02 12:55:00 +0900, Emmet Hikory wrote: Michael Bienia wrote: On 2010-02-22 12:53:09 +0900, Emmet Hikory wrote: [MOTU Leaders] I fully understand that but do you have an idea how to keep this list of Leaders open so that no impression of a fixed list of Leader (positions) arises and nobody dares to propose a new Leader (position)? This is an excellent point, and not one I'd considered before. Given this potential, I'd be willing to do without MOTU Leaders, and retain leadership to the several MOTU. What do you think about the idea of having a nomination period after each cycle, and keeping a page honoring individual MOTU for achievements of great note in each cycle? [MOTU meetings] While I'd would like to see regular MOTU meetings happen again, I also see that it's will be a hard task (sorry for sounding pessimistic). Without much to discuss I assume only a few people will attending a meeting (and stay up late or wake up early) just to hear status reports and prefer to read those status reports in the minutes. Are there any other strategies that you could suggest that would help to improve communication and accountability within the team? My experience with other teams is that when meetings aren't being held, growth and activity slow. Sorry no other ideas. And didn't want to stop you (or anybody else) from reviving the MOTU meetings. We should also try to get the ubuntu-motu ML more active again e.g. with those status reports (transitions: active, finished, planned; QA efforts; current health of universe; etc). When I look at my ubuntu-motu mailbox I mostly see only request originated from MOTU being set as the maintainer in packages. I'm not tempted to lead MOTU Metings if there's not consensus it's the right way to proceed, because I think partial or unbalanced involvement will lead to either alienation or a sense of iniders and outsiders. If most of us agree it's a good thing, and that we'll try to make at least some of them, I think they can work. More traffic on the mailing list would be nice, but it needs people to track things and send them. We've developed tools to autotrack, and this reduced the notifications. Automated notifications would be bad, in my opinion (or at least I'd steadily ignore them). Have we a rough number of how many active MOTUs we currently have? (with a loose definition of active as at least one upload/merge/sync for lucid) I don't want hard numbers (e.g. 42 MOTUs were active during the karmic cycle) or even a list of names. I'm just interested in a rough estimate of which percentage from those over 100 direct members LP lists seems to be active in universe (what ever active might actually means being it direct or indirect (e.g. through Debian)). As this might explain why there is only few communication. 20 active MOTUs have much less to discuss than 80 active MOTUs (in which case I'd wonder myself why there is nothing to discuss). Something like we have around 30-40 active MOTUs or we have around 70-90 active MOTUs would be fully sufficient for me as I don't have an idea how big MOTU actually is we try here to reform. My feeing from a quick scan of relevant sources is that we're in the 20-30 range for some elvel of activity (highly variable). I'm probably undercounting, but I doubt it's in the 70-80 range (or eve much above 50). Note that this count excluded those MOTU who are also some other sort of developer (often core-dev) as I didn't analyse the activity closely to determine where it fell. -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 2010-03-03 02:08:27 +0900, Emmet Hikory wrote: Michael Bienia wrote: On 2010-03-02 12:55:00 +0900, Emmet Hikory wrote: Michael Bienia wrote: On 2010-02-22 12:53:09 +0900, Emmet Hikory wrote: [MOTU Leaders] I fully understand that but do you have an idea how to keep this list of Leaders open so that no impression of a fixed list of Leader (positions) arises and nobody dares to propose a new Leader (position)? This is an excellent point, and not one I'd considered before. Given this potential, I'd be willing to do without MOTU Leaders, and retain leadership to the several MOTU. What do you think about the idea of having a nomination period after each cycle, and keeping a page honoring individual MOTU for achievements of great note in each cycle? That sounds great. That way we could value those MOTUs for their contribution and encourage other MOTU to get listed on this page through their contributions too. This list of most valuable MOTUs shouldn't be limited in size and list everyone who qualified in that cycle (the more valuable MOTUs we have the better). [MOTU meetings] I'm not tempted to lead MOTU Metings if there's not consensus it's the right way to proceed, because I think partial or unbalanced involvement will lead to either alienation or a sense of iniders and outsiders. I think MOTU Meetings are a right way but I currently have a hard time thinking of good (regular) topics to make them work in the long run (but perhaps others have good ideas). If my memory serves me right, the MOTU meetings died of no topics and with no topics the attendees stayed away. My feeing from a quick scan of relevant sources is that we're in the 20-30 range for some elvel of activity (highly variable). I'm probably undercounting, but I doubt it's in the 70-80 range (or eve much above 50). Note that this count excluded those MOTU who are also some other sort of developer (often core-dev) as I didn't analyse the activity closely to determine where it fell. That number is sufficient for me. As that helps to estimate how much activity can be expected and also what kind of goverance structure would be suitable for MOTU. Michael -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 2010-02-22 12:53:09 +0900, Emmet Hikory wrote: A) Leadership We have historically been broadly without hierarchy, nominating and recognising some of our number as leaders (5) as a result of their continuing efforts in some area that directly improves the health of the team. On quick review, our leadership page is out of date, and many of our leadership roles no longer have clear meaning as ArchiveReorganisation continues. While each item deserves discussion, I'd like to suggest the following: i) Close down MOTU School (6) and merge historical texts, requests, etc. with the Packaging Training effort (7) All credit to James, the current Dean, but I believe the time has come to end the separation in this area. The MOTU School page already contains *** MOTU School has been retired in favor of Packaging/Training*** - These pages remain just for historical record (added in May 2009). ii) Coordinate with all the other Ubuntu Developer Teams to set up a distribution-wide REVU Coordination team, with representatatives from each development group helping to ensure that packages of interest to each area are well tracked, and REVU again becomes considered a useful tool. I'd like to call on the REVU Hackers to support this team, potentially extending REVU to better support tracking of claimed vs. unclaimed packages, etc. The current tags functionality may be enough, but it may not. Although REVU is a nice tool, I'm not sure that is fits well in the MOTU workflow. It might work better for other teams where the packager and the team is really interested in getting the package into the archive and (more important) continue to maintain the package (ideally it ends in the package set for that team). I see MOTU more in the function of keeping universe (later the unseeded packags) functioning (as far as possible). So the MOTU work is more QA style and continues to be it. And I don't see how adding new package benefits this target in the long run as most packages on REVU seem to be done by drive-by packagers who vanish again once their package is in the archive. Such a package might benefit Ubuntu in the short term but without a maintainer (being it a person or team in either Debian and/or Ubuntu) may harming Ubuntu in the long term. It doesn't serve the Ubuntu users when we ship old packages and upstream won't be happy either with getting support request from users using this old packages. As long as we don't have good processes to identify this stale packages and remove them later again, I don't think MOTU should use REVU much. iii) MOTU SWAT needs help, especially as it moves from universe to unseeded packages. I believe that extended discussion is worthwhile between the MOTU SWAT team and the Ubuntu Security team to determine if all security efforts could follow a standardised process and be handled by a single extended team (with some potential for separation within the team to support embargoed information, disclosure requirements, etc.). If MOTU SWAT is to remain separate, some work will need to be done on the tools to help better track what packages need attention and when. The problem I personally have is that I don't know how to usefully help with security updates. Grabing a security patch from Debian is mostly easy (depending how far the Debian and Ubuntu package differ), applying it to our packages and testing if it still builds is easy but then the hard part comes: how to test that the package really fixes the security problem? For SRUs there is a step-by-step guide how to reproduce a problem. But for security problems? Often I can only find a description of the problem and patches but not a ready test case against which I can check that I didn't break it again while backporting a fix (e.g. by missing an important patch). [But I've to say that I didn't try to do security updates in the recent past]. iv) Our Mentoring efforts (8) have extended beyond a single Mentoring Facilitator. I'm unsure of the current state of this effort, but I'd think that at least the Junior Mentoring program ought be a single shared program for all development teams, with only the Senior Mentoring program preserved as part of MOTU efforts. Perhaps this should be coordinated with the other teams and we should a common understanding how mentoring should work to not confuse new developers who look/try different teams with different style of mentoring (as far as possible). vii) The current MOTU Council is unquorate, and unable to take any action. I believe that the current members should be released from their responsibility until we have some consensus on how to deal with Governance (B). +1 B) Governance MOTU has historically been governed by a set of bodies with full separation of powers: specifically the Leaders, empowered to act unless constrained by policy or dispute, the MOTU Meeting, able to set policy and delegate powers from individual MOTU to specific
Re: Future of MOTU
Michael Bienia wrote: On 2010-02-22 12:53:09 +0900, Emmet Hikory wrote: ii) Coordinate with all the other Ubuntu Developer Teams to set up a distribution-wide REVU Coordination team, with representatatives from each development group helping to ensure that packages of interest to each area are well tracked, and REVU again becomes considered a useful tool. I'd like to call on the REVU Hackers to support this team, potentially extending REVU to better support tracking of claimed vs. unclaimed packages, etc. The current tags functionality may be enough, but it may not. Although REVU is a nice tool, I'm not sure that is fits well in the MOTU workflow. It might work better for other teams where the packager and the team is really interested in getting the package into the archive and (more important) continue to maintain the package (ideally it ends in the package set for that team). ... As long as we don't have good processes to identify this stale packages and remove them later again, I don't think MOTU should use REVU much. I fully agree with this. Unfortunately, we have a current limitation in the way the archive works that limits new uploads to either MOTU or core-dev. Until we (being all Ubuntu Developers) find a good workflow for this and get it implemented in Soyuz, I fear that REVU will remain at least partially a responsibility of MOTU. By coordinating with other development teams, we're in much better potision to step back from the more questionable packages, yet still offer advice and support in getting the REVU responsibilitiy transitioned. i) Retain MOTU Leaders as those who we recognise as having special drive, expertise, and activity in specific areas, and continue to grant these MOTU special authority to set guidelines and best practices related to their area of expertise. I think this has worked in the past, and provides a dynamic force for helping us to know how to accomplish many of our goals. I'd like to add an expectation that those MOTU recognised as Leaders report regularly (say monthly) to the rest of MOTU on their activities and plans, firstly to encourage other MOTU to participate in that area (and provide for backup/turnover as individual interests shift), and secondly as a way to help identify when Leaders are not making progress, and may need assistance or support in their sphere of operations. While I recognise the contributions of the MOTU Leaders, I currently don't see a need for them. When looking at the MOTU Leaders page and striking those out that are either already merged, being in the state of merging or being dissolved, there is not much left. And from those left I don't see anything MOTU special but only areas where a coordinated effort with the other teams would be useful (REVU coordination, security updates, mentoring, liasons). And when I think about the past, I don't remember much visible activity from those leaders (in their role as leaders and not as the individuals occupying those positions). We should keep our governance/leadership structure simple and flat and don't introduce a broad structure (unless really necessary) and make it more bureaucratic as really necessary. In the current state of MOTU I don't see a need for such a structure. My main rationale for retaining it was in hopes that new folk would step forward to lead various aspects of what we do and help shape best practices and clear documentation in those areas. I suppose this could be left to the several MOTU, but I think having the means to honor those who step forward helps provide tangible representation of our only currency: respect. ii) Revive the MOTU Meetings on a regular rotating schedule (I like 22:00, 6:00, and 14:00 UTC with a meeting every week, rotating over three weeks). While I'd like to retain the power of MOTU Meeting to establish policy, with Archive Reorganisation, there is much less policy that is necessarily MOTU-specific, and we would likely benefit from use of the meeting to also discuss other areas (transitions, QA efforts, sets of packages with lots of bugs, requests for help with specific things, blocking issues, coordination with distribution-wide teams, etc.). To facilitate this, I'd like to suggest that not all agenda items need the full announce/meet/shepard process, but rather that the sheparding process only be used where policy is specifically being adjusted (and only in cases where policy is entirely specific to MOTU: many policy issues are better brought to the Technical Board). A regular meeting with publised minutes also serves to keep all MOTU informed of activities, even when they may not be able to track IRC closely or follow various bug reports. While I'd would like to see regular MOTU meetings happen again, I also see that it's will be a hard task (sorry for sounding pessimistic). Without much to discuss I assume only a few people will attending a meeting (and stay up late
Re: Future of MOTU
On Mon, Feb 22, 2010 at 12:53:09PM +0900, Emmet Hikory wrote: Fellow MOTU, [...] There remain several areas for action in order to fully realise the new MOTU role, as follows: A) Leadership We have historically been broadly without hierarchy, nominating and recognising some of our number as leaders (5) as a result of their continuing efforts in some area that directly improves the health of the team. On quick review, our leadership page is out of date, and many of our leadership roles no longer have clear meaning as ArchiveReorganisation continues. While each item deserves discussion, I'd like to suggest the following: i) Close down MOTU School (6) and merge historical texts, requests, etc. with the Packaging Training effort (7) All credit to James, the current Dean, but I believe the time has come to end the separation in this area. +1. I think this should have been done back in April 2009 when the Packaging Training effort began, as I noticed a few people back then were a little confused on what the difference was. ii) Coordinate with all the other Ubuntu Developer Teams to set up a distribution-wide REVU Coordination team, with representatatives from each development group helping to ensure that packages of interest to each area are well tracked, and REVU again becomes considered a useful tool. I'd like to call on the REVU Hackers to support this team, potentially extending REVU to better support tracking of claimed vs. unclaimed packages, etc. The current tags functionality may be enough, but it may not. Small teams, or smaller teams, such as Kubuntu, Edubuntu, and Xubuntu, this is quite easy to do. With Kubuntu, we typically upload to REVU, and head straight to #kubuntu-devel and let everyone know a package needs to be reviewed. That is how we are pretty quick with it. iii) MOTU SWAT needs help, especially as it moves from universe to unseeded packages. I believe that extended discussion is worthwhile between the MOTU SWAT team and the Ubuntu Security team to determine if all security efforts could follow a standardised process and be handled by a single extended team (with some potential for separation within the team to support embargoed information, disclosure requirements, etc.). If MOTU SWAT is to remain separate, some work will need to be done on the tools to help better track what packages need attention and when. Could some of the current SWAT members add their voices to this one? I would like to hear feedback from you all, since this is an area that I didn't follow closely. iv) Our Mentoring efforts (8) have extended beyond a single Mentoring Facilitator. I'm unsure of the current state of this effort, but I'd think that at least the Junior Mentoring program ought be a single shared program for all development teams, with only the Senior Mentoring program preserved as part of MOTU efforts. +1. I would like to see the dev teams of Kubuntu, Xubuntu, and Edubuntu help out here as well. Kubuntu in the past has done a decent job, but I will admit it hasn't been the easiest to get a mentor. This is something I can bring up with them and see if we can implement a Kubuntu mentorship or something. v) I think we still benefit from having a Launchpad Liaison team, but I suspect we'd benefit more with some more visibility into LP schedules, and some bug tracking. I'd like to see this team try to expose activity in more detail, or seek fresh membership who would volunteer to do so. Is this a team or a single person? I know in the past Jordan was LPL, then he handed it over to Reinhard, who then handed it over to both William Grant and Morten Kjeldgaard last year. William and Morten, is being the current LPL's a busy task these days? I would like to hear more on this before deciding on if a team is needed or a LPL at that. vi) As long as the incumbent is willing to serve, I think we should continue with the current Canonical Liaison. Of all the areas in MOTU Leadership, I've heard the least complaints about Daniel in this role. Maybe we should start complaining more about Daniel :) +1 though, Daniel is easy to work with in this position and usually fairly easy to get in touch with, unless of course he is out walking the dogs :) vii) The current MOTU Council is unquorate, and unable to take any action. I believe that the current members should be released from their responsibility until we have some consensus on how to deal with Governance (B). :( but I agree. It was a blast serving on the council and working with everyone, and it was an opportunity I am glad to have been involved with. viii) There is current activity merging the MOTU Release Managers with the Ubuntu Release team. Much credit to the good work done in the past, but I think we will benefit more from a single coherent team than having a separate set of delegates, such that Ubuntu Release members drawn from MOTU ought not be seen as having any
Re: Future of MOTU
Hiya all, Thanks to Emmet for raising these important issues. On Mon, Feb 22, 2010 at 12:53:09PM +0900, Emmet Hikory wrote: Fellow MOTU, During the Jaunty UDS, discussions of Archive Reorganisation (0) indicated that MOTU would be no more, and all of us should have received a request for feedback as to how we wished to proceed with our individual roles in Ubuntu Development. This work was met with wide apathy, and some confusion. At the Karmic UDS, discussion of the future of maintenance of those packages not belonging to specific teams was discussed, with the conclusion that it would be sensible to maintain a development team dedicated to the maintenance of these packages, resulting in a specification (1) that has now been approved by the Developer Membership Board (2) and Technical Board (3). As a result, we now have a new mission, summarised as: I suspect I am not alone in agreeing that the announcements were confusing. A lot of the documentation and specs still refer to generalist developers, which does not help when scouring the wiki to find out what the current situation is. [...] There remain several areas for action in order to fully realise the new MOTU role, as follows: I'll only address the areas where I have comments in my response. A) Leadership We have historically been broadly without hierarchy, nominating and recognising some of our number as leaders (5) as a result of their continuing efforts in some area that directly improves the health of the team. On quick review, our leadership page is out of date, and many of our leadership roles no longer have clear meaning as ArchiveReorganisation continues. While each item deserves discussion, I'd like to suggest the following: [...] ii) Coordinate with all the other Ubuntu Developer Teams to set up a distribution-wide REVU Coordination team, with representatatives from each development group helping to ensure that packages of interest to each area are well tracked, and REVU again becomes considered a useful tool. I'd like to call on the REVU Hackers to support this team, potentially extending REVU to better support tracking of claimed vs. unclaimed packages, etc. The current tags functionality may be enough, but it may not. We are very bad at proactively reviewing new packages on REVU, and almost as bad at responding to requests for reviews which we very frequently receive on IRC, and less frequently receive on the ML(s). Just take a look at the number of packages in the Needs Review state. I feel that we may be creating a somewhat unfair expectation that there is a simple path from .dsc to the Ubuntu archives, when in reality we do not have anywhere near the manpower required to make this as smooth as it may seem. In addition to that, it is sadly often the case that once packages are accepted into the Ubuntu archives, they are thereafter unmaintained. It is encouraged that the intial uploader subscribe to the bug traffic and maintain the package, but our development model cannot enforce this. All other than the most extraordinarily stable packages (which generally are not the ones that come in through REVU) need an active maintainer. This is something which we get for free with our packages that come from Debian. I have heard it said by members of other teams within Ubuntu that REVU is not useful to their workflow, and that they manage to work perfectly well at reviewing their own packages without it. Such reviews tend to be conducted by members of the team. I doubt whether it would be feasible to coax other (primarily Canonical) teams over to using REVU, or even that there would be a benefit to doing so, as these reviewers are not likely to start taking packages from the general queue. Sadly I don't see a pleasant way out of this, given that we are not likely to be able to solve the primary problem of having willing reviewers. I therefore think that the most palatable option will be to increase the barrier of inclusion for Ubuntu local packages. Contributors should be required to demonstrate that they have attempted to get their package into Debian first, probably through the appropriate packaging team. MOTU, as they have a stronger link to the distribution, could be permitted to upload their own NEW packages given the usual additional positive review. This should not preclude the forward progress of the distribution, and in the inevitable cases where a NEW package is of clear importance for inclusion in a release, this could be allowed given a named MOTU who is willing to take responsibility for ensuring that the package is kept in good shape (primarily through nudging of the contributor). Anyone sufficiently motivated — not just creating a vanity package — should be able to get their work in through one of these routes: either taking up maintainership in Debian, or convincing a MOTU that their package is good enough. In this vision, REVU would become more
Re: Future of MOTU
On Mon, 2010-02-22 at 14:06 +, Iain Lane wrote: iii) MOTU SWAT needs help, especially as it moves from universe to unseeded packages. I believe that extended discussion is worthwhile between the MOTU SWAT team and the Ubuntu Security team to determine if all security efforts could follow a standardised process and be handled by a single extended team (with some potential for separation within the team to support embargoed information, disclosure requirements, etc.). If MOTU SWAT is to remain separate, some work will need to be done on the tools to help better track what packages need attention and when. As an outsider, it seems to me that this team lacks coordination, and would benefit from being under the Ubuntu security umbrella so that the engineers working there can effectively delegate the required security work for Universe packages. This is probably true and our teams can discuss ways to address this. With proper work tracking, I can see this being a successful collaboration. I think we already have all the tracking mechanisms in place, we just need people to work on them: https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue https://code.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master http://people.canonical.com/~ubuntu-security/cve/universe.html http://people.canonical.com/~ubuntu-security/d2u/ -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On Mon, 2010-02-22 at 12:53 +0900, Emmet Hikory wrote: iii) MOTU SWAT needs help, especially as it moves from universe to unseeded packages. I believe that extended discussion is worthwhile between the MOTU SWAT team and the Ubuntu Security team to determine if all security efforts could follow a standardised process and be handled by a single extended team (with some potential for separation within the team to support embargoed information, disclosure requirements, etc.). If MOTU SWAT is to remain separate, some work will need to be done on the tools to help better track what packages need attention and when. I think in a lot of ways, this is already done. We just need more people to get involved in the process. Due to limitations in Launchpad, MOTU-SWAT still needs to be a separate team from ubuntu-security (this is due to the ubuntu-security PPA containing embargoed items and the fact that you must be a member of ubuntu-security to publish from this PPA to the security pocket). We've long wanted MOTU-SWAT to be able to manage themselves and we can help/comment on procedures when the LP limitations are gone. That said, with the help of various MOTU folk[1] we identified improvements in the security sponsorship process and have implemented changes to address them and make our processes more like other teams[2]. The ubuntu-security-sponsors team was created, which MOTU-SWAT is a member. Links for the security sponsorship processes are also integrated into the the main SponsorshipProcess[3], just like with other teams. Each week a member of the ubuntu-security team is assigned to process bugs in our SponsorsQueue. So far, we've been doing all review as well as publication, but MOTU-SWAT can get involved in the review process which is really the most important part (while the ubuntu-security team is required for publication, this is simply a matter of copying packages around). Jamie [1] https://blueprints.launchpad.net/ubuntu/+spec/security-lucid-sponsorship-review [2] https://wiki.ubuntu.com/SecurityTeam/SponsorsQueue [3] https://wiki.ubuntu.com/SponsorshipProcess -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
Jamie Strandboge wrote: Emmet Hikory wrote: iii) MOTU SWAT needs help, especially as it moves from universe to unseeded packages. I believe that extended discussion is worthwhile between the MOTU SWAT team and the Ubuntu Security team to determine if all security efforts could follow a standardised process and be handled by a single extended team (with some potential for separation within the team to support embargoed information, disclosure requirements, etc.). If MOTU SWAT is to remain separate, some work will need to be done on the tools to help better track what packages need attention and when. I think in a lot of ways, this is already done. We just need more people to get involved in the process. Excellent. It's always good to hear that things are already being done. You guys should announce stuff more widely (yes, I know, one always has to be careful with disclosure). Due to limitations in Launchpad, MOTU-SWAT still needs to be a separate team from ubuntu-security (this is due to the ubuntu-security PPA containing embargoed items and the fact that you must be a member of ubuntu-security to publish from this PPA to the security pocket). We've long wanted MOTU-SWAT to be able to manage themselves and we can help/comment on procedures when the LP limitations are gone. That said, with the help of various MOTU folk[1] we identified improvements in the security sponsorship process and have implemented changes to address them and make our processes more like other teams[2]. The ubuntu-security-sponsors team was created, which MOTU-SWAT is a member. Links for the security sponsorship processes are also integrated into the the main SponsorshipProcess[3], just like with other teams. Each week a member of the ubuntu-security team is assigned to process bugs in our SponsorsQueue. So far, we've been doing all review as well as publication, but MOTU-SWAT can get involved in the review process which is really the most important part (while the ubuntu-security team is required for publication, this is simply a matter of copying packages around). This matches my previous understanding that security was still tracked on a component basis. While we still will have components for a while, I am expecting that we will have a growth in packagesets in the medium-term, as the various teams who already care for loosely defined packagesets request formal recognition from the Technical Board. With this change, the set of packages for which MOTU will have explicit responsibility will be reduced, and there may end up being an increasing gap between the union of main and unseeded packages and coverage of the entire archive. As a result, I'm not confident MOTU SWAT remains an ideal identity for the set of people working on security who don't have rights to pocket-copy packages to -security. Also, while I admire the work the security team has done, I think that it likely makes sense to reach out to all the defined development teams (Ubuntu Desktop, Kubuntu, Mythbuntu, MOTU, potentially Edubuntu if approved tomorrow, etc.) to seek additional assistance with patch review, publication to the current development release, and backporting to prior releases. As Archive Reorganisation moves forward, and components go away entirely, I expect this becomes even more complicated, but I still think that it is handled better by an integrated ubuntu-security team (perhaps with only a subset authorised to pocket-copy) distribution wide than by having a central core security team and additional representative teams for each packageset providing security. -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On Mon, 2010-02-22 at 08:46 -0600, Jamie Strandboge wrote: So far, we've been doing all review as well as publication, but MOTU-SWAT can get involved in the review process which is really the most important part Correction-- the *most* important part is someone doing updates, followed by review of the updates. As Iain pointed out, we should identify improvements for coordination between the teams. MOTU-SWAT has been quiet for some time, in part because contributions were regrettably going unnoticed due to a lack of process. I think the issues have been addressed during the last two cycles and I really hope we can revitalize MOTU-SWAT going forward. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
On 22/02/10 15:06, Iain Lane wrote: Hiya all, Thanks to Emmet for raising these important issues. On Mon, Feb 22, 2010 at 12:53:09PM +0900, Emmet Hikory wrote: Fellow MOTU, During the Jaunty UDS, discussions of Archive Reorganisation (0) indicated that MOTU would be no more, and all of us should have received a request for feedback as to how we wished to proceed with our individual roles in Ubuntu Development. This work was met with wide apathy, and some confusion. At the Karmic UDS, discussion of the future of maintenance of those packages not belonging to specific teams was discussed, with the conclusion that it would be sensible to maintain a development team dedicated to the maintenance of these packages, resulting in a specification (1) that has now been approved by the Developer Membership Board (2) and Technical Board (3). As a result, we now have a new mission, summarised as: I suspect I am not alone in agreeing that the announcements were confusing. A lot of the documentation and specs still refer to generalist developers, which does not help when scouring the wiki to find out what the current situation is. I totally agree, there was a lot of confusion and still is going on. It should be easier to distinguish between Draft/Discussion and already accepted new Policy. ii) Coordinate with all the other Ubuntu Developer Teams to set up a distribution-wide REVU Coordination team, with representatatives from each development group helping to ensure that packages of interest to each area are well tracked, and REVU again becomes considered a useful tool. I'd like to call on the REVU Hackers to support this team, potentially extending REVU to better support tracking of claimed vs. unclaimed packages, etc. The current tags functionality may be enough, but it may not. We are very bad at proactively reviewing new packages on REVU, and almost as bad at responding to requests for reviews which we very frequently receive on IRC, and less frequently receive on the ML(s). Just take a look at the number of packages in the Needs Review state. I feel that we may be creating a somewhat unfair expectation that there is a simple path from .dsc to the Ubuntu archives, when in reality we do not have anywhere near the manpower required to make this as smooth as it may seem. In addition to that, it is sadly often the case that once packages are accepted into the Ubuntu archives, they are thereafter unmaintained. It is encouraged that the intial uploader subscribe to the bug traffic and maintain the package, but our development model cannot enforce this. All other than the most extraordinarily stable packages (which generally are not the ones that come in through REVU) need an active maintainer. This is something which we get for free with our packages that come from Debian. I have heard it said by members of other teams within Ubuntu that REVU is not useful to their workflow, and that they manage to work perfectly well at reviewing their own packages without it. Such reviews tend to be conducted by members of the team. I doubt whether it would be feasible to coax other (primarily Canonical) teams over to using REVU, or even that there would be a benefit to doing so, as these reviewers are not likely to start taking packages from the general queue. Sadly I don't see a pleasant way out of this, given that we are not likely to be able to solve the primary problem of having willing reviewers. I therefore think that the most palatable option will be to increase the barrier of inclusion for Ubuntu local packages. Contributors should be required to demonstrate that they have attempted to get their package into Debian first, probably through the appropriate packaging team. MOTU, as they have a stronger link to the distribution, could be permitted to upload their own NEW packages given the usual additional positive review. This should not preclude the forward progress of the distribution, and in the inevitable cases where a NEW package is of clear importance for inclusion in a release, this could be allowed given a named MOTU who is willing to take responsibility for ensuring that the package is kept in good shape (primarily through nudging of the contributor). Anyone sufficiently motivated — not just creating a vanity package — should be able to get their work in through one of these routes: either taking up maintainership in Debian, or convincing a MOTU that their package is good enough. In this vision, REVU would become more like mentors.d.n, a purpose that I feel it is well suited for. I think everyone knows that the current REVU situation is not really satisfying. I'm not sure how the raise the barrier is meant but here are my thoughts: I'm of the opinion that there are currently 5 possiblities: 1) Shutdown REVU completely 2) Keep REVU as it's now 3) Only MOTU are allowed to upload and a second MOTU reviews and uploads it 4) Universe
Re: Future of MOTU
On Tue, 2010-02-23 at 00:28 +0900, Emmet Hikory wrote: Due to limitations in Launchpad, MOTU-SWAT still needs to be a separate team from ubuntu-security (this is due to the ubuntu-security PPA containing embargoed items and the fact that you must be a member of ubuntu-security to publish from this PPA to the security pocket). We've long wanted MOTU-SWAT to be able to manage themselves and we can help/comment on procedures when the LP limitations are gone. That said, with the help of various MOTU folk[1] we identified improvements in the security sponsorship process and have implemented changes to address them and make our processes more like other teams[2]. The ubuntu-security-sponsors team was created, which MOTU-SWAT is a member. Links for the security sponsorship processes are also integrated into the the main SponsorshipProcess[3], just like with other teams. Each week a member of the ubuntu-security team is assigned to process bugs in our SponsorsQueue. So far, we've been doing all review as well as publication, but MOTU-SWAT can get involved in the review process which is really the most important part (while the ubuntu-security team is required for publication, this is simply a matter of copying packages around). This matches my previous understanding that security was still tracked on a component basis. While we still will have components for a while, I am expecting that we will have a growth in packagesets in the medium-term, as the various teams who already care for loosely defined packagesets request formal recognition from the Technical Board. With this change, the set of packages for which MOTU will have explicit responsibility will be reduced, and there may end up being an increasing gap between the union of main and unseeded packages and coverage of the entire archive. As a result, I'm not confident MOTU SWAT remains an ideal identity for the set of people working on security who don't have rights to pocket-copy packages to -security. Also, while I admire the work the security team has done, I think that it likely makes sense to reach out to all the defined development teams (Ubuntu Desktop, Kubuntu, Mythbuntu, MOTU, potentially Edubuntu if approved tomorrow, etc.) to seek additional assistance with patch review, publication to the current development release, and backporting to prior releases. As Archive Reorganisation moves forward, and components go away entirely, I expect this becomes even more complicated, but I still think that it is handled better by an integrated ubuntu-security team (perhaps with only a subset authorised to pocket-copy) distribution wide than by having a central core security team and additional representative teams for each packageset providing security. Historically, the ubuntu-security team is comprised of Canonical employees only. It is the team that is responsible for officially supported packages in main and restricted. Moving forward, the ubuntu-security team will have a list of packages which are supported (we obviously have to) if/when components go away entirely. While anyone can submit a patch for a supported package, a member of the ubuntu-security team will need to perform the review, testing, publication and USN. I don't really see this as something that should change, but that of course doesn't mean that ubuntu-security can't work with other teams providing security support! :) For community supported packages, in the current process anyone can submit a patch for a security update with ubuntu-security-sponsors reviewing them and ubuntu-security publishing ACKd patches. ubuntu-security only has to be involved at all due to LP limitations, but performing the shuffling around is not a huge issue atm. We currently do reach out to the other teams on an individual basis, though as mentioned in this thread, there is more that can be done with coordination regarding community supported packages. For now that team is MOTU-SWAT and moving forward we will work with whatever teams and processes are in place for this. Ultimately, I see the handling of community security as a function of the community. Ie, MOTU (or whatever it will turn into) should define its own processes for dealing with security updates, but IMHO all that really needs to happen is that people need to get involved with provided patches and joining ubuntu-security-sponsors to get them reviewed. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU
Jamie Strandboge wrote: Emmet Hikory wrote: As Archive Reorganisation moves forward, and components go away entirely, I expect this becomes even more complicated, but I still think that it is handled better by an integrated ubuntu-security team (perhaps with only a subset authorised to pocket-copy) distribution wide than by having a central core security team and additional representative teams for each packageset providing security. ... For community supported packages, in the current process anyone can submit a patch for a security update with ubuntu-security-sponsors reviewing them and ubuntu-security publishing ACKd patches. ubuntu-security only has to be involved at all due to LP limitations, but performing the shuffling around is not a huge issue atm. For the reference of those following the discussion, this topic was raised in the weekly Secuity Team meeting, and the following item has been added to the agenda for the next Technical Board meeting: * Have delegated teams become responsible for security of their packagesets (KeesCook) * expect teams to actively track at least open CVEs in their packagesets * expect teams to report on the progress of such tracking during the weekly security team meeting Members of MOTU SWAT are encouraged to attend and share their views. Based on the meeting discussion, I have been convinced there is an active place for MOTU SWAT within the redefined MOTU. -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU discussion at UDS
Am Montag, den 09.11.2009, 17:19 -0500 schrieb Scott Kitterman: With the archive reorganisation coming fast, I've registered a spec for a discussion at UDS about the future of the MOTU community. I'd like to encourage all MOTU who are going to UDS and any others that would be willing to participate remotely to subscribe to the spec I've made for the discussion: https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-motu Even if the SRU and release teams and the MOTU Council are absorbed into larger archive wide bodies, there are still a number of things that MOTU does that are not replicated elsewhere and I think we should discuss what we want our future to be. I'm CCing ubuntu-devel@ and technical-board@ as I think there should be more people involved in this discussion. Maybe we can also make the title of the session a bit more generic? Maybe Lucid Development Process Review or something? Permissions Reorg should be the perfect opportunity for us to unify processes where possible and make sure they all make sense in a post-permissions-reorganised world. Have a great day, Daniel -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Future of MOTU discussion at UDS
On Tue, 10 Nov 2009 17:52:25 +0100 Daniel Holbach daniel.holb...@ubuntu.com wrote: Am Montag, den 09.11.2009, 17:19 -0500 schrieb Scott Kitterman: With the archive reorganisation coming fast, I've registered a spec for a discussion at UDS about the future of the MOTU community. I'd like to encourage all MOTU who are going to UDS and any others that would be willing to participate remotely to subscribe to the spec I've made for the discussion: https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-motu Even if the SRU and release teams and the MOTU Council are absorbed into larger archive wide bodies, there are still a number of things that MOTU does that are not replicated elsewhere and I think we should discuss what we want our future to be. I'm CCing ubuntu-devel@ and technical-board@ as I think there should be more people involved in this discussion. Maybe we can also make the title of the session a bit more generic? Maybe Lucid Development Process Review or something? Permissions Reorg should be the perfect opportunity for us to unify processes where possible and make sure they all make sense in a post-permissions-reorganised world. I think such a session would be a good thing, but I think that is different than the discussion I am proposing to have here. I think it's reasonable for MOTU to sit down as a group and discuss what it is that they want. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
