Comments on: Apt URL Part Two http://blog.nixternal.com/2009.06.03/apt-url-part-two/ Free Software Chicago Style: letting proprietary solutions sleep with the fishes Wed, 10 Mar 2010 10:42:06 -0500 http://wordpress.org/?v=2.9.2 hourly 1 By: Jef Spaleta http://blog.nixternal.com/2009.06.03/apt-url-part-two/comment-page-1/#comment-5125 Jef Spaleta Thu, 04 Jun 2009 17:49:14 +0000 http://blog.nixternal.com/?p=575#comment-5125 @nixternal: "The PPAs are typically utilized for testing prior to sending stuff to backports" Is that a statistically valid statement? That might be the intent of PPAs when they were first created..but is that the typical usage case now? I don't think the Apt URL discussion would be so...controversial....if the typical PPA workflow really was as a feeder to Backports. I think the actual PPA usage has grown into a new role while perception of intended usage hasn't changed. I think its the dissonance that is causing people to look for Apt URL whitelisting as a technical solution..to what is fundamentally a breakdown on package policy/workflow. I think you have to throw away all the existing assumptions about how PPAs are meant to be used, and look at how they are actually being used..and then work forward from there. There are a crapload of individual ppas. Is the pre-backports workflow "typical" at this point? 9489 registered Ubuntu PPAs at this point over a 1000 "active" whatever that means. Is pre-backport testing the dominate usage scenario? Can you actually trend the flow of packages from PPA to backports? Maybe there is a difference between the flow rate for main as compared to universe for example. This might be hard to discover if there is no direct linkage in launchpad between PPA and backports that can be logged. If PPAs really are meant to feed into Backports, finding a way to instrument that feeder process as part of launchpad workflow would make sense and give you something to trend accurately. Another question, can you get hard number of which PPAs and which binaries inside of PPAs are the most popular. Are the most popular binaries going into backports in a timely manner? PPAs aren't mirrored are they? If they aren't then someone should have access to logs showing PPA binary download activity. which could be mined. Are the most popular PPAs pre-backport testing or have they effectively a parallel repository structure? You should probably stop talking to me now. You've given me about 5 specific new talking points about the benefits of streamlining PPA workflow by opening Soyuz. I will end up quoting you next time I have the opportunity to debate a Canonical rep about the closed status of Soyuz. -jef @nixternal:
“The PPAs are typically utilized for testing prior to sending stuff to backports”

Is that a statistically valid statement? That might be the intent of PPAs when they were first created..but is that the typical usage case now? I don’t think the Apt URL discussion would be so…controversial….if the typical PPA workflow really was as a feeder to Backports. I think the actual PPA usage has grown into a new role while perception of intended usage hasn’t changed. I think its the dissonance that is causing people to look for Apt URL whitelisting as a technical solution..to what is fundamentally a breakdown on package policy/workflow. I think you have to throw away all the existing assumptions about how PPAs are meant to be used, and look at how they are actually being used..and then work forward from there.

There are a crapload of individual ppas. Is the pre-backports workflow “typical” at this point? 9489 registered Ubuntu PPAs at this point over a 1000 “active” whatever that means. Is pre-backport testing the dominate usage scenario? Can you actually trend the flow of packages from PPA to backports? Maybe there is a difference between the flow rate for main as compared to universe for example. This might be hard to discover if there is no direct linkage in launchpad between PPA and backports that can be logged. If PPAs really are meant to feed into Backports, finding a way to instrument that feeder process as part of launchpad workflow would make sense and give you something to trend accurately.

Another question, can you get hard number of which PPAs and which binaries inside of PPAs are the most popular. Are the most popular binaries going into backports in a timely manner? PPAs aren’t mirrored are they? If they aren’t then someone should have access to logs showing PPA binary download activity. which could be mined. Are the most popular PPAs pre-backport testing or have they effectively a parallel repository structure?

You should probably stop talking to me now. You’ve given me about 5 specific new talking points about the benefits of streamlining PPA workflow by opening Soyuz. I will end up quoting you next time I have the opportunity to debate a Canonical rep about the closed status of Soyuz.

-jef

]]> By: nixternal http://blog.nixternal.com/2009.06.03/apt-url-part-two/comment-page-1/#comment-5124 nixternal Thu, 04 Jun 2009 16:55:03 +0000 http://blog.nixternal.com/?p=575#comment-5124 @Jef - you are right about easy, but if someone can spend time packaging it up and putting it into a PPA or other repo, it should be easy for them to make MOTU. If they are having problems making MOTU, then I don't want to use their repos or packages. In a way MOTU would be easier, as you don't have to mess with your PPA, nor do you have to figure out how dput works for the PPA. The fact that you have to search or discover a PPA makes it more difficult than the standard set of repos you are provided after installing Ubuntu. The PPAs are typically utilized for testing prior to sending stuff to backports. I know the Kubuntu team is relying more on backports now than they are the PPA. This time around with KDE 4.3 beta release, we will use the PPA as it is a beta release, but when 4.3 is stable, then we will get it backported. @Jef – you are right about easy, but if someone can spend time packaging it up and putting it into a PPA or other repo, it should be easy for them to make MOTU. If they are having problems making MOTU, then I don’t want to use their repos or packages. In a way MOTU would be easier, as you don’t have to mess with your PPA, nor do you have to figure out how dput works for the PPA. The fact that you have to search or discover a PPA makes it more difficult than the standard set of repos you are provided after installing Ubuntu. The PPAs are typically utilized for testing prior to sending stuff to backports. I know the Kubuntu team is relying more on backports now than they are the PPA. This time around with KDE 4.3 beta release, we will use the PPA as it is a beta release, but when 4.3 is stable, then we will get it backported.

]]> By: Jef Spaleta http://blog.nixternal.com/2009.06.03/apt-url-part-two/comment-page-1/#comment-5123 Jef Spaleta Thu, 04 Jun 2009 16:08:15 +0000 http://blog.nixternal.com/?p=575#comment-5123 @nixternal: Try not to rely on personal mermory, or collective institutional memory about trending, actually having a graph that trends a workload metric in front of you for is far more reliable..especially if its highly fluctuating with a long term upward trend across releases. The fluctuations are going to warp perception. Fight the tendency to ballpark it, and find a way to trend workload. "Easy" is such a fluid definition. You may think the MOTU process is easy enough, but do the potential candidates who are active as PPA packagers think it is? The definition of easy could have slipped a little bit as the demographics of your contributor community changed over time. Seeing if the active PPA packagers think its easy is the only way forward here. It could just be a lack of communication about the role of MOTU. You might find out that its easier to know about PPAs, then it is about knowing about MOTU. That makes some sense, as technically launchpad is a general purpose hosting service not tied to the Ubuntu distribution release policies..and PPAs are part of that service. You don't see MOTU membership communicated through general launchpad interaction like you do PPAs. In a sense Launchpad nature has made PPAs easyer to discover and thus easier to use. Are you able to track volunteer MOTU activity levels? Do you have a sense as to how many active individuals are doing the day-to-day work or release-to-release work? And you have to be careful about setting workload expectations for volunteers and keeping a track of volunteer activity without being judgemental. You have to build in an expected turnover rate for volunteers into any process which is heavily dependent on them. You should absolutely expect volunteer MOTUs to step back after sometime, but have you generated an expectation on that timeframe (in an average sense) and built a process which anticipates losing volunteers at an average rate? How has the MOTU group grown over time? Was it impulsive growth with a large chunk of the team built in a burst? Or has it been slow aggregation? Impulsive growth can have draw backs on the back end because you should then expect that group of people to stepback around the same time (on average) so you lose people impulsively too...and institutional process memory with them. -jef @nixternal:

Try not to rely on personal mermory, or collective institutional memory about trending, actually having a graph that trends a workload metric in front of you for is far more reliable..especially if its highly fluctuating with a long term upward trend across releases. The fluctuations are going to warp perception. Fight the tendency to ballpark it, and find a way to trend workload.

“Easy” is such a fluid definition. You may think the MOTU process is easy enough, but do the potential candidates who are active as PPA packagers think it is? The definition of easy could have slipped a little bit as the demographics of your contributor community changed over time. Seeing if the active PPA packagers think its easy is the only way forward here. It could just be a lack of communication about the role of MOTU. You might find out that its easier to know about PPAs, then it is about knowing about MOTU. That makes some sense, as technically launchpad is a general purpose hosting service not tied to the Ubuntu distribution release policies..and PPAs are part of that service. You don’t see MOTU membership communicated through general launchpad interaction like you do PPAs. In a sense Launchpad nature has made PPAs easyer to discover and thus easier to use.

Are you able to track volunteer MOTU activity levels? Do you have a sense as to how many active individuals are doing the day-to-day work or release-to-release work? And you have to be careful about setting workload expectations for volunteers and keeping a track of volunteer activity without being judgemental. You have to build in an expected turnover rate for volunteers into any process which is heavily dependent on them. You should absolutely expect volunteer MOTUs to step back after sometime, but have you generated an expectation on that timeframe (in an average sense) and built a process which anticipates losing volunteers at an average rate? How has the MOTU group grown over time? Was it impulsive growth with a large chunk of the team built in a burst? Or has it been slow aggregation? Impulsive growth can have draw backs on the back end because you should then expect that group of people to stepback around the same time (on average) so you lose people impulsively too…and institutional process memory with them.

-jef

]]> By: nixternal http://blog.nixternal.com/2009.06.03/apt-url-part-two/comment-page-1/#comment-5122 nixternal Thu, 04 Jun 2009 16:01:36 +0000 http://blog.nixternal.com/?p=575#comment-5122 @João Pinto - FUD? You are crazy dude. I know getDeb has gotten better, but in the past it was hosing machines just like Automatix was. I can't think of anything else to compare this entire situation to. Yes, I really do not trust 3rd parties either. By the way, I am not stuck in the universe, as a lot of my work goes on in main anyways :p My concerns are not based on lack of information, and I think that was a stupid remark based on a lack of information. If you read at all my previous post, I clearly stated that offering Apt URL support on a team's PPA (ie. Desktop Team, Kubuntu Team, Server Team, etc) would be the safest way to initially offer Apt URL. As for personal PPAs that would really depend on the person. I feel that person should be a MOTU or a Core Developer before they are "whitelisted." Here is a question for you, since I don't use getDeb. How come you do not package for Ubuntu? Your experience is obviously great and would benefit Ubuntu by contributing directly. @SeanHodges - ah ha! That's why it is not in the repos. Thanks for that! @João Pinto – FUD? You are crazy dude. I know getDeb has gotten better, but in the past it was hosing machines just like Automatix was. I can’t think of anything else to compare this entire situation to. Yes, I really do not trust 3rd parties either. By the way, I am not stuck in the universe, as a lot of my work goes on in main anyways :p My concerns are not based on lack of information, and I think that was a stupid remark based on a lack of information. If you read at all my previous post, I clearly stated that offering Apt URL support on a team’s PPA (ie. Desktop Team, Kubuntu Team, Server Team, etc) would be the safest way to initially offer Apt URL. As for personal PPAs that would really depend on the person. I feel that person should be a MOTU or a Core Developer before they are “whitelisted.” Here is a question for you, since I don’t use getDeb. How come you do not package for Ubuntu? Your experience is obviously great and would benefit Ubuntu by contributing directly.

@SeanHodges – ah ha! That’s why it is not in the repos. Thanks for that!

]]> By: SeanHodges http://blog.nixternal.com/2009.06.03/apt-url-part-two/comment-page-1/#comment-5121 SeanHodges Thu, 04 Jun 2009 15:19:45 +0000 http://blog.nixternal.com/?p=575#comment-5121 Sorry, typo: "restrictions that limit modification and distribution" - I meant - "restrictions that limit modification BUT NOT distribution" Sorry, typo:

“restrictions that limit modification and distribution” – I meant – “restrictions that limit modification BUT NOT distribution”

]]> By: SeanHodges http://blog.nixternal.com/2009.06.03/apt-url-part-two/comment-page-1/#comment-5120 SeanHodges Thu, 04 Jun 2009 15:11:29 +0000 http://blog.nixternal.com/?p=575#comment-5120 @Thomas: The purpose of the multiverse repository is for packages that are closed source and/or have other restrictions that limit modification and distribution. I believe submitting to multiverse is slightly more difficult than submitting to universe because of the complications that surround this. Skype is a perfect example of this. The reason why Skype cannot be in multiverse is because the Skype licence explicitly forbids it. For example: "1.3 You will not distribute other products or services together with Skype Software, unless You are a publisher of computer magazines for end users and distribute the Skype Software with Your magazine(s) for free." See: http://www.mail-archive.com/debian-legal@lists.debian.org/msg37309.html @Thomas: The purpose of the multiverse repository is for packages that are closed source and/or have other restrictions that limit modification and distribution. I believe submitting to multiverse is slightly more difficult than submitting to universe because of the complications that surround this.

Skype is a perfect example of this. The reason why Skype cannot be in multiverse is because the Skype licence explicitly forbids it. For example:

“1.3 You will not distribute other products or services together with Skype Software, unless You are a publisher of computer magazines for end users and distribute the Skype Software with Your magazine(s) for free.”

See: http://www.mail-archive.com/debian-legal@lists.debian.org/msg37309.html

]]>