Re: continuing conversation from UDS-N - Application Review Board
I've drafted a proposal for the Tech Board based on our discussions at UDS and on ubuntu-devel. The ARB is still reviewing it, but we'd also like to open it up for broader review: https://wiki.ubuntu.com/PostReleaseApps/MaverickExceptionsProposal Let us know of any changes (anything I missed, or that doesn't seem to accurately reflect the discussions). We'll try to finalize it next week. Thanks! Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Naming sessions in Launchpad for UDS
(I know I'm very late to this discussion, but want to make sure this is clarified) On Wed, Oct 06, 2010 at 03:27:29PM -0600, Duncan McGreggor wrote: > Let me break that down for easy viewing: > * Application Developers > * Application Selection and Defaults > * Cloud > * Development Process > * Hardware Compatibility > * Other > * Ubuntu the Project > > We had 9 tracks last year and filled them pretty well. We're looking at > at 2 less this year (as defined above) and probably even more sessions > than last time (every year our material has grown). If you missed it, you might want to review http://mdzlog.alcor.net/2010/05/27/rethinking-the-ubuntu-developer-summit/ for some rationale for updating the format. We haven't added or subtracted tracks; we've arranged them on a different axis. Sessions are now listed by topic, rather than by which team happened to submit them. > Unless we're cutting out slots and pushing outlying session topics into > the community for discussions instead of proper UDS sessions... We do not "push topics into the community", because we are part of the community. UDS is a community event, and all of the sessions at UDS are "proper", whether they come from a Canonical engineering team like yours or an individual with a passionate interest in the subject. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Application packaging (Re: brainstorming for UDS-N - Application Developers)
On Fri, Oct 01, 2010 at 05:56:27PM +0100, Evan Dandrea wrote: > > On Tuesday, September 28, 2010 05:31:26 pm Rick Spencer wrote: > > > We want to empower, engage and harness application developers to develop > > > on and for Ubuntu. These sessions cover the many elements in achieving > > > that goal. > > > > > > What's high on your list for this area? > > > > > > There are some existing conversations and threads that people should > > > feel free to comment on in addition to any new areas: > > > * Changes to the implementation of the New Apps on stable releases > > > (suggestions have included changing the system to use backports as an > > > avenue onto a stable release, for example). > > > * Changes to the Application Review Board process (including, for > > > example, eliminating it and replacing it with a streamlined backports > > > process). > > > * Enhancement, changes to tools such as Glade, Gedit, etc... > > > * Anything about Quickly and/or Quickly Widgets, including new > > > templates, improvements to the existing template, new widgets, etc... > > > * Information Architecture for application developers, including a > > > developers manual, etc... > > > > If we are going to meet the goal of really streamlining the process for > > developers to get their applications in front of users, then we need to > > change > > what it is that is delivering the application. I don't think that a > > traditional Debian package is going to be able to support a truly > > lightweight > > process. > > Thank you. This is something I've been thinking about for quite a while and > it's comforting to know that I'm not alone in what entrenched minds must find > to > be very radical thinking. You might also be interested in http://mdzlog.alcor.net/2010/07/06/weve-packaged-all-of-the-free-software-what-now/ which I posted back in July. It is a radical perspective (questioning our fundamental model), but it is not unheard of. > I think our current architecture for packaging and delivery is built on top of > some misconceptions. Namely, that we can solve the problem of buggy software > getting into Ubuntu by fixing bugs in applications on behalf of developers, > that packaging needs to be complex, and that we should be and ultimately need > to be doing the legwork to package these applications ourselves. I can't speak for anyone else, but I certainly don't suffer from any such delusion. Packaging is not about keeping bugs out, but about getting software in and getting it working---together. > We need to make it so that developers can quickly deploy an application that > then appears in Ubuntu Software Center for anyone on that release of Ubuntu, > regardless of where we our in our own cycle. The current effort in this area is based around Debian packages, and is an incremental step from where we are today. We can and should continue to improve and simplify it from there. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: brainstorming for UDS-N - Application Developers
On Thu, Oct 14, 2010 at 09:14:46PM +0100, Colin Watson wrote: > On Fri, Oct 01, 2010 at 05:56:27PM +0100, Evan Dandrea wrote: > > I believe that in order to do this properly, we need to massively > > simplify our packaging model. Anything that makes a package > > non-atomic (hello maintainer scripts) should be thrown out. Anything > > that adds needless complexity, equally so. Packaging needs to be the > > least important part of the puzzle, not the most difficult, and most > > certainly not at the core of our own development efforts. > > There are few pressing reasons to change the *binary* package format > significantly, and many reasons not to. The core implementation is > robust yet flexible, knowledge of bits of it is in lots of different > parts of the core system, we use many of its features in non-trivial but > mission-critical ways, and you generally only want to have one package > manager on the system rather than having two of them fighting it out. > Plus I rather suspect that if we tried to reimplement it then the > chances are good that we'd end up in a situation where we had two > package managers neither of which quite met our needs. I don't think we need to replace dpkg, but I think it might be beneficial to have more than one subsystem for managing installation of components. The requirements are very different at each end of the scale (low-level system libraries to distributed applications). (I elaborate on this in http://mdzlog.alcor.net/2010/07/06/weve-packaged-all-of-the-free-software-what-now/) While in some cases it may be sufficient to simply ignore the more complex features offered by dpkg, I think there are fundamental assumptions there which are much harder to remove (e.g. root privileges). That said, I agree with you that there are gains to be found in how we work with source packages. -- - mdz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
