brainstorming for UDS-N - Application Developers

Wed Oct 6 03:14:26 BST 2010

On Tue, 2010-10-05 at 17:04 +0200, Krzysztof Klimonda wrote:
> On Tue, 2010-10-05 at 12:57 +0100, Matthew Paul Thomas wrote:
> > > 
> > > Yes, it is a problem but not that bad. If application is popular there
> > > is a good chance that both upstream and ubuntu developers know about it
> > > and keep it maintained. That leaves a lot of packages that don't have
> > > any active Ubuntu maintainer - some of them are cared by upstream
> > > developers who ask us -- either by sending mail to the u-d-d mailing
> > > list or by asking on #ubuntu-devel/#ubuntu-motu IRC channel -- to
> > > upload a fix. That of course, leaves quite a bit of applications but,
> > > at least in my opinion it's not that usual to say that we have to
> > > revamp it.
> > 
> > That's to be expected, if people heavily involved in that process seldom
> > compare it with other platforms.
> 
> Point taken, I'm awaiting the "Application Developers" track where we
> can discuss that and present differences.
> 
> > 
> > >> There has never been a "big distribution". No distribution, Ubuntu
> > >> included, has ever had more than 2 percent market share.
> > > 
> > > big in terms of developers, of processes used for development etc
> > > rather than the market share
> > 
> > The worst of both worlds, then: complex processes *and* low market
> > share. :-)
> 
> But I'm trying to point out the the processes are fitting the current
> development style.
> 
> > >...
> > >> Yes, that's part of the problem. Packaging should not require that
> > >> experience and understanding of the system. Thirteen-year-olds write
> > >> and sell iPad applications.
> > > 
> > > No, they can't. You have to be of the legal age (and pay $99 a year) to
> > > even get a chance to send your application for a review.
> > 
> > <http://itunes.apple.com/us/app/ichalkboard/id322491414?mt=8>
> > 
> > When iChalkboard 1.0 was released, its primary developer was 13. Its
> > designer was 14.
> 
> Great project but they still had to have a help with submitting it to
> the Apple. It's hard, for me, to tell how easy had it been for them to
> do it - and there are both 14 years old maintainers and 14 years old
> programmers in the FOSS world.
> 
> But yes, we could make the process easier - there actually has been some
> work being done on this front in Debian. The DEP-5 proposal (machine
> readable debian/copyright) would also make it possible to generate
> copyright file from the IDE - most projects are fairly simple in license
> terms anyway.
> 
> The hardest part of packaging that remains is debian/control and it also
> could be made simpler if our plugin for Anjuta had enough informations
> from other sources.
> 
> > >> Do you think that more than one in a thousand users of the average
> > >> Ubuntu application have ever looked at its changelog?
> > > 
> > > So? Are you suggesting that we should not care about those, more
> > > technical and knowledgeable users?
> > 
> > No -- just that changelogs, as they are currently written and presented,
> > fail miserably at the task of making "it easier for our users to make
> > sure what can they do with their software". I'm sure we could fix that
> > in ways that don't require packaging to remain complex.
> 
> Yes, they could be better - and their quality doesn't really depend on
> the complexity of packaging. It's just both tedious and, in some cases,
> hard to write a decent (i.e. readable and interesting) changelog. We
> should probably split changelog into two parts - a maintenance changelog
> where we keep all the changes that has been made to the packaging and
> the one for application - where new features and outstanding bugfixes
> are mentioned.
> 
> > >> <https://wiki.ubuntu.com/PackagingGuide/Complete> is 16518 words long.
> > >> Even the "Basic Packaging" section alone is longer than the US
> > >> Declaration of Independence, and the original US Constitution,
> > >> combined.
> > > 
> > > But that's a different problem - yes, we can work on getting our
> > > documentation fixed. At the same time creating a packaging for a single
> > > Desktop application takes few minutes assuming it uses autotools or
> > > another build system supported by debhelper - e.g. debian/rules is 3-4
> > > lines long, debian/changelog is created by dh_make, there is no need
> > > for maintainer scripts other than those created by debhelper.
> > 
> > I take your word for that, but everyone I know involved with packaging
> > (up to and including Michael Vogt) tells me that it's unreasonably
> > difficult in general.
> 
> The complexity quickly grows as the packaged software gets more complex
> - it's much harder to package and maintain library or system-wide
> daemons then it is to package a "leaf" program - some Desktop
> application for example.
> 

I'd like to amplify this.  For the leaf-node applications I've packaged,
debian/copyright has taken the *vast* majority of the packaging time,
and coming up with a good package description is the second biggest
task.

It's only when you want to do something a bit more complex, like
splitting the app into a base package + plugins that the packaging
becomes at all complex.  Or when the software requires some uncommon
steps to build from source.

> > 
> > As Marc Deslauriers says, we could have a one-click "Package and submit
> > to Ubuntu Software Center" plugin for Anjuta, and similar for other
> > IDEs. That would be a good step. But we'd still be subject to the Law of
> > Leaky Abstractions: if anything went wrong, it would be hard to figure out.
> 

I don't think it would be particularly hard to debug - it would be quite
easy to machine-generate a package that looks the same as what I'd
manually create, so it would be no harder to debug than the current
state of affairs.

Ignoring debian/copyright, the packaging of most software needs three
things:
1) The commands required to build from source (which the IDE clearly
already knows)
2) The list of dependencies required to build from source (which the IDE
probably knows, and dpkg -S can resolve to a package name)
3) Some metadata - description, homepage, etc

For the sort of leaf-node apps I think we're talking about, this would
be reasonably easy.

> > 
> > >...
> > > But is it because the process is wrong or because people are not aware
> > > of it? Maybe promoting backports (and allocating more resources to make
> > > it snappier) is a better way.
> > 
> > It's worth a try, sure. But we don't have enough decades to try things
> > like this one at a time. Let's try other things as well.
> 
> Sure, that's a great plan but I'm not sure if that's going to work. At
> the end the process that is going to get choosen is the one that more
> resources has been put into.
> 
> > 
> > >...
> > >> In the past four years, not one but two operating systems have each,
> > >> starting from zero, accumulated more than 20 *times* as many
> > >> applications as Ubuntu has. What we are doing is not working. It's
> > >> time to try something else.
> > > 
> > > Why? Most of application for both iPhone and Android are completely
> > > useless. You can hear people complaining about it all the time - dozens
> > > of applications doing the same thing, "fart apps", direct clones. Sure,
> > > they inflate the number of total applications but I'd disagree that
> > > they make platform more appealing to users.
> > 
> > Any sufficiently large collection of things is subject to Sturgeon's
> > Revelation. But iOS and Android customer growth speaks for itself.
> 
> But are they growing because of tens of thousands applications available
> or because both are that much better than their competitors and both get
> an enormous media campaigns?
> 
> Yes, we need more great applications. But are we going to get them only
> by making publishing them easier? People are willing to do everything to
> get their application published in the iTunes store because they see
> others making hundreds of thousands of revenue out of their
> applications. 
> 

Yeah, I'm not sure about this either.

That said, I think it's perfectly reasonable to want to make it easier
to deploy apps on top of Ubuntu but I wouldn't want that to happen at
the expense of the base Ubuntu experience.

One of the problems I have in this discussion is that I'm not entirely
sure what *specifically* I want the base Ubuntu experience to be.
Bouncing around ideas at UDS will hopefully solidify that.

> > 
> > >...
> > >> Why would a developer want to bypass checks that would help save them
> > >> from disappointing their users?
> > >>
> > >> Do you have any examples of sanity checks that produce unfixably wrong
> > >> results?
> > > 
> > > Yeah, If we make it easier and easier to get applications into our
> > > software center it's going to get worthwhile for attackers to use
> > > software center as a point of attack for users' computers. To either
> > > tamper with their data or to just use new computers for a botnet of
> > > sort.
> > 
> > Attackers can do that with a PPA right now, where it's even less
> > tractable -- there's no "Report as inappropriate" button on a PPA page.
> 
> Yes, and that's my biggest problem with the PPA model. There were a
> discussion about creating something like "a trusted PPAs" for people who
> are Ubuntu or upstream developers so they could, for example, distribute
> nightly builds of software.
> 
> > 
> > Keeping our OS secure, by having processes that result in it having few
> > applications, is just a large-scale form of security through obscurity.
> 
> It's a much easier thing to screen application the way Apple does with
> the iTunes Store when you have a complete control over a platform. It's
> also much safer not to verify applications (Google doesn't have an
> approval process afair) when your platform is designed to be as safe as
> possible. Our platform is neither designed with this goal in mind or in
> our total control.
> 
> We could start working on a sandbox for applications - but is it really
> how we see the future of Desktop Linux?
> 
> > 
> > >...
> > >>> [1] I use "for our users" quite a lot - that's because what is good
> > >>> for developers (or even for us) is not always good for the users of
> > >>> our distribution - for example developers want to push their new
> > >>> software to as many people as possible in as little time as possible
> > >>> but, on the other hand, not all users are interested in the newest
> > >>> and greatest stuff.
> > >>
> > >> That decision should be up to individual users and organizations.
> > > 
> > > But if we don't prepare small patches for applications the choice we
> > > leave our users with is whether they should keep current software and
> > > deal with bugs (and security patches) or should they update. Various
> > > upstream projects use different development models and not all of them
> > > release point releases with bug fixes.
> > 
> > Ubuntu users already have that problem, in the worst possible way. Your
> > organization needs the new version of LibreOffice? Oh, sorry, you'll
> > have to upgrade your entire operating system, getting new versions of
> > every other application at the same time. Good luck with the retraining!
> 
> That's what -backports are for. They don't work because there are so
> little people working on them.
> 
> > 
> > >...
> > >>> Things like this are done - beta tests etc. but not at this level. It
> > >>> would feel like we, as Ubuntu, are limiting our users.
> > >>
> > >> Things like this are often done at this level, and at much larger
> > >> levels. Twitter is doing it right now with 105 million registered
> > >> users. Microsoft does it for Office's half a billion users. And
> > >> Facebook also often does it with half a billion active users. They
> > >> would be incompetent if they didn't.
> > > 
> > > And neither of those companies and projects is based on free software
> > > and a community of supporters, developers and advocates. It's one thing
> > > for developers of closed applications or services to decide that they
> > > want only a part of their users to have an access to new software
> > > version (and we should provide tools for them to do that) and a
> > > different one for free software projects to do that - if only because
> > > it's not entirely free and open model.
> > 
> > I don't see any reasons there. How does the licensing model have
> > anything to do with the rollout process? For example, I'm pretty sure
> > that any changes to Launchpad's rollout process since it was closed
> > source have nothing to do with the fact that it's now open source.
> 
> 
> Everyone has a choice to use the edge Launchpad server. My understanding
> of the proposal was that the developer chooses how many people are
> allowed to use a beta software and others don't have access until later.
> 
> > 
> > >...
> > > All points I'm making here (and in the previous email) are probably
> > > only valid if we keep the current development style. But the email I
> > > was answering for was not about whether we should change Ubuntu from
> > > the current model (where its, in fact, a software distribution) to the
> > > model where we ship only a base system, a software store/center and a
> > > set of libraries for developers to develop for Ubuntu. I actually
> > > believe that it would be a really good idea to focus ourselves only on
> > > a core system, but that requires quite a lot of discussion.
> > >...
> > 
> > Cool. Those aren't the only two options, though. We could ship a basic
> > set of applications (browser, mail client, basic word processor, media
> > player, etc) like Windows and Mac OS X do, *and* change the model for
> > distributing other applications.
> 
> Yes, by the "base system" I've meant both the system, DE and a set of
> applications that are choosen as default. Also, what about libraries?
> Who should package them?
> 

That's easy.  We (Ubuntu) provide the same set of libraries we currently
provide - possibly with some extra binary-compatibility sauce, like
ensuring that an SONAME that's available in $LTS will be available until
$(LTS+1).  If an app needs an unpackaged library it can bundle it
privately; that's basically what currently gets done by upstreams,
anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20101006/307779a8/attachment-0001.pgp 