<div class="gmail_quote">Forwarded message to the Ubuntu Studio Developers Mailing List with John Dong's permission.<br><br>---------- Forwarded message ----------<br>From: <b class="gmail_sendername">John Dong</b> <span dir="ltr"><<a href="mailto:jdong@ubuntu.com">jdong@ubuntu.com</a>></span><br>
Date: Sun, Apr 11, 2010 at 3:46 PM<br>Subject: Re: Backporting Ubuntu Studio Applications for LTS Version<br>To: Scott Lavender <<a href="mailto:scottalavender@gmail.com">scottalavender@gmail.com</a>><br><br><br><div style="word-wrap: break-word;">
<br><div><div class="im"><div>On Apr 6, 2010, at 4:31 PM, Scott Lavender wrote:</div><br></div><div class="im"><blockquote type="cite">John,<br><br>Hello again. Please allow me to preface this email with profuse thanks in changing the Ubuntu Studio forum name at Ubuntu Forums.<br>
<br>I write this email to you to discuss backporting Ubuntu Studio centric applications for LTS versions.<br>
<br>I have had limited exposure to backporting via backport bug reports but in my experience it seemed that some applications, JACK and Ardour specifically, were not backported to Hardy. This lead to me backporting them in my PPA, announcing my backport PPA, and committing to keeping up with them.<br>
<br>Please read the previous sentences without an accusing tone or assessing blame! I think most teams have limited resources and address what they can.<br></blockquote><div><br></div></div>Hi Scott,</div><div><br></div>
<div>I think the main issue with JACK was that it was a library, and backporting libraries is always troublesome because often times it'd require the recompiling of reverse-dependency packages. Whether or not such packages are safe for backporting is often controversial. </div>
<div><br></div><div>With Ardour, I'm not sure what happened there -- most likely due to the lack of triaging manpower on our end :( I'm sorry for that.</div><div><br></div><div><br></div><div><div class="im"><br><blockquote type="cite">
<br>I had suggested on the ubuntustudio-dev mailing list than perhaps we should keep our own "official" Ubuntu Studio backporting PPA. Jussi asked why and even suggested contacting the backports team as you would probably appreciate our efforts and possibly accepts on of the Ubuntu Studio developer members into the backporting team. You can find that email at : <a href="https://lists.ubuntu.com/archives/ubuntu-studio-devel/2010-April/002345.html" target="_blank">https://lists.ubuntu.com/archives/ubuntu-studio-devel/2010-April/002345.html</a><br>
<br></blockquote><div><br></div></div><div>Cool! I think keeping an official UbuntuStudio PPA is a good idea, just like how Kubuntu has their PPA. It serves two purposes:</div><div><br></div><div> 1. For cases where a backport is unacceptably intrusive for inclusion in general Backports but is acceptable for your distribution, you may use your PPA to distribute them. Kubuntu uses this, for example, to bring new releases of KDE to existing Ubuntu releases, which for Backports has been more or less agreed to be unacceptably intrusive and regression-prone.</div>
<div><br></div><div>2. For cases where your backports would be suitable for general-user backports (Ardour sounds like one of those cases), the testing and feedback through Ubuntu Studio can be sufficient evidence to base a backport approval on. That is, after a package has been shown to work well in your PPA, it's relatively easy to tell the Backports Team "hey look, the package works fine from our PPA", and we would feel relatively comfortable with approving such backports requests.</div>
<div><br></div><div>Right now, the Tech Board charter for Backports still states that "MOTU" (I guess that now means any Ubuntu developer) can join the Backports team. Generally the procedure I've used is that an applicant should be passionate about Backports work and have some publicly verifiable record of "sane" backports-related decisions -- whether that's in the Ubuntu Studio PPA, or helping to test / process official Backports requests. I then mail the backports team and see if anyone "objects" (typically not). These procedures are not meant to be like the DMB's core-developer grilling sessions -- they're just in place so we don't have every MOTU on the Backports team and 95% of them remain dormant -- I'm sure at that point cjwatson will have to take me into the back room for "the talk" ;-)</div>
<div class="im"><br><blockquote type="cite">Hence my email today. So, I shall be backporting many Ubuntu Studio centric applications to the latest LTS version. I would be more than happy that they should be included into the official backports. Hopefully we can develop a relationship or agreement that accomplishes that goal.<br>
<br>Additionally, if you find it beneficial or preferable that one from the Ubuntu Studio team should join the Backports Team, then I gladly volunteer.<br></blockquote></div></div><br><div><br></div><div>I think that:</div>
<div><br></div><div>(1) You should still pursue the idea of an officially sanctioned Ubuntu Studio PPA because although there might be a big overlap between Ubuntu Backports and Ubuntu Studio Backports, there will be cases where you need to provide Ubuntu Studio users specific backports that are not appropriate for general backports.</div>
<div><br></div><div>(2) At the same time, the overlapping effort should not go to waste -- we welcome the contribution of any backports you feel are appropriate for the general -backports repositories.</div><div><br></div>
<div>(3) The Backports team seems to be perpetually overworked and understaffed :-/ back when I had hours and hours of time every day and just one role (Backports) within the Ubuntu community, I felt like I could handle everything related to backporting. That's clearly not the case anymore, and if someone on your team has a passion for backporting and would like to help with the general backporting effort, we'd be glad for that. The joining of the Backports team primarily gives you the permission to officially declare a package as suitable for backporting (i.e. like the -sru or -release ACKing). However, I should point out that 99% of the work is the QA and testing process leading up to the ACK and anyone can do that. I do peruse Launchpad bugmail relating to Backports and unfortunately I'd have to say most of the requests are stuck in that QA phase.</div>
<div><br></div><div><br></div><div>Please let me know if this information is helpful, and I look forward to hearing back from you guys!</div><div><br></div><font color="#888888"><div><br></div><div>John</div><div><br></div>
</font></div></div><br>