Re: Reorganize MOTU team documentation?
On 02.03.2010 00:01, Emmet Hikory wrote: 1) With Archive Reorganisation, the vast majority of documentation is no longer MOTU-specific, to the degree that aside from a basic set of team pages (overview, roadmap, meetings (and historical minutes), policy summary (mostly related to Leaders/Meeting/Council, etc.) I don't think there's much that belongs under MOTU Documentation. Changes to Developer Documentation should be discussed on a wider list. 2) Much of the Developer Documentation (and all MOTU-specific documentation) tends to reference information for other teams: most especially the various QA teams (bugsquad, testing, etc.). Moving it out of the wiki fails to help this integration, and makes it difficult for those working on other teams (who may not have any reason to know bzr) to easily reference our documentation. Agreed. 3) Publication to a known URL is a huge advantage. Aside from the ease of passing URLs in IRC, such pages also show easily in various web searches about a topic. It is painful to extract an appropriate current URI for a formatted page from loggerhead, so that is insufficient as an alternative. Regular updates to some known authoritative provider would work, but there would need to be an expectation of persistence for the length of the project. This could theoretically be solved by checking out current documentation trunk and publishing it as HTML somewhere. 4) The majority of our fellow developers are probably not familiar with mallard. While they can learn how to use it, it seems unfortunate to make this change at the same time we are making other changes that require developers to update their understanding: frequent change of the way in which things are done has often been cited in the past as a reason for developers to cease contributions. Before we decide to do this it might make sense to talk to people who did this work in DocBook before and how many people enjoyed contributing there. I don't mean to be too negative and am happy about every attempt to spruce up our documentation, but I have some reservations about the ease of doing drive-by fixes or writing a new article. 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: motu-release
On Thu, Feb 18, 2010 at 01:02:43PM +0100, Stefan Potyra wrote: Definitely makes sense. I don't have a strong preference over the exact procedure as well. How did ubuntu-release handle FFe's so far? I assume the worklist is the list of subscribed bugs? Yep, precisely. Do you also use the +nominations page? No, the conclusion a couple cycles back was that the +nominations list has a low S:N ratio, and anyway that feature doesn't add anything over the subscribed bugs list. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release
Since there are no objections to the proposed diff, I've applied it now (plus Daniel's correction). I'll send out an announcement mail in the next day or so informing developers of the new procedure, then mass-migrate the motu-release bug subscriptions over to ubuntu-release. On Sun, Feb 28, 2010 at 12:35:26AM +0100, Stefan Potyra wrote: I think the attached diff for FreezeExceptionProcess reflects the emerging consensus. Are there any objections if I apply this to the wiki and send out an updated freeze process mail to u-d-a? no objection, but still got a few questions: 1) how are FFe's handled? I assume that one ACK from a member of ubuntu-release suffices, correct? Yes, that's the intent, consistent with my own feeling on the subject and the feedback from Scott. The wiki changes reflect this, I think, by removing all mentions of the two-vote requirement. 2) new packages: do we also just require one ACK there, or do we want two ACKs? Also, new packages was delegated from MOTU to motu-release (or rather motu-uvf which got renamed to motu-release later). Even later ubuntu-release was made a member of motu-release, acknowledging that ubuntu-release should always be able to decide for motu-release. Do we need a formal MOTU decision to transfer this responsibility? If so (please speak up if you anyone think that it's needed, otherwise I'll assume consensus), what is the current process to get this decision? Effectively, the ubuntu-release team and the motu-release team are now identical, so I don't think redelegation would be needed here. As for a two-ack requirement on new packages, I have no strong feeling here either, but I think a single ack from ubuntu-release should be sufficient as it is for other exceptions. The wiki page mentions that the packages still have to go through https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages. 3) Universe used to have a later deadline for final freeze, to get latest bug fixes in. Past the deadline we used -proposed to get very late fixes in, handing over the queue to -sru. I think this could prove worthwhile again. Maybe we should replace universe with unseeded packages and decide later on it? Yes, I agree that this probably needs to be s/universe/unseeded/. I don't see any explicit mention of this on the wiki page, so I think the details can be hashed out closer to the release. WRT delegations: I think between Riddell and myself Kubuntu is already well covered. In the past I was the server team delegate for Universe, but the only purpose that served was to obviate the double ack rule. Since we're getting rid of that rule, I think there's no need. I woulnd't let getting delegation sorted out stop announcing thins. delegations also served to have the people with best knowledge cover an FFe. Teams not mentioned yet were we had delegates are: * mythbuntu * mozilla team * ubuntustudio * xubuntu * desktop (gnome) * netbook * edubuntu I'm not yet 100% sure how delegates fit in with the motu-release and ubuntu-release merge. I for one am happy to see the delegation process continue, at least for packages in universe (not to be confused with unseeded packages - obviously a mythbuntu or xubuntu delegate only makes sense for seeded packages :). I was never involved in delegate selection or observing closely how well particular delegated decisions worked, so I'll defer to you guys regarding who you think the delegates should be. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- 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 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
how can I get a working qprof?
Hi, I'm trying to install qprof through Synaptic Packet Manager, but it seems not to work at all. I've got ubuntu 9.10 (jaunty) on a x86_64 architecture From Synaptic, I downloaded qprof 0.5.2-5. But when I try to run qprof_start it turns out with: bash: qprof_start: command not found I also can't find /lib/qprof/alias.sh These are my dependancies installed: - debhelper 7.0.17ubuntu4 - libatomic-ops-dev 1.2+cvs20080819-1 - libpfm3-3.2-dev I also tried to manually install the package, but I got the following error In file included from prof_utils.c:36: atomic_ops.h:253:4: error: #error Cannot implement AO_compare_and_swap_full on this architecture. prof_utils.c: In function ‘QPROF_setup_signals’: prof_utils.c:326: warning: implicit declaration of function ‘AO_load’ prof_utils.c:328: warning: implicit declaration of function ‘AO_store_release’ prof_utils.c: In function ‘QPROF_format_pc’: prof_utils.c:398: warning: implicit declaration of function ‘AO_fetch_and_add1_acquire’ prof_utils.c:547: warning: implicit declaration of function ‘AO_fetch_and_sub1_release’ prof_utils.c: In function ‘add_sample’: prof_utils.c:586: warning: implicit declaration of function ‘AO_fetch_and_add1_release’ prof_utils.c:592: warning: implicit declaration of function ‘AO_store’ prof_utils.c: In function ‘QPROF_pc_sample_list_handler’: prof_utils.c:633: error: ‘struct sigcontext’ has no member named ‘sc_pc’ prof_utils.c:636: warning: implicit declaration of function ‘AO_fetch_and_add1’ prof_utils.c: In function ‘QPROF_pc_sample_list_write_q_profile’: prof_utils.c:881: warning: implicit declaration of function ‘AO_load_acquire_read’ make: *** [prof_utils.o] Error 1 what's wrong? can You help me finding a way to install qprof? thanks in advance kind regards Marco Marazza -- Marco Marazza marco.mara...@gmail.com -- 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
