On Tuesday, September 04, 2012 06:01:56 PM Steve Langasek wrote: > Hi Scott, > > On Tue, Sep 04, 2012 at 05:50:12PM -0400, Scott Kitterman wrote: > > On Wednesday, September 05, 2012 12:11:18 AM Emmet Hikory wrote: > > > For application developers who prefer standard locations, I don't > > > see > > > > > > any reason we oughtn't simply add their packages to the repository with > > > immediate backport: in addition to allowing application developers to > > > put > > > their files in any policy-compliant location, it automatically provides > > > a > > > safe upgrade path for users. Even for software with release cycles that > > > require significantly more frequent updates than typically provided by > > > our > > > release cycle, there are few barriers to keeping this updated in > > > backports, > > > and users who have installed from backports will remain with backports, > > > so > > > their most active and interested users may be expected to always have > > > the > > > latest version, while highly conservative users will be able to enjoy a > > > consistent ABI during the life of a given release (although these users > > > would need to wait for our next release before using the package). > > > > +1. I've never understood why there is resistance to this. > > There's a general sense that the Ubuntu archive can't scale out to the > degree it needs to in order to take on the next challenges for the platform. > While Debian packaging isn't hard for you or me, and while it's definitely > gotten much easier over the past 4 years or so, it's still not so easy that > we blindly trust outside contributors to get the packaging right without > review by an Ubuntu developer. We do not have an infinite supply of Ubuntu > developers to do this review. Should the set of software available to > Ubuntu users through apt be limited to only that software that Ubuntu > developers (or Debian maintainers) have time and interest to take care of > directly? Or should users have better (not perfect, but better) ways to > install software that's not gotten the attention of the elite inner circle?
First, this elite inner circle has an open door. Second we also have a limited supply of ARB reviewers. Starting a new review process (ARB) because their aren't enough reviewers was clearly doomed from the start, so much of my "I don't understand this" comes from the current process where we substitute one review process with insufficient reviewers for another one with insufficient reviewers. Additionally, I think the notion that "Oh, X has a bazillion apps, so we need that many too" is mistaken in many regards. How many office suites do we need? I'd say one that works robustly, reliably, and compatibly with it's proprietary competition (and despite a huge amount of work by people deeply interested in solving this problem, IMO we don't have it). How many solitaire games do we need? I'm not sure, but I'm confident it's fewer than one finds in whatever Android Marketplace is called now. Historically, Linux distros have included a curated collection, some larger, some smaller, of relevant applications, libraries, etc that can be used on the base operating system. That curation process is one of the real strengths of Linux distributions and I think "Oh, let's have a bazillion of everything because it's there" is the wrong way to go. Yes, extras is separate, but not in any way that's meaningful to a user. Fundamentally, I think this process takes us in the wrong direction. So far the processes are not appropriate to the stated goal and the goal is, IMO, rather questionable. > The intent of Extras was always to make it easy for upstream developers who > know nothing about packaging policy to get their software in the hands of > users in as reliable and bug-free a manner as possible. To date, it has > fallen far short of this goal. We see 130 apps written for the recent app > contest that will never make it into Ubuntu or Debian, because no one will > ever package them the traditional way; and I think this is the tip of the > iceberg. Provided we can address the app isolation issues and streamline > the packaging helpers, doesn't it make sense for us to make this software > available to our users - all of it, not just the ones an Ubuntu dev looks at > and decides are personally interesting to them? Sure, there's going to be > some low-quality stuff in there that our users aren't going to want. But > isn't it better to let users judge this quality for themselves instead of > having it pre-judged by what Ubuntu developers choose to work on? I may > know a lot about putting together a distribution, but I'm a terrible judge > of what the next big thing will be that's important to users, and I'd > rather our users didn't miss out on it because of my poor ability to pick > the winners. There are a LOT of Debian/Ubuntu developers and non-developers involved in packaging, so I suspect the good stuff will get attention (I may be wrong). If such a system existed, then, if it was really clearly distinct from Ubuntu, I think it might make sense, but what's been done so far doesn't meet that goal and neither does what's specified. Build the system that makes this a reasonable technical/security approach and then use it, but right now the cart is before the horse. > Given this goal, then, backports is not a solution. Backports is a > necessarily heavy-weight process, of getting the package prepared, > sponsored (possibly after several rounds of feedback), through the NEW queue > for the devel release, and only then backported. That works for some > upstreams who can invest that time and energy, but it won't work for all of > them, and if it did I think the backports team would quickly reconsider the > workload. And it's a process that largely doesn't map to the goals of the > upstream who is trying to get their software into the hands of the users > running the current stable release, *not* to get their software integrated > into Ubuntu itself. It's entirely possible that some of this software > won't be relevant by the time the next Ubuntu release comes out! Why put > an upstream through a process optimized for long-term integration of the > distribution when all they care about is getting an app out to users that > gives them information about this month's beer festival? For this month's beer festival apps, I agree, but I get the impression that's not the norm. If there were the Ubuntu/Debian developers to do the reviews, I think the bulk of these things would be just fine as regular packages. To date, I think ARB has complicated things for not much gain. Back when MOTU was more active we reviewed a lot of new packages and got them in. We also taught a lot of people about packaging. If the push behind ARB recruitment and processes had gone instead toward enhancing Ubuntu development I think we'd have produced as much or more and Ubuntu would have more developers. > Does this explain better why there's resistance to using the backports > process for this class of package? No really, since I think that most of the packages that have been aimed at the ARB are not "this month's beer festival" apps. They are things that could have been packaged normally just fine. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
