=== ubott2 is now known as ubottu [13:42] pesia: is it too late for the ubuntu studio blueprint Brian had made? [13:51] No. Do you need it discussed at UDS? [13:51] (and which blueprint?) [14:22] https://blueprints.launchpad.net/ubuntu/+spec/multimedia-platform-n-pro-audio-secured [14:23] persia: i don't know if it *needs* to be discussed at UDS [14:26] Oh, it probably ought be discussed. The "Brian" confused me. [14:26] Anyway, seems to be scheduled for UDS. [14:26] You probably want to push for the specification to be written :) [14:27] And you probably want to try to make the session, if you can (remotely, so IRC+audio stream). [15:12] persia: sorry for the late reply, work it keeping me busy lately [15:12] i am woefully inexperience with blueprints, UDS's, and specifications [15:13] who would nominally work up the specification? [15:13] are there examples that might be used? [15:13] where can i find out when this is scheduled so I know how much time is left? [15:18] There are three people associated with each blueprint: an Approver, a Drafter, and an Assignee.. [15:19] The Approver is responsible for determining when a blueprint is Approved: this switches the responsible person from the Drafter to the Assignee. [15:20] The typical workflow is that some Registrant files the blueprint, the Drafter writes up a Specification (see https://wiki.ubuntu.com/SpecTemplate ), the Approver approves it, and the Assignee coordinates the implementation. [15:20] Blueprints may be scheduled for Sprints. UDS is a Sprint. You can see UDS schedules at summit.ubuntu.com [16:15] persia: i found that it is scheduled for Tuesday [16:16] i also found the ubuntu studio specification: https://blueprints.launchpad.net/ubuntu/+spec/ubuntustudio [16:16] i can use that as an example [16:16] heh, indeed. [16:16] normally i would presume that I would be the "approver"? [16:17] For stuff that would significantly change how Ubuntu Studio behaves, I'd hope so, or at least that you implicitly trust the approver. [16:17] but i suggest that i might also be involved in the drafting as well [16:20] it looks like daniel and luke are subscribed as well to the blueprint [16:21] and assuming that they both will be at UDS-N then i feel relieve as this probably will not turn out to be completely useless without intervention [16:21] The Drafter is responsible for coordinating drafting, and usually does the first draft. The Specification is intended to be the result of collaboration. [16:35] persia: i'll take some time from work this afternoon, sequester myself in an unused meeting room with white board, and work something up for a draft [16:35] hopefully, i can convince others to look over it and improve it over the weekend [16:36] persia: if there are any key bullet point items you would like to see addressed i would greatly appreciate those [16:36] * scott-work has so much going around in his head currently that i can't even begin to formulate a direction or specific concerns currently [16:37] Main thing I'd like offthe top of my head is no-thought-required pulse/jack integration [16:37] that is the only thing that i thought of previously and feared i was missing many other ideas LOL [16:37] But I'm planning to attend the session and watch the implementation, and will probably make lots of points (some completely wrongheaded) along the way. [16:38] but my understanding was that it would take further tinkering by pottering/upstream in pulse audio to properly integrate them [16:38] I'm a little uncomfortable with autostart-jack-when-detect-audio-interface-on-the-firewire-network [16:38] But that needs more discussion, more than anything else. [16:38] i hope that i am incorrect and that we have the capacity to further the integration fully [16:38] Sure, needs some upstream tinkering, but diwic might be happy to do some of that. [16:39] who is diwic? [16:40] https://launchpad.net/~diwic (the Registrant for the spec) [16:41] Oh [16:41] * scott-work presents an embarassed grin for all to see [16:41] for some reason i thought "brian" had create the blueprint [16:42] Hence my 'The "Brian" confused me' at 13:27 :) [16:45] yes, i realize that now, at the time it confuses me :P [16:46] s/confuses/confused [16:46] my larger concern was that the blueprint wasn't focused and my lack of attention would leave the work at the sprint unfocused and therefore not as productive as it could be [16:52] UDS isn't a hackfest: it's just talk. [16:52] Having a focused agenda for a spec helps, but unfocused ones happen sometimes, and sometimes end up with good results. [16:52] Really depends on the subject and who is present. [16:53] My main concern is that the work that diwic clearly wants to do oughtn't adversely affect Ubuntu Studio. [16:53] heh, my ignorance shines again :P [16:54] well, that makes me feel better then :) [16:54] i'll still take some time later today and work on it a little then [19:05] I'm beginning to like PPAs less and less as days go by. People have genuine trouble interpreting the nature of them vs. official repositories. [19:06] I liked PPAs for about 3 months, when they were only available to members of ~ubuntu-dev and didn't actually protect against shooting yourself in the foot (wrong versions were OK, etc.) [19:07] Now that they are functional third-party release archives, I have the same feeling about them as I have for e.g. getdeb. [19:07] (the main bit being: "Why not work as *part* of Ubuntu?") [19:08] Yeah. It's bad enough with all different flavours and derivatives and what have you, but now it feels like people are separating _inside_ ubuntu. [19:09] I tend to think of flavours as an opportunity to collaborate. [19:09] But I dislike most derivatives (the exceptions being Sabily, Ichthux, and gNewSense: all because they have very good reasons to be out-of-archive, and otherwise play well). [19:10] And I just don't see the point of folks who have out-of-archive repos that aren't also Ubuntu developers. [19:10] Things like the various browser every-browser-release-every-Ubuntu-release-automatic-backports repos make some sense. [19:11] As do some of the test-this-weird-feature-before-I-upload ones. [19:11] But the vast majority just seem to be invitations to *not* contribute to Ubuntu. [19:11] I hear ya. [23:52] I agree with the above re PPAs. For me, they are only useful for testing/provide daily builds from upstrea for testing. In the Vinux project, we use PPAs because some changes that are made are not yet archive worthy, but hopefully will eventually be. [23:53] What is Vinux? [23:54] persia: Its an ubuntu derivative focusing on accessibility. It was started by someone else in the community, but I am now using it as a testing ground for new accessibility integration work, so once its ready in vinux, we can then move it to Ubuntu proper. [23:54] ...Unfortunately some of the things the community have done with that project are aweful, aweful, aweful hacks. [23:55] heh. It's so sadly that way for derivatives sometimes. [23:55] makes me like flavours even more every day. [23:55] Yeah, with time though, i intend to fix those hacks. [23:56] But it might be worth getting the Vinux folk in touch with the LP folk: there's some work ongoing to make first-class derivatives in certain cases, which should ease merging (in-LP MoM equivalent stuff). [23:57] Hrm ok, the vinux folk currently use remastersys/whatever else out there to remaster an existing live CD. [23:58] SO I wonder in what way LP and official derivitives will solve image creation, if at all. [23:58] Won't do a thing for image creation. [23:58] Right. [23:58] I suspected as much. [23:58] Will provide for per-package bug tracking, and remix/derivative distinctions, and archive concentrations, etc. [23:59] Depends on how much is in the PPA: getting it out of PPA and into the "Vimux Repository" has brand value, if nothing else. [23:59] (course, all this is *well* off-topic here :) )