[00:09] persia, i didn't see any wiki pages that specifically addressed development teams as i did for delegated teams [00:10] my presumption is that they would function in a similar manner however [00:10] Then I did it wrong :) [00:11] Indeed. I completely did it wrong. [00:11] Thanks for helping me to discover this. [00:11] So, https://wiki.ubuntu.com/UbuntuDevelopers/TeamDelegation is basically right, *EXCEPT* [00:12] We have separated granting a team for upload rights from granting a team the authority to manage their own membership. [00:12] So, for example, the Server Team has upload rights to the Server packageset, but doesn't have admin rights over the Server-Developer team. [00:13] * persia adds sorting this out to the TODO list [00:14] Just to make sure, the important thing to you currently is making sure that folk actively working on Ubuntu Studio can upload our packages, right? You don't much care about coordinating team membership, etc.? [00:24] persia, i care about making ubuntu studio better, if this overlaps into coordination of team membership then i will gladly accept any responsibilities as needed [00:25] however, my primary concern is as you said...making sure those working on ubuntu studio can upload [00:25] my understanding from the what i have read is that we would need to get the team approved first with our package set [00:25] my presumption is that you, luke, and alessio would be among those in the group primarily [00:25] I never meant to imply you were one to shirk responsibility: everything I have seen from you indicates precisely the opposite :) [00:26] although unnecesarily as it is [00:26] sorry, didn't mean to imply that you were implying that ;) [00:26] Right, getting the team approved is the first step, and your imagination of the set of initial developers matches mine. [00:26] after the team is approved, which can be sought immediate almost [00:26] then i would focus on getting myself and whoever else is needed approved into the team [00:26] or approved for rights to upload [00:27] to get the team approved i expect that we need to: [00:27] 1. add wiki page to explain how to become a "developer" for ubuntu studio, what we expect, etc [00:28] Don't worry about that stuff for now. [00:28] * persia looks up an example [00:28] oh, okay [00:28] i found several on friday from the archives that you suggested [00:29] but further examples are also welcome :) [00:29] * ScottL is going outside to mow for a bit, i'll check in when i need a drink [00:33] https://lists.ubuntu.com/archives/devel-permissions/2010-July/000090.html is the application for the server team (like us, they already had a packageset) [00:35] So the main thing to do is make sure we know which is the right team in LP, and make sure it has the right membership (including core-dev as an indirect member), and isn't subscribed to any bugs. [01:42] hmmm, i would presume that ubuntustudio-dev would be the proper team [01:43] Quite possibly, although I'm not sure the current membership is right. [01:43] i would not expect adding core-dev as an indirect memeber to pose problems [01:43] are you intimating that we should prune some membership? [01:44] i have no idea if ubuntustudio-dev is assigned to bug, but it would be easy enough to check [01:45] * persia is digging on LP, and won't have any firm opinions until that is complete :) [01:45] lol, rock on man [01:46] So, in terms of membership, we've a bundle of folk in ubuntustudio-dev. Some already have upload rights, many do not. [01:46] I'm not sure of the social benefit in ejecting those folk: many of them have done or are doing good work. [01:48] The team is also subscribed to a bunch of packages, and probably N individual bugs. [01:48] perhaps a new team? [01:48] that seems somewhat redundant [01:48] That's what I'm thinking. [01:48] Well, let's think about what are the right teams to have in LP. [01:49] If you have a good model, then maybe there is no social penalty in clearing out the membership of ubuntustudio-dev. [01:49] Currently we have a few: "Ubuntu Studio", "Ubuntu Studio Nightly", "Ubuntu Studio Testers", "Ubuntu Studio-dev", etc. [01:50] Yeah, given the messof teams in LP, I think the order of action is 1) clean up the LP teams to have sensible purposes, and appropriate everything. [01:51] 2) move folks between teams as appropriate to match the new model (maybe also trying to contact the members and make sure they are still interested) [01:51] 3) Ask for the developer team to have upload rights [01:52] 4) Add people back to the developer team as appropriate [01:57] i'm not sure the purpose of "Ubuntu Studio" and i don't think "Ubuntu Studio Testers" is fulfilling it's purpose [01:57] er [01:57] s/Ubuntu Studio Testers is/Ubuntu [01:58] s/Ubuntu Studio Testers is/Ubuntu Studio Testers is NOT [01:59] Heh. Yeah, it gets confusing and murky. Moreso when you start looking at the PPAs and bzr trees. [01:59] i would expect that "Ubuntu Studio-dev" owns the bzr branches that are mirrored for the archives, is this an accurate statement? [02:01] From the limited digging I just did, it appears that Ubuntu Studio-dev owns the seeds, and owns the branches from which uploads happen (which aren't the branches that are mirrored from the archives) [02:01] from or for? [02:02] i guessed that the brances that are owned by ubuntustudio-dev are mirrored and owned by "Ubuntu" [02:02] From [02:02] It's *much* more complicated than that. [02:02] these "Ubuntu" mirrors are used for the archives [02:02] LOL [02:02] okay [02:03] LP is currently telling me "Peer failed to perform TLS handshake", so I can't look up the details, but here's a rought description (you can get the details from LP, if you can connect) [02:03] much is, it seems...complicated, that is [02:03] ~ubuntustudio-dev has branches for some of the Ubuntu Studio specific packages. [02:04] Sometimes people take snapshots of those branches and upload the results to the archive. [02:04] The uploaded package is then processed by the branch-importer, which generates e.g. lp:ubuntu/natty/ubuntustudio-meta [02:05] (note that this may have identical content to lp:~ubuntustudio-dev/ubuntustudio/ubuntustududio-meta but the branch histories differ, and the branches are incompatible) [02:10] i wonder what ubuntu studio specific packages are NOT owned by ubuntustudio-dev [02:10] i realize that -nightly builds some, but i wouldn't necessarily call these "ubuntu studio specific" [02:11] checking under "ubuntustudio-dev" code, it reminds me that we need to check on the hal dependency in ubuntustudio-seeds [02:12] All the stuff we ship from Debian-Multimedia [02:12] that is "ubuntu-seeds/ubuntustudio.oneiric" [02:13] okay, that makes sense since we _are_ talking about acquiring upload rights....sorry i'm a bit slow [02:16] looking at xubuntu, they have the following teams: xubuntu, xubuntu-dev, xubuntu-users, xubuntu-testers, xubuntu-artwork, and xubuntu-daily builds as far as i can tell [02:17] No worries. I've been thinking about these things for the past 3 years or so, so I'm \\ve a bit of an advantage. [02:18] and i plan to use some of the xubuntu-testers documentation for us :) [02:18] heh [02:19] if we had a clear plan for new teams with distinct purposes, it would be easier in some ways to remove everybody from all teams and start over :/ [02:19] in some way it obviously wouldn't [02:19] s/way/ways [02:21] and i'm not sure which differences are intended between https://launchpad.net/~ubuntustudio and https://launchpad.net/ubuntustudio [02:22] oi vey, and now i find https://launchpad.net/ubuntustudio-project [02:22] these are beginning to look like a bunch of random launchpad groups that people put together because they could [02:23] I believe each had a purpose at the time it was created. [02:23] I'm not sure there was an overarching vision, or that everyone creating the teams was aware of all the others at the time of creation. [02:23] i think this creates a nightmare, however, for users who wish to assign bugs as accurately as possible [02:24] Ah, yes. So the current ubuntustudio packageset (or something like what it ought be) is listed at http://people.canonical.com/~cjwatson/packagesets [02:24] Generally in Ubuntu we discourage users from assigning bugs. [02:25] The idea being that people who are motivated to do things (as volunteers, because of their jobs, for other reasons) will be able to select the things they want to do, and do them. [02:25] Users fiddling with people's TODO lists just makes people not want to look at those TODO lists. [02:25] oh, several of those packages in cjwatson's packageset are not in the archives [02:25] our seeds are badly out of date in regards to the language packs [02:26] my plan was to weed them out this cycle [02:26] i had considered it last cycle but didn't for various reasons [02:26] hmmm, dos2unix, interesting [02:27] Really, my goal here *isn't* to make your TODO list grow :) [02:28] lol, the language packs are something that bothers me because it shows up quite prominately in the build logs [02:29] http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntustudio/natty/daily-20101109.log [02:30] that shows seventy-five to one hundred "unknown ship package"s [02:30] http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntustudio/natty/daily-20110426.1.log is more interestingly annoying, as it reflects the Natty release image. [02:30] (but annoying for precisely the same reasons) [02:31] persia, would it be beneficial to explore each "ubuntu studio-*" in launchpad and see what code is under each? [02:32] And which members, and what bugs, and what package subscriptions, etc. [02:32] that could be done [02:32] The more you know about the situation, the better your chances of making it make sense. [02:33] We also have the "Ubuntu Studio" project. I've never really understood the value of that: it seems ot just complicate bug reports. [02:33] i dislike disorganization and i would like to find rectify it [02:33] aye, it does seem so [02:33] i'm going to shower after mowing and hopefully before wife/kids get home from grocery store so i can help bring in groceries [02:33] be back in a few [02:36] So, `grep "Unknown.*package" daily-20110426.1.log | wc -l` returns "840", as a measure of just how out-of-date our seeds have become. [02:36] Comparatively, there are "only" 89 Unknown dependencies or recommendations to the packages that we do ship. [02:58] i would like to try to attend the xubuntu team meeting to see how we (i) can improve our meetings [03:27] i notice that the "ubuntu studio project" has numerous other projects under it...e.g. ubuntustudio-artwork, ubuntustudio-look [03:27] some of these project are either empty or appear to have old code [03:27] i think i'll have to create an organization chart in inkscape during the week [05:24] howdy [05:27] hey Kokito [06:03] re [16:48] persia: are you around for a question regarding the various teams and projects for ubuntu studio? [16:49] i believe it to be a simple question [16:50] If my nick is in the channel, just ask. If I'm not around, I'll answer when I get back. If you didn't see an answer for a long time, bug me, and I'll repeat myself. [16:54] (if my nick isn't in the channel, something annoying is happening, and I'll return when I can. In practice, this should happen rarely) [17:10] right, if a branch starts with "~ubuntustudio-dev", e.g. lp:~ubuntustudio-dev/ubuntustudio/ubuntustudio-menu, then ubuntustudio-dev owns that branch, correct? [17:11] Yes [17:36] it would appear that all code lies with ubuntustudio-dev other than a discreet few [17:38] i have been brainstorming why creating projects or teams within launchpad would be beneficial or of use, i can see: [17:38] 1. hosting code [17:38] 2. bug reporting [17:38] 3. controlling access to code [17:39] i believe i thought of a fourth reason but i can not remember it now [17:39] oh, 4. communication, i.e. mailing lists [17:40] given these reasons then, i think the number of projects and teams could be greatly reduced [17:40] but there are other problems within the logistics of reducing the number of projects/teams [17:41] possibly problems exists, right now they are concerns [17:42] for example, if we deprecated a project which owns code, how do we transfer ownership to a different/new project or team [17:42] So,. 2) isn't interesting within an Ubuntu Studio context, because it's easier for us to just use the Ubuntu infrastructure, and this result is less confusing to users. [17:43] 2) is *very* interesting for software projects, which projects we'd then package and include. [17:43] and ubuntu studio owns and maintains various (although limited) softwares [17:43] So, if we wanted separation between the folks that were doing hard-core work on some piece (e.g. ubuntustudio-controls), and the folk that were preparing uploads into Ubuntu Studio, it makes sense to have a project for ubunstudio-controls. [17:44] it does, to a degree [17:44] (although in this case, I would argue that someone ought to come up with a better name, and build something that was generally useful for several media-generation focused distributions) [17:44] but do we want projects for each software project under ubuntu studio? [17:45] and each project have it's own upload rights? do we really need that fine granularity? === falktx_ is now known as falktx [17:45] This is separate. [17:45] * scott-work is rereading then [17:45] So, let's take ladish as an example. [17:46] okay [17:46] There's a ladish project. That has several developers. They do cool things. Once in a while, they say "This code is usable in this state" and tell everyone. [17:46] Then the distributions (that's us) take that code, package it, and include it. [17:46] * scott-work admits than he keeps thinking in terms of ubuntustudio-* packages [17:47] So, if there are projects that are interesting externally, then it makes sense to have separate projects (and we should encourage less focused names). [17:47] if there are projects that make no sense externally, then it doesn't make sense to have separate projects in LP. [17:47] Now, LP hosts code by people and teams. [17:48] The official code in Ubuntu Studio is always available at lp:ubuntu/packagename or by downloading the source packages. [17:48] Anyone can get it either way. If they branch from bzr, they can push to lp:~${USERNAME}/ubuntu/${PACKAGENAME}/${BRANCHNAME} with candidate code. [17:48] side point: can someone (core-dev?) upload to lp:ubuntu/packagename for lp:~ubuntustudio-dev packages? [17:49] If they download packages, they can prepare more traditional patches. [17:49] If we have a packageset team, anyone in the team can upload. Having core-dev as a member is a requiremnt. [17:49] There's also a bug in LP right now that means that for many of our packages, MOTU can upload, but that's temporary, and they are encouraged to either join our team or refrain from uploading those packages. [17:50] interesting [17:50] So, I don't think we need to worry about teams or projects in terms of hosting code. [17:50] Or in terms of bug reporting. [17:51] *Except* if we determine that some piece of software that is only in Ubuntu Studio currently is more generally useful, in which case it should be spawned off into it's own project. [17:52] So, moving on: [17:52] does this mean that those with upload rights will be able to push to lp:ubuntu/packagename ? including, say, ubuntustudio-controls ? [17:52] Yes. [17:52] oooh, it is complicated [17:52] Or upload the package, in which case the package importer will automatically commit the changes to lp:ubuntu/packagename [17:53] well, that leaves #3 and #4 [17:53] So, moving on with your list: I don't think 3) means anything. [17:53] Either you mean restricting access in some way, which we don't do (plus we're using distributed version control), so there's no help. [17:53] and #4 is arguably not a great reason for neither a project nor a team in launchpad context [17:54] Or you mean restricting who can commit, in which case I wonder if there is a use case for having the set of committers be different than the set of uploaders. [17:54] i meant #3 in terms of pushing to the branch [17:54] and uploading [17:54] Ah, yes, then there's a case for one team: the upload rights team. [17:55] Mind you, teams can also have social value: people may feel they belong more if they are invited to be on a team. [17:55] since people can lp:~${USERNAME}/ubuntu/${PACKAGENAME}/${BRANCHNAME} i am less worried about committing than i am about uploading [17:56] (for example, there's a team on LP "CJK Testers", which consists of people who have Chinese, Japanese, or Korean locales available. This team grants no privileges, but sometimes it gets subscribed to bugs that need someone with the right environment to reproduce/triage/etc.) [17:56] persia: that social aspect intrigues me and vexes me [17:56] but i feel that it should be checked by purpose [17:56] Ubuntu Studio Testers could function in the same way: ask Bug Squad to subscribe the team when a bug is found that needs a complex studio setup to reproduce, etc. [17:57] Yeah. You need to have a reason, but the reason need not be technical. [17:57] i almost said value because there is a purpose but it is not happening [17:57] * scott-work thinks that -testers is an example of this [17:58] Teams sometimes subside, and need a kick. [18:07] * scott-work sighs, i'm only a supervisor but i seem to have to help my department's managers see the bigger picture sometimes :/ [18:07] at work, that is [18:08] Some people are big-picture people. Some people are little-picture people. It takes both. [18:09] its also appears that "the ubuntu studio project" became an umbrella "project group" under which several ubuntu studio projects are attached [18:09] Oh, regarding 4) we have a couple mailing lists on lists.ubuntu.com : the question to ask is "Do we need more?". [18:09] That's someone getting fancy with launchpad. [18:09] i agree [18:10] re: #4, i don't think so but i think perhaps -dev might be repurposed slightly [18:10] well that's not correct [18:10] perhaps additional purposes [18:10] And as much as I probably know, like, and respect the person who did it (there are only so many candidates after all), I believe that doing it that way creates false separation from the Ubuntu Project, and makes it harder for us to work as part of the larger umbrella. [18:11] my concern is that the team is small with limited purposes and i do not believe we need this many teams [18:13] if the team was orders of magnitudes larger with associated increase in active and frenzied development then i could understand a larger organizational system [18:20] oh, and i agree with big-picture and little-picture people, but at times i am taken aback how much guidance and shaping i do for our department and division that i feel that others should be doing [18:21] *shrug* but it is what it is and our department/division keeps improving which is what i think is most important [18:22] persia: so basically you dismantled all my reasons for teams/projects within launchpad and only added social concerns :P [18:23] given those constraints it certainly appears that we don't need many teams/projects then [18:24] I believe social concerns are generally the overriding concerns. If the social bits are right, everyone can work together to solve everything else. If the social bits are wrong, this will never happen. [18:26] but with the inclusion of an "upload rights team" [18:27] To a large degree, that's a social bit: "These are the people who we trust to be the final reviewers of the seeds and packaging: anyone is welcome to join: just build the trust". [18:27] then i would also suggest that we rebrand the -devel group into "ubuntu studio contributor group" [18:27] Could do. [18:27] this group would not have commit or upload rights directly then [18:28] once trust is built, then they move into "upload rights team" [18:28] Just a social group that people can join if they are doing stuff, as a stepping stone to being on the upload team? [18:28] we can keep "ubuntu studio users" group [18:28] Users is an important group: that's where the bulk of the support staff is developed. [18:29] i think the "contributor" team is important even if a person has no upward ambitions for the upload team [18:30] for documentation or art or testing [18:32] but yes, the ideal path would be to use the "contributor" group as a stepping stone for those with larger designs [18:32] but we know that there is always turnover and also new members that should keep the "contributor" group populated and necessary [18:33] i think a lack of definition, documentation, and publishing hurts increasing the ubuntu studio contributor ranks [18:34] And we could make a concerted effort to help anyone in the contributor team who isn't already become an Ubuntu Member. [18:34] i don't think we have the procedure for inclusion defined, i haven't seen it documentated, and i don't beleive we have make people aware of the possiblity [18:35] very true (i'm pushing holstein right now) ;) [18:35] For most of the teams I've been involved with, inclusion was a matter of announcing intent, showing up at a meeting to receive accolades (or criticism and encouragement for next time). A friendly tribal initiation. [18:37] i think clearly identifying who CAN become a contributor and what is expected (from both parties) will encourage people to join also [18:37] the method you mentioned was how i became involved with ubuntu studio, but it is a hard path in some ways [18:38] a person must be a highly motivated person to navigate to proper inclusion into the team [18:38] properly defining the path would lower the threshold [18:39] Right. The surroundings to the procedure need to be clear. [18:39] 1) All are welcome: this is how to start to get involved. [18:40] 2) This is the procedure to be accepted: it's not hard, just do stuff listed in #1 [18:40] 3) Being accepted brings an expectation that you're going to help those who aren't yet go through the process. [18:42] * scott-work is to be interviewed by Linux Outlaws tomorrow morning at 6:00 am about the XFCE change [18:42] Cool! [18:43] Be nice to unity: it's just not for us. [18:43] (just because there's already too much wild discussions about unity vs. gnome shell, and I don't think this decision has anything to do with that, but rather with the requirements for higher processing for desktop effects) [18:44] i completely agree [18:45] i'm completely amazed by how much internet press i found regarding this issue, i.e. ubuntu studio choosing xfce, and how they choose to spin it [18:45] (at least how i percieved they spun it) [18:46] Yeah. It'll be good to be able to set the record straight. [18:46] we aren't thumbing our noses at canonical/ubuntu/unity, our response would have been the same most likely if ubuntu went with gnome3 [18:46] Yes, computers are getting faster. Yes, folk have GPUs. Still, when folk are trying to extract every last bit of performance out of their hardware to achieve some special audio effect, or render some animation, there is no space for fancy wiggly window animation. [18:48] i find the needs between a musician compared to a desktop/laptop user are different [18:49] at it's most base, i do not think that a typical desktop/laptop user will want to have 10+ windows open and need to manage them [18:49] well, not actively at least [18:49] You're right about that. They use only one at the time. Two at most. [18:49] Well, lots of folk do that, but they usually only need to see 2-3 at the same time. [18:50] hi astraljava [18:50] Howdy. [18:50] Yeah, one is common. 2-3 is heavy workload. [18:50] i was going to posit that a typical user would actively use and manage five windows or less at any given point [18:51] and five may be gratious [18:51] Whereas for JACK, one has 4-5 *important* windows open before one even starts with tone generators, effects, etc. [18:51] absolutely, it could be upwards toward 20 possibly [18:51] 5 is probably too high, but let's give them credit. it also nicely matches the minimum you need just to use qsynth to generate some tones. [18:52] but i would say that a musician could easily have well over 10 windows open [18:52] and i feel that neither gnome3 nor unity were designed for such management [18:53] that doesn't make them bad of course, they serve the general populace's needs quite nicely [18:53] Indeed. They are focused on a completely different category of user. [18:53] and that is the focus of my explanation tomorrow [18:53] That sounds like a good story. [18:55] i feel that canonical and ubuntu are doing something quite remarkable and noteworthy at this moment [18:55] unity is giving gnome 3 competition....which is good i think, it should foster development [18:55] but futhermore, the move to wayland and away from x.org is remarkable as well [18:56] canonical is investing in the future with wayland...this will be BIG later on [18:56] We'll see: there's a lot of stuff that wayland breaks that needs investigation. [18:56] scott-work: im going to make that happen this summer [18:57] that is to be expected naturally [18:57] *membership [18:57] holstein: outstanding! [18:57] About time! [18:57] persia: :) [18:57] as long as my ubuntustudio work can get me membership [18:57] but moving away from x.org's code base with what has been described as large amounts of legacy code is a good thing i believe [18:57] holstein: it worked for me [18:57] :) [18:58] the rest of my contributions i might need to let go [18:58] but, unless i just get crasy busy, i plan to always do what i can with ubuntustudio [18:58] holstein, Nobody cares how you contribute to Ubuntu, just that you do, and that you keep doing so, and that your work is important (all of which I believe to be true) [18:58] and, i think thats enough to warrant membership* [18:59] persia: cool [18:59] persia: if we redo the teams/projects i would like to clearly list the purpose of the team and link how to join...and possibly other things that i can't define currently :P [18:59] scott-work, That sounds like a good plan. [18:59] lunchtime... BBL [18:59] clearly list the purpose and link on the project/team page in the description [19:00] I agre that it's probably not worth rearranging everything until there is a plan, and docs (and you have rough consensus) [19:04] however, we could implement the upload rights team without breaking anything i believe [19:05] persia: do you know what is involved in removing a team/project from launchpad or deactivating it? [19:05] persia: what about moving ownership of code or branches? [19:06] is the concensus to be sought on the ubuntu studio mailing lists only? [19:06] Moving ownership of branches is hard: easier to handle it semantically: branch the old location and push to the new location, and tell everyone the new location is correct and the old location is not. [19:06] removing teams and projects requires that the team/project owner talk to the launchpad crew. I think it's a question, but ask in #launchpad to be sure. [19:07] As the project lead, you get to choose the polity. I'd recommend including at least all the opinion leaders active in Ubuntu Studio, and probably most of the more active folk. You may find the mailing lists a handy way to reach them, or not (you'd know better than I). [19:08] The key bit is that if someone is doing good stuff for Ubuntu Studio, you don't want them to feel rejected, or feel like they were excluded from the decision. [19:08] They may not agree with all the details, but you want to make certain they agree with the way the final solution was reached. [19:10] if we can clearly frame the discussion in the end goals and the benefits expected then hopefully the details will become of less concern to many, if not most [19:10] Sure. [19:46] hmmm, no answer yet in #launchpad although i will continue to solicit an answer [19:47] Australia or Europe day is better timing [19:47] ah, excellent suggestion [19:48] i'll try again tonight at home and then early in the morning [19:54] persia: i have an answer: [13:55] scott-work: Teams can be deleted outright. Projects cannot be deleted, but can be deactivated, which hides them from most people. Either way, a request into https://answers.launchpad.net/launchpad/+addquestion is the way to go - preferably from the person who owns the item in question (or member of the owning team) [19:55] Excellent. [23:24] * ckontros expected alot more from the artwork brainstorm/discussion thread by now. :( [23:38] ckontros, i just realized that it was there 30 minutes ago as i left for home [23:38] i'm going to respond shortly [23:40] * astraljava is not very graphical guy, so doesn't really have an opinion [23:41] I notice when things look good, but can't really tell where to enhance them if they don't [23:43] ScottL: Gotcha. Wasn't really thinking of you. ;)