Improving process of MOTU SRU requests that are no change rebuilds
Hello Folks, I'd like to discuss possibly modifying the MOTU SRU process to allow a wider group of individuals the ability to approve MOTU SRU requests that are simply no change rebuilds. From my experience on the motu-sru team, I've made a few observations: ~99.99% of rebuild requests pose minimal levels of risk; if a MOTU requests a rebuild he or she is usually involved in maintaining the package in question; and frequently the reason the rebuild is necessary is because of another SRU or security update (ex. xulrunner-1.9). So in the spirit of making life easier for everyone, I'd like to propose allowing all MOTUs the ability to approve SRU requests that are no change rebuilds. Optionally, we could also require that the MOTU approving must not be the MOTU requesting. Thoughts, Feedback? Cheers, -- Cody A.W. Somerville Software Systems Release Engineer Foundations Team Custom Engineering Solutions Group Canonical OEM Services Phone: +1-781-850-2087 Cell: +1-506-471-8402 Email: cody.somervi...@canonical.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Request to extend Xubuntu Release Delegation to include Lionel Le Folgoc (mr_pouit)
Hello MOTU Release Team, I'd like to request that the MOTU Release team bless and recognize the extension of release authority delegation for Xubuntu to Lionel Le Folgoc. Lionel is the Xubuntu Technical Lead as well as a Ubuntu Core Developer. With Lionel being so instrumental in the development and release management of Xubuntu, I have complete faith that Lionel is able to make sound decisions in regards to the many administrative release tasks and decisions presented durring this segment of the release cycle. If the MOTU Release Team or any one else has any objections, please let them be made known. Otherwise, I'd ask that the MOTU Release Team notify the appropriate teams (ie. Ubuntu Release Team, Archive Admin Team, etc.) of this extension once the required consensus is established. Cheers, -- Cody A.W. Somerville Software Systems Release Engineer Foundations Team Custom Engineering Solutions Group Canonical OEM Services Phone: +1-781-850-2087 Cell: +1-506-471-8402 Email: cody.somervi...@canonical.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Call for feedback: REVU header and notifications
Hello, On Sat, Feb 28, 2009 at 6:17 PM, Siegfried Gevatter (RainCT) < rai...@ubuntu.com> wrote: > Heya, > > Just two quick questions... > > First of all, I've been thinking for a while about changing REVU's > subtitle from «A Review Tool for MOTUs» to the more descriptive > «Collaborative Ubuntu Packages Reviewing»; if you have better ideas > let me hear, and if you think we shouldn't change it too (this > shouldn't really make a difference, but I was asked to get feedback on > this ML first as that line has been there forever). How about "Ubuntu's Collaborative Package Review Tool"? If you're going to name a thing, you can't use a verb - you need to use a noun. > Unrelated to this, Nathan Handler has asked that in the e-mail > notifications send out by REVU the subscribers should not be listed in > a "To:" field but instead as "Bcc:" to hide their e-mails. Personally > I disagree with this, as I like being able to quickly check who else > is interested in a package or know if some interested party has also > got a notification, and it also avoids having to go to Launchpad to > find the e-mail address of someone if you want to contact them > privately. I do not see privacy being a concern here as people > contributing to Ubuntu should be contactable and not be hiding their > e-mail address, it is available on Launchpad anyway (I'm not sure if > notifications are working for people who have set their email to not > be displayed) and if someone wants to harvest e-mails there are way > more efficient ways than subscribing to REVU packages (like looking at > the changelogs). However, I wanted to hear what other people think > about this. I completely agree with you. If you wish to contribute to Ubuntu, you need to be contactable and visible. If people want to hide their real life identity, their prerogative, the world wide web easily facilitates the creation of new identities. > Cheers, > > -- > Siegfried-Angel Gevatter Pujals (RainCT) > Ubuntu Developer. Debian > Contributor.<https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu> Nathan: Can you elaborate why you feel the way you do? Cheers, -- Cody A.W. Somerville Software Systems Release Engineer Foundations Team Custom Engineering Solutions Group Canonical OEM Services Phone: +1-781-850-2087 Cell: +1-506-471-8402 Email: cody.somervi...@canonical.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: New Application processes
On Thu, Jan 8, 2009 at 11:44 AM, Daniel Holbach wrote: > I see the mailing list discussion as a time for the MC (and everybody > else) to take a look at the application and to ask for clarification or > ask additional questions. > Will the council be voting at the IRC Meeting? Cheers, -- Cody A.W. Somerville Software Systems Release Engineer Custom Engineering Solutions Group Canonical OEM Services Cell: 506-449-5899 Email: cody.somervi...@canonical.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Thu, Jan 8, 2009 at 11:16 AM, Dustin Kirkland wrote: > On Wed, Jan 7, 2009 at 6:22 PM, Robert Collins > wrote: > > I completely agree. MOTU and core-dev membership is a combination of > > * technical knowledge [for which two key points apply: arbitrary > > have-done-X metrics don't assess any more reliably than peer assessment > > of the work done, and the knowledge ages rapidly as technologies change. > > Packaging of python today is not the same as it was 5 years ago]. > > * trust - which is entirely subjective > > * fitting in the team - which can be assessed by who objects :) > > Okay, so I'll restate my point in another way ... > > If there is *no* objective component to MOTU/CoreDev application > assessment, then I don't think it's fair to make arbitrary, > *quantitative* criticisms on an application. > > Criticisms of the form: > * You haven't done enough merges > * You haven't touched enough Universe packages > * You haven't been a MOTU or Developer long enough > * You haven't ... enough ... > should be invalid. > > These things are actually measurable, and we could very well set the > value of "enough". If we are consciously choosing *not* to set these > values, I think it's totally unfair to criticize someone for not > achieving these arbitrary, dynamic, mystery thresholds. I agree. In the same spirit of having a workbook, we could set guidelines and not hard fast rules. If we're going to have a workbook, we're setting some numbers anyhow. > > > :-Dustin > > -- > ubuntu-devel mailing list > ubuntu-de...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- Cody A.W. Somerville Software Systems Release Engineer Custom Engineering Solutions Group Canonical OEM Services Cell: 506-449-5899 Email: cody.somervi...@canonical.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Proposal: Move MOTU Applications back to ubuntu-motu ML
Hello, I'd like to propose that we move applications for MOTU back to ubuntu-motu. An important part of the application process is peer feedback/review and by moving the application e-mails back to ubuntu-motu mailing list, we increase the likelyhood of that occuring. Infact, I'd also like to propose that the motu-council mailing list allow only members of the motu-council to post to it *unmoderated*. So far, I've yet to see a discussion on motu-council that couldn't have happened on ubuntu-motu although I do acknowledge the usefulness of a mailing list to get in contact with the motu-council. Cheers, -- Cody A.W. Somerville Software Systems Release Engineer Custom Engineering Solutions Group Canonical OEM Services Cell: 506-449-5899 Email: cody.somervi...@canonical.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-sru needs you
Hi Devid, On Sun, Sep 28, 2008 at 5:50 PM, Devid Antonio Filoni <[EMAIL PROTECTED]>wrote: > Hi, > I propose myself as motu-sru member. I have free time to also do > moru-sru works and I think I will do a good job. I've worked at some > SRU, so I know the procedure and in some bug I've suggested if a bug > is a SRU or not (I'm unable to find links right now), etc... Thank you for taking the time to volunteer. > > > My launchpad profile: > https://launchpad.net/~d.filoni<https://launchpad.net/%7Ed.filoni> > My wiki page: https://wiki.ubuntu.com/DevidAntonioFiloni > > I will answer to any questions you will have for me. Can you provide a few (ie. 2-4) links to SRU bugs you've been involved with? Also, could you take one of the currently pending SRU bugs that you're not involved with and take us through the steps that you'd go through if you were already a member of the motu-sru team? > > > Thanks, > Devid Antonio Filoni > > > > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > Cheers, -- Cody A.W. Somerville Software Systems Release Engineer Custom Engineering Solutions Group Canonical OEM Services Cell: 506-449-5899 Email: [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Proposed Features for Launchpad Bugs 3.0 - call for help!
so that you can easily recognize it from mass of bug reports and other crap that makes it way through my inbox each day. 2.6 Now just shut up! :) With that all being said, it should be very easy to shut launchpad up including disabling bug mail that you might receive due to specific group memberships. 3. Project pages aren't as useful anymore I'm not a big fan of the new layout/look for project pages. I much much preferred the old one. The new one is so bland and contains very little information. 4. Associating teams/users with projects & ACL I use launchpad for non-ubuntu projects. I'd like to be able to associate a "team" with a project but not make it the registrant. Projects need some sort of "membership" functionality along with ACL so that you can associate people and teams with it. ex. Project Xyz has xyz-core-developers as the registrant. . xyz-core-developers is member of xyz-developers . xyz-developers owns the mainline branch . xyz-core-developers are associated with Project Xyz but not xyz-developers In this case, I should be able to (and want to) associate xyz-developers team with the project. 5. Speed As others have mentioned, speed needs to be addressed pronto. Although, this is far from the biggest issue for me as I guess I'm used to slow being a Xubuntu dev and all. = Top 15 = CaptureDistroSeriesWhenFilingBugs || UI to allow the user to say "I don't know/Hardy/Intrepid/..." MaloneMeToo|| Being able to say and record "this bug affects me to" Crash reporting|| Provide a repository of crashes linked to bug reports, possibly integration with Breakpad? Bug Activity UI Interleaving || Displaying activity in the comments view Code review UI || Allow code review of patch attachments, feature-parity with Bugzilla Quick summary/description/tags editing || Allowing people to change these fields without two pageloads Better package name UI guidance|| If the user selects "don't know" then lead him to an explanation CompleteActivityLog|| Ensuring bug activity captures all bug changes Import a remote bug UI || One-push importing and task-annotation from Debbugs & Bugzilla TagDiscipline || Actually using OfficialBugTags for something! ExplicitSearchFilteringAndCleanURLs|| Let users see and understand what search filters are on, and clean up default search URLs FixingIrrelevantComments || Marking and hiding irrelevant comments. BugFreezing|| Marking a bug as frozen, disallowing new comments from non-bug-team-members CollectingBugStatistics|| Pre-requisite for the triage report and useful to external report builders Bugtask forwarding relationships || Mark bugs as needing to go upstream = Runner Ups = Workload estimation || Story points/hours Flip Incomplete to New || Automatically flip bugs from Incomplete when information is provided Negated Tags in Searches|| Allow searching for bugs with some tags, but without others Email first-time bug-reporters || A welcome message and guide to triaging process IgnoreSubscriptionsRevenge || Unsubscribing implicit subscribers from specific bugs = Depends on how it works = Proactive bug imports || Enabling complete syncs from plugin-enabled sites Package-specific reporting guidelines || Bonus points for a syntax for including screenshots No more Confirmed || With Me Toos and Triaged, removed this confusing status Expired bugs || Allowing us to track expired bugs separately from invalid, including a textual rationale Qualifying bug reporters || Redirect non-qualified people to answers; based on Karma, Ubuntu Members, Referees, etc. Version-tracking of bugs || Being able to specify that a bug is present or was introduced in version X, and later fixed in version Y (*) = DO NOT WANT AT ALL = Timebomb New bugs || After 6/N months, all New bugs become Incomplete -- Cody A.W. Somerville Release Engineer Canonical OEM Solutions Group Cell: 506-449-5899 Email: [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Announcing Michael Casadevall as an Xubuntu Developer
Hello Developers, I'd like everyone to give a warm welcome to Michael Casadevall ( https://launchpad.net/~sonicmctails <https://launchpad.net/%7Esonicmctails>) who (after impressing me with his kung-foo) is joining the Xubuntu Team as a Xubuntu Developer. Michael is an exceptionally dedicated individual with a strong, diversified pool of talent and skill who is eagerly working towards becoming a MOTU. Michael, an Xfce4 user for close to a year, will be assisting us with general packaging and development tasks for the most part but I'm sure his keen ability to fix FTBFS; experience with ports, debian, and gnome; and demonstrated initiative in other teams to identify and refine infrastructure and processes for the better will be a huge asset to our team. In fact, I think Michael is tackling packaging the unreleased alpha of xfce 4.6 into our team PPA as we speak :-). You can contact Michael via e-mail at [EMAIL PROTECTED] or tackle him on IRC in #xubuntu-devel (look for NCommander). Cheers, -- Cody A.W. Somerville Release Engineer Canonical OEM Solutions Group Cell: 506-449-5899 Email: [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
MOTU SRU Team wiki page
Hello MOTU, Contributors, and fellow MOTU-SRU members, I quickly put together a wiki page for the MOTU SRU team to allow for us to easily schedule meetings and keep track of issues we face along with the resolutions we've arrived at. You can visit it and help make it more awesome by directing your browser to https://wiki.ubuntu.com/MOTU/Teams/SRU Along with getting this team page setup in the wiki, I'd like to see about organizing a MOTU SRU meeting so that we can all touch base. How does August 7th @ 1600 UTC sound to everyone? Cheers, -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
MOTU Meeting Minutes for July 25th, 2008
Hello Folks, You can find the meeting minutes for the MOTU Meeting held this previous July 25th, 2008 at https://wiki.ubuntu.com/MOTU/Meetings/2008-07-25 The current minutes, as written by myself, are as follows: *MOTU Meeting Minutes for 2008-07-25* == *MOTU Leadership Teams - Membership Policy Discussion Cnt'd*. == >From the last meeting (https://wiki.ubuntu.com/MOTU/Meetings/2008-07-11), CodySomerville and StefanPotyra collaborated to bring forth a summary as promised of the MOTU Leadership Teams Membership Policy Discussion which can be found at https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004227.html At this meeting, StefanPotyra agreed to chair, CodySomerville agreed to write the minutes, and EmmetHikory agreed to write a proposal to -MOTU. Vibrant discussion continued regarding the MOTU Leadership Teams Membership Policy. In contrast to previous discussions, a growing preference for, rationalized by a desire and proposed higher need for working teams rather than bureaucratic accuracy, a system that avoids voting was evident. Others, however, felt that such a system would be ill-defined, inherently more complex, and questionable as voting is used to measure the legitimacy of the leadership teams. The proposal wrote by EmmetHikory can be found at https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004278.html Cheers, -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
REMINDER: Ubuntu MOTU Meeting Friday, July 25th 2008, 20:00 UTC
Hello MOTU, A friendly reminder of the fast approaching *Friday, July 25th 2008, 20:00 UTC* meeting. The meeting agenda is currently empty but the canonical copy where additions can be made is found at https://wiki.ubuntu.com/MOTU/Meetings Cheers, -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
REVU: New: codeblocks 8.02-0ubuntu1 (source)
-- Forwarded message -- From: Ubuntu Installer <[EMAIL PROTECTED]> Date: Sat, Jul 19, 2008 at 1:20 AM Subject: New: codeblocks 8.02-0ubuntu1 (source) To: "Cody A.W. Somerville" <[EMAIL PROTECTED]> NEW: codeblocks_8.02.orig.tar.gz NEW: codeblocks_8.02-0ubuntu1.diff.gz NEW: codeblocks_8.02-0ubuntu1.dsc -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 17 Jul 2008 04:39:23 + Source: codeblocks Binary: libcodeblocks0 codeblocks codeblocks-dbg libwxsmithlib0 codeblocks-contrib codeblocks-dev libwxsmithlib0-dev Architecture: source Version: 8.02-0ubuntu1 Distribution: intrepid Urgency: low Maintainer: Ubuntu MOTU Developers Changed-By: Michael Casadevall <[EMAIL PROTECTED]> Description: codeblocks - Code::Blocks integrated development environment (IDE) codeblocks-contrib - Contrib plugins for Code::Blocks IDE codeblocks-dbg - Code::Blocks debugging libraries codeblocks-dev - Code::Blocks development files (SDK) libcodeblocks0 - Code::Blocks shared library libwxsmithlib0 - wxSmith shared library (wxSmith is a Code::Blocks plugin for RAD libwxsmithlib0-dev - wxSmith development files Launchpad-Bugs-Fixed: 105428 Changes: codeblocks (8.02-0ubuntu1) intrepid; urgency=low . * Inital Release based off existing codeblocks debian folder (LP: #105428) * Modify Maintainer from original debian folder to match the DebianMaintainerField specification. * Added 01_codeblocks_plugin_path.dpatch to move the plugins path Files: e17e11cf8887acb52140f521d3e7c328 884 x11 optional codeblocks_8.02-0ubuntu1.dsc e34f8918f81041dc411d3fa756dee631 8326851 x11 optional codeblocks_8.02.orig.tar.gz 1dee418841cc6cdb6e139b5984268935 5456 x11 optional codeblocks_8.02-0ubuntu1.diff.gz Original-Maintainer: Yiannis Mandravellos <[EMAIL PROTECTED]> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIgWo3tBZf7PTGAzIRApv1AKDFl2crvewqTFNYHYJlMx5g5TDRnwCePvh8 zoQ0ZxuVkgfwROH9Nck8Qjw= =y8H4 -END PGP SIGNATURE- Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the overrides about once a week. You may have gotten the distroseries wrong. If so, you may get warnings above if files already exist in other distroseries. -- You are receiving this email because you are the uploader, maintainer or signer of the above package. -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU Leadership Teams - Membership Policy
On Thu, Jul 17, 2008 at 10:09 AM, Neal McBurnett <[EMAIL PROTECTED]> wrote: > On Thu, Jul 17, 2008 at 08:20:36AM -0300, Cody A.W. Somerville wrote: > > * Normal elections will start at an agreed date relative to a > development > > milestone and polls will remain open until a second agreed date that is > also > > relative to a development milestone. Once polls close, results will > become > > available and a short period to allow for grievances and/or disputes to > occur > > takes place. Finally, a third agreed date, which will also be relative to > a > > development milestone, will mark the normal conclusion with the MOTU > council > > officially announcing results and updating team memberships. If a > grievance of > > dispute arises, the MOTU council will resolve the issue in 15 days of the > third > > date or escalate the issue to the technical board. > > > > Although a voting system has not been agreed upon yet, two systems which > have > > received a lot of discussion include Single Transferable Vote (used by > some > > governments) and the Schulze method (used by Debian and Wikipedia among > > others). It is generally agreed that a preferential voting system, where > voters > > would rank their preference of the candidates instead of voting for or > against, > > is best. > > I've been active in voting method discussions for a few decades now. > If we go with elections, my advice is to go with either Approval > Voting or Range Voting. One benefit of them is the focus on > "supporting" folks (rather than a competition among folks), which can > contribute to a feeling of consensus. > > http://en.wikipedia.org/wiki/Approval_voting > http://bcn.boulder.co.us/government/approvalvote/center.html > http://en.wikipedia.org/wiki/Range_voting > > I don't know if I agree with that. The reason why I feel a preferential system, in particular STV, is a good fit for us is because you never vote against someone like you would in approval voting (by not voting) - you simply express your preference of one candidate over another. I feel this is mandatory because it should be a requirement to becoming a MOTU that you *could* be able to fill these roles. As for range voting, that is a plausible idea but both range voting and approval voting are classed as single seat (ie. used to elect single individual) system whereas STV is a multi-member system. > I'm not sure why STV is on the list since it is for party voting - do > we have parties in MOTU now? I mean besides the great festive > gatherings that Daniel organizes? ;-) Single Transferable Vote is *not* for party voting. Infact, it *explicitly* ensures votes are for candidates and not parties. STV is on the list because is a preferential voting system designed to minimize wasted votes and provide proportional representation. > > > The ranked methods like IRV (and STV) and Schulze suffer from > increased complexity and confusion, and the risk of counter-intuitive > results. E.g. with IRV it is possible that raising the rank of a > winning candidate on some ballots, which originally had ranked that > candidate last, could counter-intuitively result in the winning > candidate becoming a loser. See > > http://en.wikipedia.org/wiki/Instant-runoff_voting > http://en.wikipedia.org/wiki/Schulze_method > http://en.wikipedia.org/wiki/Single_transferable_vote Yes, this is called the monotonicity criterion. IRV and STV both fail this criterion but Schulze method does not. However, I don't think we need to get caught up in weird corner cases due to the scale and nature of the elections we'll be holding. > > > > An alternative proposal by Emmet Hickory would have members be attached > to a > > "release" and favors replacing team members through a process more > > closely related to apprenticeship than any sort of election. The team > would > > define goals for a release, handle freeze exceptions for the release, and > then > > follow the release as the SRU team until the release is no longer > supported > > (all together, roughly terms of 2 years). His full e-mail can be found > here: > > https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169. > > Make that > https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169.html > > Neal McBurnett http://mcburnett.org/neal/ > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
MOTU Leadership Teams - Membership Policy
Hello, At the last MOTU Meeting, plenty of healthy and constructive discussion occured regarding membership policy in MOTU Leadership Teams. However, it was determined that the issue did not yet have a concrete proposal for any sort of decision making process to move forward with. I have developed the following summary of the different proposals based on the mailing list archives, IRC chat logs, and a summary that Stefan Potrya prepared. Currently, the MOTU community feels that it is beneficial to delegate certain responsibilities and permissions to a subset of trusted individuals; for example the MOTU Release Team and Universe Stable Release Update Team. Since these bodies represent and act on behalf of MOTU-at-large, it is argued that for these leadership teams to be legitimate that they must accurately reflect the MOTU via an electoral process. Others feel alternative solutions would instead be optimal. Regardless, over the last few releases, the methodology used to populate these teams has been inconsistent. It is desired that a standard practice/policy be adopted. Initial discussion on this topic in June began with modifying the electoral system we've used in the past (voters vote yes or no for candidates and candidates who have the highest net count would be appointed OR candidates would have to achieve a certain percentage of approval). Strong consensus was reached on all major points except for the actual voting system to be used. * Terms will be in the length of two release cycles which will usually work out to be roughly 12 months. * Individuals interested in serving on a team will nominate themselves by e-mailing their intentions to ubuntu-motu. The MOTU Council will make a call for nominations 15 days before polls open. * To allow for new individuals to get involved in the leadership teams and to ensure minimal disruption between terms, only a subset of the team will be up for re-election at the end of each release cycle. This will either be accomplished by holding a second election on the second release this policy is adopted or by designating certain members of first election to serve an extra release cycle. * If a member if not able to complete their term, they will be able to resign and the runner up in the election will be appointed to serve the remainder of the term. If a runner up is not available, the team may choice to optionally replace the resigning member with an appointment of their choice. If the latter occurs, any MOTU may veto the appointment by filing grievance with the MOTU Council whom will allow the team to either leave the position vacant or call a by-election. * Normal elections will start at an agreed date relative to a development milestone and polls will remain open until a second agreed date that is also relative to a development milestone. Once polls close, results will become available and a short period to allow for grievances and/or disputes to occur takes place. Finally, a third agreed date, which will also be relative to a development milestone, will mark the normal conclusion with the MOTU council officially announcing results and updating team memberships. If a grievance of dispute arises, the MOTU council will resolve the issue in 15 days of the third date or escalate the issue to the technical board. Although a voting system has not been agreed upon yet, two systems which have received a lot of discussion include Single Transferable Vote (used by some governments) and the Schulze method (used by Debian and Wikipedia among others). It is generally agreed that a preferential voting system, where voters would rank their preference of the candidates instead of voting for or against, is best. An alternative proposal by Emmet Hickory would have members be attached to a "release" and favors replacing team members through a process more closely related to apprenticeship than any sort of election. The team would define goals for a release, handle freeze exceptions for the release, and then follow the release as the SRU team until the release is no longer supported (all together, roughly terms of 2 years). His full e-mail can be found here: https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004169. 1. Do we still agree with the items in the list above or do you prefer Emmet's proposal? 2. If yes, what voting system should we use? If no, we should work on elaborating Emmet's proposal. 3. If you're not sure what voting system we should use, you might pick the one you best understand. Cheers, -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: policy for membership in MOTU key teams
On Thu, Jul 3, 2008 at 3:06 AM, Scott Kitterman <[EMAIL PROTECTED]> wrote: > On Wednesday 02 July 2008 18:31, Cody A.W. Somerville wrote: > > On Wed, Jul 2, 2008 at 5:29 PM, Scott Kitterman <[EMAIL PROTECTED]> > > > > > In my experience Condercet methods work quick well with multiple selection > votes too and retain their resistance to strategic voting. In either case > we > wouldn't count it by hand, so the complexity of counting isn't a > significant > factor. > > Yes, Debian does like the fancy charts to prove they got a correct result. > Here is an example (another election I was in) that shows how easy it is: > > > http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_8e5a1ca7f86a5d5d<http://www.cs.cornell.edu/w8/%7Eandru/cgi-perl/civs/results.pl?id=E_8e5a1ca7f86a5d5d> > > I'd rather just use the best system to begin with rather than have to worry > about when we need to change. How is a Condorcet system superior exactly? According to the Gibbard-Satterthwaite theorem, tactical voting is possible in all non-dictatorial deterministic voting systems. I fail to see how it is more resistant to strategic voting (I can describe a number of methods for you). Furthermore, the small number of methods of tactical or strategic voting that does exist for elections conducted using STV in general only are effective in marginal district... but do we really need to worry so much about strategic voting? Strategic voting really comes into play when there are "parties" involved (we don't have that). And do we want an individual least un-preferred (Condorcet) or most preferred (STV)? The biggest fault that I can see with STV would be that it fails the monotonicity criteria but it is important to note that *no* preference voting system satisfies all the criteria described in Arrow's impossibility theorem. For example with Schulze (the actual system I think you're proposing) it fails to meet independence of irrelevant alternatives, participation, consistency, invulnerability to compromising, invulnerability to burying, and later-no-harm criteria. And to hit the simple point home a bit more, don't you think we'd all have a bit more faith in a system that we could actually figure out the result on our own? Personally, I don't want my vote going into some black box which magically produces a set of winning candidates. I'm not suggesting that STV is the choice we go with but I don't think Condorcet is either "just because". > > > Scott K > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: policy for membership in MOTU key teams
On Wed, Jul 2, 2008 at 5:29 PM, Scott Kitterman <[EMAIL PROTECTED]> wrote: > On Wednesday 02 July 2008 07:29, Cody A.W. Somerville wrote: > > Hello, > > > > > > > This is probably the toughest part to figure out: "How the voting works". > > ... snip > > Actuall I think it's not. There is a lot of research supporting the > http://en.wikipedia.org/wiki/Condorcet_method and services that support > it. > It's a little complex in the theory, but actual voting is just ranking your > preferences. > > Scott K > For those not familiar, the Condorcet method is the method used by Debian. Personally, I'm not overly familiar myself but I've attempted to do some research for the benefit of the crowd. What benefits does the Condorcet method provide over Single Transferable Vote? From what I see, both systems are preferential voting systems however the Condorcet method is exceedingly more complex than STV and is classed as a single member system (ie. engineered to elect one member) where STV is classified as a multi-member system. Although STV suffers from the issue of sequential exclusions (meaning that sometimes STV eliminates at an early stage in the count a candidate who might have gone on to be elected later had they been allowed to remain in the contest), there have been a number of recent refinements to STV such as CPO-STV and Sequential STV which solve the problem by incorporating elements of the Condorcet methods into STV. Alternatively, a method known as BTR-STV deals with the problem with a completely different (but exceedingly more simple than the other systems) solution by simply making sure no candidate could possible be eliminated. On the other hands, a neat feature of Condorcet is that it is possible for a candidate to be the most preferred *overall* without being the first preference of on any of the ballots yielding a compromise candidate whom the largest majority will find to be the least disagreeable even if not their top pick. This may or may not be desired (I'm not sure). So what *is* the "Condorcet method", well it isn't actually *a* method but a set of criteria. When people refer to the Condorcet method, they are talking about any single-winner election method that meets the Condorcet criterion. What is the criterion? Basically that the system has to always selects the Condorcet winner. What is the Condorcet winner? It is he candidate who would beat each of the other candidates in a run-off election (there is actually a few different types of run-off elections to boot but in this context I would describe it as the guy who gets the majority votes if everyone voted on only those two people) . In modern examples, voters rank candidates in order of preference but things get very tricky from there as there is need to resolve circular ambiguities. This situation emerges when, once all votes have been added up, the preferences of voters with respect to some candidates form a circle in which every candidate is beaten by at least one other candidate. An example borrowed from wikipedia is if there are three candidates, Alex, Cody and David, there will be no Condorcet winner if voters prefer Alex to Cody and Cody to David, but also David to Alex. Frustratingly, depending on the context in which elections are held, circular ambiguities may or may not be a common occurrence . Now, if the Condorcett method is meant to elect a single member only how would we use it? Well, it will actually produce a list and I'd suppose we'd pick the number the highest ranking individuals? Erm... maybe? I suppose it depends on the exact system used. Earlier I said that Debian uses the Condorcet method but now you must be wondering which method they *really* use now that you know what Condorcet is really all about. The name is "the Schulze method", aka Schwartz Sequential Dropping (SSD), Cloneproof Schwartz Sequential Dropping (CSSD), Beatpath Method, Beatpath Winner, Path Voting, and Path Winner. In this system, each ballot contains a complete list of all candidates and the individual voter ranks this list in order of preference. Generally, ascending numbers are used, whereby the voter places a '1' beside the most preferred candidate, a '2' beside the second-most preferred, and so forth. Sounds like how one might vote on a Single Transferable Ballot, no? Just wait... it isn't so simple. Voters may give the *same* preference to more than one candidate and *may keep candidates unranked*. If the latter occur (ie. doesn't rank all candidates) then it is assumed that all ranked candidates are strictly preferred to those that he or she did not rank and indifferent between the non-ranked candidates. Then to determine the actual winner (this is a single-member system remember), it determines the "strongest path". The following is from wikipedia:
Re: policy for membership in MOTU key teams
tes: Brad, Andrea, Carter, Jennifer, Delilah, Scott 1 Voter votes: Brad, Andrea, Carter, Scott, Jennifer, Delilah 20 Voters vote: Delilah, Scott, Jennifer, Brad, Carter, Andrea 20 Voters vote: Scott, Delilah, Jennifer, Carter, Brad, Andrea 17 Voters vote: Jennifer, Delilah, Scott, Andrea, Carter, Brad This would give the following tally: Andrea: 31 Carter: 30 Brad: 2 Delilah: 20 Scott: 20 Jennifer: 17 When first preferences are tallied Andrea and Carter have reached the quota and are declared winners. With droop, Andrea has 10 surplus votes and Carter 9. These surplus votes would go to Brad as Brad is the next available preference listed. This would give us the following tally: Brad: 2 + Andrea's surplus (10) + Carter's Surplus (9) = 21 Delilah: 20 Scott: 20 Jennifer: 17 Brad has now reached a quota and is declared elected. He has no surplus so Jennifer, who this time has the fewest votes, is excluded. Because only Delilah and Scott are left in the count, and there are only two seats left to fill, they are both declared elected. The result being that Andrea, Carter, Brad, Delilah, and Scott get elected. If we instead go with the B-H quota (which we determined earlier to be 20), then the election would be a different story. The original tally is: Andrea: 31 Carter: 30 Brad: 2 Delilah: 20 Scott: 20 Jennifer: 17 Andrea, Carter, Delilah, and Scott would all be declared winners in the first tally. Andrea's (11) and Carter's (10) surplus (21) would still go to Brad. Delilah and Scott do not have a surplus. This would give the following tally: Brad: 23 Jennifer: 17 Brad has met the quota and is declared a winner. The result of the election is Andrea, Carter, Delilah, Scott, and Brad being elected (the same as with the Droop quota). However, what about a situation where all six get elected? Same scenario, different votes: 28 Voters vote: Andrea, Carter, Brad, Delilah, Scott, Jennifer 30 Voters vote: Carter, Andrea, Brad, Scott, Delilah, Jennifer 1 Voter votes: Brad, Andrea, Carter, Jennifer, Delilah, Scott 1 Voter votes: Brad, Andrea, Carter, Scott, Jennifer, Delilah 22 Voters vote: Delilah, Scott, Jennifer, Brad, Carter, Andrea 21 Voters vote: Scott, Delilah, Jennifer, Carter, Brad, Andrea 17 Voters vote: Jennifer, Delilah, Scott, Andrea, Carter, Brad Andrea, Carter, Delilah, and Scott are declared winners in the first tally. Andrea and Carter have a surplus of 16 which goes to Brad. Delilah and Scott have a surplus of 3 which ends up going to Jennifer. This gives us the following second tally: Brad: 20 Jennifer: 20 Either both are declared winners or STV calls for one to randomly be selected. To prove that Droop doesn't allow this, note that the Droop quota is 21 and not 20. This means that although Andrea, Carter, Delilah, and Scott are still declared winners the first tally. The surplus to Brad would instead be 16 and the surplus for Jennifer would be 1, resulting in the following: Brad: 2 + 16 = 18 Jennifer: 17 + 1 = 18 Oh, whats this?! A tie? Yes, but neither meet the quota. In this case, either tie procedures come into place or (my preference) we decide that neither candidate is elected since they didn't meet the quota. === Single Non-Transferable Vote === An alternate to STV would be Single *non*-transferable vote where we would only vote once for the individual most preferred. Candidates would be given available seats in order of number of votes. So if we have three seats and five candidates (a, b, c, d, and e) and there are 100 votes cast with the a - 30, b - 20, c - 19, d - 21, and e - 10 then candidates a, d, and b would be declared the winners. This only provides semi-proportional representation by definition but would be less likely in our case due to small scale we're dealing with. === Block Approval Voting === A third alternative would be block approval voting - a simple variant on block voting where each voter can select an unlimited number of candidates and the candidates with the most approval votes win - where you would vote yes or no for each candidate. This does not provide proportional representation and is subject to the Burr dilemma<http://en.wikipedia.org/wiki/Burr_dilemma>, among other problems. Although approval voting is the system we've used in the past, it is really an abuse of the approval system as approval voting is not meant to be multi-member. > > Emilio > As I stated already, I'd like to propose the single transferable ballot with either the Droop or H-B quota. What happened to the thing I said about KISS? Well, although the two other alternatives I presented *are* more simple it also sacrifices the traits that make (IMHO) STV so favourable. STV is a preferential, proportional representative voting system that is relatively simple, allows us to minimize wasted votes, scales well to the multi-member task, and even provides us with an easy way to replace individuals (when more candidates then seats run) who aren't able to fill their entire term. Anyhow, I didn't origianlly intend for this e-mail to be this long so I do hope someone reads it, lol. Maybe I'll transfer the gist of it to a blog post. Cheers, -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU-SRU Meeting (was: motu-sru extension)
On Tue, Jun 10, 2008 at 11:29 PM, Scott Kitterman <[EMAIL PROTECTED]> wrote: > On Tuesday 10 June 2008 18:50, Luke Yelavich wrote: > > On Sun, Jun 08, 2008 at 10:03:10PM EST, Luca Falavigna wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > Cody A.W. Somerville ha scritto: > > > > As for a meeting, I'd love to get one done ASAP (I'm sure the rest of > > > > the team is ready to rock and roll too). I'm unfamiliar with your > guy's > > > > schedule but mine is very flexible. Please feel free to pick a > > > > tentative date and we can go from there. > > > > > > Given that we live in different timezones (Luke in Australia, Stephan > > > and I in Europe and the rest of the team in U.S.), it will be hard to > > > find a suitable date for everyone. > > > > > > E.g. if we choose 20 or 21 UTC, there could be room to attend everybody > > > (it will be early in Australia, though). > > > > I would much prefer 21:00UTC, which is 7AM my time, and preferably during > > the week. > > > > Luke > > If we do it then, I can be there for about 45 minutes. That should be > plenty. > > Scott K How about June 16th? (June 17th for Luke) Cheers, -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
MOTU-SRU Meeting (was: motu-sru extension)
On Sat, Jun 7, 2008 at 2:06 PM, Luca Falavigna <[EMAIL PROTECTED]> wrote: > > > > I have added Cody Somerville, Scott Kitterman, and Stephan Hermann > > as new members of MOTU SRU. Please welcome them to the team. > > Welcome aboard! Can we schedule a short meeting to discuss what we can > do to improve our workflow and to examine difficulties we faced? > > Hey, thanks :) As for a meeting, I'd love to get one done ASAP (I'm sure the rest of the team is ready to rock and roll too). I'm unfamiliar with your guy's schedule but mine is very flexible. Please feel free to pick a tentative date and we can go from there. Cheers, -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-sru extension
On Tue, Jun 3, 2008 at 8:44 PM, Chuck Short <[EMAIL PROTECTED]> wrote: > > Hi, > > I would just like to make a suggestion if you wish to expand the team > then it should cover different timezones since the motu-sru might not > always be available. Why is that nessary? When is a member of the SRU team ever needed *immediately*? If that is the case, I don't mind giving out my phone number (if I'm placed on the team). > > > Regards > chuck > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: wanted: motu-sru members
I'd be interested in volunteering if more volunteers are required. On Fri, May 30, 2008 at 7:47 PM, Stefan Potyra <[EMAIL PROTECTED]> wrote: > Hi again, > > thanks for more volunteers. > > Siegfried: Having no big track of sru history doesn't imho warrant that you > couldn't be a member of motu-sru. Do you also volunteer? > > So, how do we proceed now? > > I'd say, we extent the deadline until tomorrow (31.05.08), 20.00 UTC. If > there > should be more than two volunteers (it looks like we need to replace two > members right now), I'd call for a vote then. Otherwise, let's just add the > members to the team on Monday, at 20.00h UTC unless anyone disagrees with > that. > > Any objections? > > Cheers, > Stefan. > > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > > -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: sabbatical
Hey Jordon, It has been a pleasure working with you. I'm hoping we can stay in touch and I wish you the best of luck with your PhD! Cheers, Cody For those of you subscribed to the -motu list that don't know Jordan Mantha, Jordan has done some amazing work over the years. He'll definitely be missed and his lack of presence felt. If you see him on IRC, be sure to give him a big hug and thank you. If you have time, be sure to ask him about the top secret labs at the Department of Education :) On Wed, May 14, 2008 at 5:54 PM, Jordan Mantha <[EMAIL PROTECTED]> wrote: > Hello MOTU Land, > > It has really come to my attention that I need to have a sabbatical time > away from Ubuntu development. For people who know me this is no surprise as > I've been struggling to get my PhD and "real life" in better order for > better than a year now. In recent weeks I've felt increasingly frustrated > with some aspects of Ubuntu development and community and I feel like for > the betterment of myself and the community I should take some serious time > off. I'm very hopeful that I'll be able to come back at some point so I'm > considering this a sabbatical and not a goodbye. > > Because I'm a firm believer in the Ubuntu Code of Conduct and have a couple > of leadership positions within MOTU I'm writing this email as a part of > "Step down considerately". Right now I act as the MOTU/LP liaison and a > member of the MOTU SRU team, but I will step down from those positions as > soon as replacements are found and/or current work is finished. > > I cherish the time I've had to work with you all and count many of you as > some of my very best friends. Good luck with Intrepid. > > -Jordan Mantha > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > > -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Fax: 506-453-9112 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: NEW Packages process
On Wed, Apr 16, 2008 at 9:40 AM, Daniel Holbach <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Cesare Tirabassi schrieb: > > Its not a question of trust, its a question that 4 eyes see better than > 2. I > > know I don't rely on my packaging skills alone, no matter how much I > work I > > will always miss something. > > Right. That happens to upstreams, happens to uploads of existing > packages and happens in uploads of new packages. Whenever somebody is > made member of ubuntu-dev they have the chance to break packages (and > embarrass themselves) with every single upload. > > I guess my question is two-fold: 1) how can we improve our existing ways > to collaborate on packaging to be less error-prone, 2) why do we deem > the reviewing of new packages different than uploading for example new > packages versions, etc.? > > > >> Is the quality of packaging our main concern? > > > > Definitively. > > Then what can we do to improve it? Is "I will have to ask my colleague" > the only way to do that? > > > > Very good example, and a showcase of why devs are not very keen in > reviewing. > > First, the contributor missed even the more fundamentals of a package > (other > > examples are native packages which are not, wrong standards, wrong > > distribution, etc.), so the reviewer instead of spending a whole morning > > reviewing the package just points out the more obvious (I would and > never > > have done this by the way, this is a side product of having one reviewer > > trying to "triage" a long queue). > > I picked the example to illustrate that sometimes trivialities which > don't really have a large impact block the upload. > > > > Even then the contributor waits two weeks > > to make a fix which just takes 5 minutes at the most. Is he really > interested > > in packaging? If I were the reviewer I don't think I will want to spend > my > > time in reviewing things that will eventually just get thrown out of the > > window. > > If I submitted a package, had to wait weeks to get it reviewed, then got > a reply "please fix this triviality" I wasn't sure if I made it my first > priority to come up with a fix. > > > > By the way, how will lowering the required acks to one solve the above > > example? > > If the reviewer feels empowered to make the decision right now and the > contributor is responsible for incoming bugs, chances are higher to > directly come to the beef of the packaging problems. > > > > Should I ack a package that I know doesn't meet the required standards? > I, for > > one, will not want to see Universe become another automatix or > deb-o-matic. > > The right approach here (and this is quite often used) is to say: this > is > > wrong but I'm not blocking for this so that the contributor knows about > it > > (and a good contributor will upload a fix shortly after). > > Right, not-blocking-but-mentioning makes perfect sense. > > > > Having gone very recently through this, yes, it adds frustration and is > as > > much a fault of the contributor as of the reviewer. By lowering the bar > we > > are not doing anyone a favour, just lowering the quality of the archive. > > I still believe that saying "one MOTU's decision is not enough" does not > fix the problem and that there are better ways to get high quality > packages into the archive and have responsive people fixing them as > problems come up. One of the reasons Open Source software *works* is because it employs the scientific method. That process relies heavily on peer review. I don't think we should remove that, discourage that, or ever consider it unimportant. If everyone had unlimited time and resources, I would get every single one of my packages reviewed. No, not because I don't think I'm not competent enough to make the upload myself alone but because I consider peer review the corner stone of our development model. Maybe the issue here isn't a philosophical one but more of a technical one? Maybe we should focus, as you suggested, on improving and innovating review infrastructure? > > > Have a nice day, > Daniel > > - -- > My 5 today: #210449 (network-manager-applet), #215043, #193764 > (evolution-scalix), #215472 (gnome-themes-extras), #205756 (gnome- > subtitles) > Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIBfPSRjrlnQWd1esRAsC7AJ993DNk9MgkZHsRj6NU
Re: Changes to the Universe Development team structure
If we move forward with this (*coughs* see #ubuntu-motu and following e-mails *coughs*), then this team should be a member of the ubuntu bug control team (ie. allowing them to set importance level, etc.). This would mean that the minimum requirements for joining the group would have to be heightened though to include the prerequisites of the ubuntu bug control team. However, I don't think that'll be a problem as it sounds like the perfect candidate for this team would already be (or should be) a member of the ubuntu bug control team. Thanks, Cody On Thu, Apr 3, 2008 at 11:07 AM, Emmet Hikory <[EMAIL PROTECTED]> wrote: >In recognition of the growing number of developers, a new > development team is being introduced to provide further granularity of > entitlements within Ubuntu Development: the Universe Hackers (Ubuntu > Contributing Developers) (1). This team is intended to include all > who have been actively involved with universe development for some > time, have provided significant contributions, and have a sustained > commitment to the development community. > >All current MOTU have been added to this team (indirectly), and > new members are encouraged to apply by sending mail to > [EMAIL PROTECTED] with a reference to their updated wiki > page, indications of other current team members willing to sponsor > their membership, and their plans for future activity. Applicants are > expected to meet the following criteria: > > * Have been working with Ubuntu development for some time, with a > number of bugs fixed in the archives > * Have a close working relationship with other members of the Ubuntu > community > * Have a clear plan for future activity > * Have updated their wiki page to meet the criteria listed on > https://wiki.ubuntu.com/NewMemberHowto > >While the specific entitlements granted to this team are still > expanding, the intent is to allow most development activities that do > not specifically require upload to the archives or extensive > experience with package management to be performed by members of this > team. In addition to other efforts underway, I would like to > encourage anyone maintaining a VCS for Ubuntu packaging of a universe > package to consider using this team in place of ~ubuntu-dev as a > source of acceptable committers. Further, if anyone has any specific > suggestions of other entitlements that should properly belong to this > team, please reply here, or raise in a MOTU Meeting. > >Along with this new team, the previous Contributors of packages > for ubuntu universe team (ubuntu-universe-contributors) is undergoing > a rename to "Universe Code Monkeys" (~universe-code-monkeys), and a > transition is planned for existing members to expire after six months > have passed. All members of the Universe Hackers and all Ubuntu > Developers will remain members, and anyone whose membership expires > will be welcome to rejoin (although those working on packaging for > greater than six months are definitely encouraged to become Universe > Hackers). This should significantly reduce the REVU keyring sync > delay, and may grant other entitlements in the future. > > 1: https://wiki.ubuntu.com/UbuntuDevelopers > > -- > Emmet HIKORY > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > -- Cody A.W. Somerville Software Engineer Red Cow Marketing & Technologies, Inc. Office: 506-458-1290 Toll Free: 1-877-733-2699 Cell: 506-449-5899 Email: [EMAIL PROTECTED] http://www.redcow.ca -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: 'cd' in debian/rules
Hi Matt, Use the "-c" option of make. >From the manfile: -C dir, --directory=dir > Change to directory dir before reading the makefiles or doing > any‐ > thing else. If multiple -C options are specified, each is > inter‐ > preted relative to the previous one: -C / -C etc is > equivalent to > -C /etc. This is typically used with recursive > invocations of > make. > Thanks, Cody A.W. Somerville Ubuntu Developer -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Back to school [Second session available]
The first session hasn't taken place yet. You can see irclogs.ubuntu.com for IRC logs (plus I'm sure they'll post the irc log on the wiki like they used to). Thanks, Cody A.W. Somerville On Jan 16, 2008 6:54 PM, Luke Yelavich <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thu, Jan 17, 2008 at 08:29:32AM EST, James Westby wrote: > > I'm please to announce that Stefan has volunteered to run this session > > again on Saturday 19th January at 09.00 UTC to try and help those for > > whom the original session was inconvenient. > > Are there logs available from the first session? I don't mind not > attending a session, but logs of a session would be useful. > > Thanks. > - -- > Luke Yelavich > GPG key: 0xD06320CE > (http://www.themuso.com/themuso-gpg-key.txt) > Email & MSN: [EMAIL PROTECTED] > Jabber: [EMAIL PROTECTED] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHjos9jVefwtBjIM4RAtTJAJ9KuUSjOYrHeFIN+Q2jaQHSbdiJGACgmn4T > DNYZVsNlP0PQDjzuXjUzZeM= > =7ZmW > -END PGP SIGNATURE- > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > -- Cody A.W. Somerville -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: FTBFS list for Hardy
Would it be possible to have it when you hover over a cell it gives a tool-tip stating the title of the column (ie. arch) it is in? Thanks, Cody A.W. Somerville On 11/3/07, Luca Falavigna <[EMAIL PROTECTED]> wrote: > > Hello everybody, > > Following Emmet's mail [1] about QA efforts for Hardy development cycle, > I prepared a little script [2] which lists FTBFS for every port and > displays results on a web page [3]. > > It is absolutely not perfect and poorly tested, but can be useful during > the initial phases, so I'm going to schedule its execution until better > tools will be available. > > Feel free to reply if you have suggestions or criticisms. > > [1] http://tinyurl.com/35mmg5 > [2] http://ubuntu.linuxdc.it/ftbfs/ftbfs.py > [3] http://ubuntu.linuxdc.it/ftbfs > > Regards, > > -- > Luca > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > -- Firefox (www.getfirefox.com) -- A browser you can trust -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Notice of leave
Hello Everyone, I just wanted to let you know that I'll will be away for approximately eight weeks starting July 1st. if you require anything of me during this time, please send me a comprehensive e-mail to this address and I will be able to address them periodically. Thank you, Cody A.W. Somerville -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: MOTU Meeting
I voted on the wiki for Monday, January 22nd, 2000hrs UTC. Thanks, Cody A.W. Somerville On 1/17/07, Stefan Potyra <[EMAIL PROTECTED]> wrote: Hi folks, same procedure as last time, just reply to the mail with your preferred date. All MOTU's, hopefuls and people generally interested in the development of universe are invited. This time I have three candidates: * Sunday, January 21st, 10.00h UTC * Monday, January 22nd, 20.00h UTC * Tuesday, January 23rd, 08.00h UTC The voting will be closed on Saturday, 20th January, 12.00UTC. Please also add your agenda points to [1]. Cheers, Stefan. -- [1]: https://wiki.ubuntu.com/MOTU/Meetings -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- Firefox (www.getfirefox.com) -- A browser you can trust -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: new team: motu-swat
On 1/12/07, Kees Cook <[EMAIL PROTECTED]> wrote: > > On Fri, Jan 12, 2007 at 03:21:14AM +0100, Stefan Potyra wrote: > > Then it's time to call for the all new motu-swat, the police of > universe, who > > will squish all security bugs and thus make universe a safer place. > > Woo-hoo! This team is already rocking! I'm always happy to have more > eyes (and debdiffs) on the security issues in universe. A bunch of > -security uploads have already gone through as a result of motu-swat > attention. :) > > One thing I'd like to figure out is some way to publicize universe > security updates more widely. One place that collects the "recent > package updates" is the Ubuntu Weekly Newsletter. There's a Security > Updates section which catches USNs (for main), and an Updates section > which catches notifications sent to the $RELEASE-changes mailing list, > but since security uploads are done kind of side-ways, they seem to > bypass the -changes mailing lists (and as a result, the Newsletter). Right. However, security updates to Ubuntu+1 will _never_ be caught (but I don't see this as a problem). Thanks motu-swat! :) > > -- > Kees Cook > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFFpyNjH/9LqRcGPm0RArl7AJ9jd6pbDXtQfMBIYHwvFLdToEGYgQCgoRD8 > crJtPWt/XPdfkodq0+x//kE= > =dQ5w > -END PGP SIGNATURE- > > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu Thanks, Cody A.W. Somerville -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
