Re: Ubuntu and derivatives (Re: Ubuntu.com Download Page)
On 01/25/2013 03:17 PM, Jordon Bedwell wrote: > On Fri, Jan 25, 2013 at 5:13 PM, Allison Randal wrote: >> On 01/25/2013 02:38 PM, Scott Kitterman wrote: >> Each flavor has a dedicated landing page: kubuntu.org, edubuntu.org, >> xubuntu.org, ubuntustudio.org, mythbuntu.org, lubuntu.net. The one for >> *U*buntu (with *U* for Unity is ubuntu.com. > > By that flawed and short-sighted logic how do you explain Ubuntu with > a G for GNOME up until a couple of years ago? That was meant to be "*U* for Unity ;)", but the winky got lost when I had to manually retrieve/resend the message. (Mailman isn't as smart as Launchpad about figuring out messages sent from one of many different aliases.) The fact is, "Ubuntu" is the name of two distinct things: a project encompassing many flavors, and one of those flavors. Recognizing which one you're talking about at any given moment helps immensely. Allison -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu and derivatives (Re: Ubuntu.com Download Page)
On 01/25/2013 02:38 PM, Scott Kitterman wrote: > Ubuntu.com is an element of Canonical marketing. Don't be confused into > thinking it's more than that. Each flavor has a dedicated landing page: kubuntu.org, edubuntu.org, xubuntu.org, ubuntustudio.org, mythbuntu.org, lubuntu.net. The one for *U*buntu (with *U* for Unity is ubuntu.com. The centralized page for the Ubuntu *Project* is wiki.ubuntu.com. This seems right to me, as it's open for collaborative ownership by all flavors, all members. It'd be quite appropriate to add a prominent link from the main page of the wiki to: https://wiki.ubuntu.com/DerivativeTeam/Derivatives Allison -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Fwd: Chef-server
On 12/21/2012 11:45 AM, John Moser wrote: > > Packages and source tarballs appear available from this location: > > http://apt.opscode.com/pool/main/ > > Potentially these are appropriate for multiverse, if the Chef developers > are willing to submit them. Some packages in Debian have DFSG > designation, so I assume some modifications are necessary for inclusion > of Chef in Universe or Main. > > I am simply at a loss as to why some packages have been brought over, > yet others have not. Perhaps the client is simply more "open" and thus > easier to import by policy, and so the bits needed to interact with a > server are brought in functionally but the bits needed to run a server > are left out. That would at least be a valuable effort and explain the > current state of things. But that is simply speculation on my part. Chef has never been terribly interested in supporting distro packaging. Last I checked, their custom apt repository heavily modifies some core packages (outside the chef package namespace) in ways that could never be accepted into Debian/Ubuntu. They treat it as an "appliance", not as independent packages. I asked OpsCode about this a few months ago when I was doing a Chef/Puppet assessment for a client, and they didn't seem to have any interest in normalizing their packages into something distributable. Allison -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Proposal to delay release of Precise Pangolin
On 12/13/2011 12:11 AM, James Freer wrote: > After reading the following posts i wanted to raise the release issue. > It seems that staff are under a lot of pressure to deliver the 6 > month releases as well as LTS. I've been using Ubuntu for about 5 yrs > and it seems that quality varies between releases likely due to the > pressure staff are under. > > Would it not be better for all to produce an annual version that's > allowed time for testing and bug fixing. LTS is ok but second year and > one is starting to find quite a few apps that have been updated and a > six month release simply doesn't give adequate time for staff. If > you're wondering what i do... i'm an april updater A release cycle that's twice as long doesn't really give you more time to test changes, it just gives you twice as many changes to test. And it makes some kinds of changes much more difficult, because they need to be staged over multiple releases for a smooth transition. Here's a good post (short): http://jroller.com/thuss/entry/there_are_pros_and_cons But if you have time, I recommend reading Martin Michlmayr's full Doctoral dissertation. http://www.cyrius.com/publications/michlmayr-phd.html >From the conclusion: == In contrast to traditional software development which is feature-driven, the goal of time based release management is to produce high quality releases according to a specific release interval. This dissertation has shown that feature based release management in FOSS projects is often associated with lack of planning, which leads to problems, such as delays and low levels of quality. [...] Time based releases are associated with two factors that act as important coordination mechanisms: 1. Regularity: the production of releases according to a specific interval allows projects to create regular reference points which show contributors what kind of changes other members of the project have made. Regularity also contributes to familiarity with the release process, and it leads to more disciplined processes. 2. Schedules: by using time rather than features as the orientation for a release, planning becomes possible in voluntary projects. Time based projects can create schedules which describes important deadlines and which contains dependency information between different work items and actors. Together, these mechanism reduce the degree of active coordination required in a project. Developers can work on self-assigned work items independently and with the help of the schedule integrate them into the project in time for the release. As such, the time based release strategy is a means of dealing with the complexity found in geographically distributed volunteer projects with hundreds of contributors. == Allison -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Ubuntu should move all binaries to /usr/bin/
On 11/01/2011 03:20 PM, Cosme DomÃnguez wrote: > > But it requires a lot of work that I think should start first in Debian. And, is already being discussed in Debian (lengthy thread): http://lists.debian.org/debian-devel/2011/10/msg00157.html Allison -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Proposal to delay release of Precise Pangolin
On 10/19/2011 06:02 AM, nick rundy wrote: > Put the "rapid release" schedule > on hold temporarily and make an LTS that fixes this stuff. You'll be pleased to know that bug fixing and quality improvements are precisely what people are focusing on for the LTS. You won't see much in the way of new features proposed at UDS-P. This is common for LTS cycles, but especially strong this cycle. "Quality" is a big part of being "Precise". :) It's a common fallacy in software development, thinking "If I only had a few more weeks, I'd make it so much better". In fact, time-based releases don't decrease quality, they improve it. Martin Michlmayr gave a great talk on this at Google a few years ago, based on his research at Cambridge: http://video.google.com/videoplay?docid=-5503858974016723264 Allison -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Fwd: FOSDEM 2012 cross-distributions devroom
Original Message Subject: FOSDEM 2012 cross-distributions devroom Resent-Date: Wed, 28 Sep 2011 11:24:39 + (UTC) Resent-From: debian-devel-annou...@lists.debian.org Date: Wed, 28 Sep 2011 13:23:14 +0200 From: Wouter Verhelst Organization: The Debian Project, http://www.debian.org/ To: debian-devel-annou...@lists.debian.org Hi all, It's that time of the year again: FOSDEM organisation is firing up, which means I get to ask for talks again. As during the two previous years, Debian has been invited to participate in the cross-distribution devroom. This means that talks will be held in front of an audience not only consisting of people involved with Debian; instead, the expected audience will consist of people from many different distributions, as well as other people--regular FOSDEM visitors. Still, there is no reason to assume that Debian-specific talks will not be welcome. However, there won't be as much time for that as there was before FOSDEM 2010. Having said that, People interested in holding a talk at FOSDEM are hereby invited to submit a proposal. This should be done by sending a mail to the relevant mailinglist (distributi...@lists.fosdem.org, subscription required -- http://lists.fosdem.org/listinfo/distributions), containing the following information: - Title of the proposed talk, - Abstract of the talk - Name of the speaker - Bio of the speaker - Requested amount of time for the talk Thanks, and see you at FOSDEM, -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Brainstorming for UDS-P
Hi all, While we're all in the final preparations for Oneiric, it's round about that time in the cycle to start thinking about plans for the next cycle. What's on your mind? Allison -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [Oneiric-Foundations-Topic] networked client app updates
On 04/26/2011 11:53 AM, James Westby wrote: > On Thu, 21 Apr 2011 18:23:52 +0100, John Rowland Lenton > wrote: >> * if our projects switch to, say, python 4, then we'd be looking at >> shipping python 4 to all supported ubuntus, including LTS'es. > > I can see why you would want to do this for ease of support, but it's > common for projects to support several versions to avoid this > requirement. > > In addition, making a change like this would likely have effects far > beyond u1, in order to allow u1-on-lts to use a Python version that may > not have been available when it was released. This is where the /opt/.../UbuntuOne/... install location comes into play for dependencies. Simply using backports means the updated library/tool affects the entire system, which is likely to be a nightmare. Installing a version in /opt, which only one app can find, is safer. My gut reaction is that installs of dependencies in /opt should be very rare, and paved with warnings to the app developers of "You understand that you are *personally* responsible for this version of the library you're installing with your app? And it darn well better not leak out into the rest of the system!" But, it does fit with general Linux development practices in the wider world. >> * it's easy to imagine scenarios where we'd want to ship updated >> versions of rhythmbox, banshee or nautilus (and/or any newer >> application that integrated with our apis). Much more commonly we'd >> want to update plugins to those apps. > > Why would you want to upgrade the apps themselves? > > This seems to be getting away from what I thought was the original > question in the discussion, and in to the more general territory of > wanting to push new stuff in to released versions, and perhaps it is > worthwhile to separate those discussions if possible? This is a cost/benefit question. Chances are it's very expensive to do the integration and maintenance work on non-standard versions of all those apps, and much less expensive to maintain multiple variants of the plugins. But, it's appropriate to consider the problem on both sides as we work our way toward the best solution. >> the thing we need is to have as much feature parity as is possible >> across all the platforms we support, > > This seems to be a core point of contention. Perhaps you could explain > why feature parity across versions of Ubuntu is important to your team. > > As I understood the original question it was how to update client code > to keep it in sync with changes that the server makes. It would be > possible to do that in order to keep old features working and not enable > new features on the old releases. A desire to push new features in to > old releases is valid, but seems to be a different question to me, and > not one that has a lot to do with the code in question being a networked > service client. The key feature of a lightweight client app like this is "the ability to connect to the remote service". It is possible to maintain 5 versions of U1 client that each implement the latest connective features, but depend on only the versions of various libraries/tools available in each supported distribution. That's one for (to take a snapshot today): - Natty, the upcoming release - Maverick, the current release - Karmic, the soon-to-be-removed non-LTS release - Lucid, the current LTS release - Hardy, the soon-to-be-removed LTS release And, it might even be reasonable to ask the U1 team to continue with this rather hefty maintenance burden perpetually, since they happen to be backed by a company that deeply believes in the Ubuntu release cycle. I'm not so sure it's reasonable to ask other developers of other networked client apps to carry similar maintenance burdens. Or at least, we can ask them to, but they're perfectly free to say "No thanks, we just won't bother with an Ubuntu version". Or, they'll do what Dropbox does, and just maintain their own "pirate radio" repository just for their client app, completely avoiding the standards and quality control Ubuntu has in place for repositories. That's not necessarily a bad thing, there's always room for the chaos of evolution. But, the fact that we have multiple projects all stumbling around the same problem also means this is an opportunity to be opinionated, solve the problem once in a way that really fits with Ubuntu, and set an example in U1 for the best way to implement updates for a networked client app on Ubuntu. There are definite advantages to a clean set of thoughtfully developed standards. Allison -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
[Oneiric-Foundations-Topic] networked client app updates
The Ubuntu One developers have an interesting technical conundrum that would benefit greatly from all of your thoughts. They've started collecting ideas, and would like to collect more, and hopefully settle down on a plan for the next cycle in a UDS session. The basic problem is in keeping a networked client in sync with a networked service. In the wider world this is generally handled by releasing an update for the client whenever the service changes. Ubuntu One has been tying the development cycle for their service to Ubuntu's six month cycle, so client feature updates only happen in new distro releases. But, even that doesn't quite work, because once you change the service then clients on older distro releases (especially LTSs) still need the feature updates to connect to the updated service. Sometimes these feature updates depend on newer versions of libraries than exist on the older distro releases. The category of lightweight client apps for a remote service is becoming more and more common, so ideally a solution for Ubuntu One will be one we can recommend to all app developers. Here's a grab bag of brainstorming so far: - Only ship a very small shim for the client on the CD (advantage of small footprint), and do the rest of the install the first time someone uses Ubuntu One. - Ship Ubuntu One client in extras, backports, commercial, or partner repository. (Better if it's on by default than requiring a manual step to enable the repository.) - Ship Ubuntu One client (only) in a PPA. - Implement "self updating" within the client, similar to Firefox/Thunderbird (on non-packaged installs). This is the most complex technically, so not the most appealing. - Pull some update dependencies into /opt/.../UbuntuOne/lib, to keep them completely isolated from the rest of the system, but available to the Ubuntu One client. Do you all have more ideas or suggestions? Allison -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
