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
> ( )
> 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
> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]