On Fri, 2013-01-04 at 14:05 -0500, Colin Walters wrote: > On Wed, 2013-01-02 at 11:23 -0800, Travis Reitter wrote: > > > I think our best bet for a usable SDK would be something that sets up a > > QEMU instance on top of OSTree > > I have scripts for this > ( http://git.gnome.org/browse/gnome-ostree/tree/src/ostbuild/ostbuild-qemu-pull-deploy?id=d99b501bb0fbc5c866f7f7774b1c7710308ddbd1 ) > > but really the whole ostree/gnome-ostree stack here needs significant > levels of work and polish. > > > Being able to build against a single set of > > pre-built binaries should dramatically lower the trouble of getting > > started with development on Gnome. > > The question here is build...what? Applications? Or contribute to the > desktop itself? These are quite independent things with potentially > quite different tools to use. Certainly, they're different use cases. I would think an SDK would be primarily targeted to third-party application and library developers. But I don't think it should be too much of a stretch to make it usable for first-party application and library developers as well, since there should be a fair amount of overlap there (and the dogfooding would help quality a lot). I think the main split is between the development above and lower-level desktop development (daemons like D-Bus, libraries like glib and pulseaudio, systems like systemd). > > Every time I start a new jhbuild build tree, it's a very long and > > painful process. And every full-tree update is a big risk. > > Yeah, and there is still yet more we can do to jhbuild to make things > better here; the two biggest things are: > > 1) improving the sysdeps tooling see > https://bugzilla.gnome.org/show_bug.cgi?id=691036 for an example case > where it works on OpenSUSE/Fedora, but fails on Debian due to confusion > over the package split > > 2) Maintaining autobuilders; see my other mail These would certainly help a lot. Jhbuild itself isn't usually the source of the problems; but its design isn't resilient to module build breaks (which are way too frequent) and excessive re-building of any modules which aren't directly interesting to most developers. As a library developer, I only really care about my library, its direct dependencies (mostly that they don't break API) and my consumer applications. Most of the time, I only want to work with a few modules, so constant churn of a few hundred others is a distraction I'd like to minimize. And application developers don't even have the "consumer application" modules to care about. Those two points above could go a long way to improving development experience.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature