brainstorming for UDS-N - Application Developers

[Matthew Paul Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Scott Kitterman wrote on 06/10/10 06:20:
>
> On Tuesday, October 05, 2010 09:19:41 am Matthew Paul Thomas wrote:
>...
>> For example, in Natty we'll be doing work that makes it easier to
>> visually distinguish core updates from application updates.
>> <https://wiki.ubuntu.com/SoftwareUpdates?action=AttachFile&do=get&target=up
>> dates-list.jpg> That alone would make it much easier for someone to
>> (for example) postpone an application update to a weekend when they
>> have time to troubleshoot any problems. In future, it might even be
>> possible for them to roll back to the previous version.
> 
> So it's better to accept a library update when you don't have time to 
> troubleshoot?  I don't think this distinction is terribly helpful.

By spending less time on other people's applications, we could spend
more time testing fixes to Ubuntu core.

> Open Office may be a leaf application, but if I've got a presentation
> I have to get finished to give to a customer tomorrow, it's a lot more
> mission critical to me at the moment than any number of core libraries.

Exactly.

>...
>>>> Every general-purpose operating system has gone through a stage
>>>> where the primary publisher of software for it was the OS vendor
>>>> themselves. Every popular general-purpose operating system quickly
>>>> outgrew that stage.
>>>
>>> The Linux distribution paradigm is different than other operating
>>> systems.  I don't think the analogy is relevant.
>>
>> I'm interested to know why.
> 
> Why it's different, why it's a good thing it's different, or why
> drawing analogies from things that are substantially different has
> little relevance?

Why the difference is relevant. (I don't think it's even an analogy, but
rather a general pattern.)

>...
> But it can't be done by fiat.  We didn't achieve the packaging system
> we have now accident and it will take good engineering work to get to
> something that is both simpler and functional.  I don't know of anyone
> that defends the current complexity of packaging as a good thing, what
> we lack is tools to to get there.  Additional theorizing that it should
> be easier, doesn't really help.

Several concrete ideas have already emerged from this discussion.
Calling them "theorizing" doesn't really help.

>...
> Debian/changelog isn't meant for non-technical end users.  If you want 
> something that is, we need something different.  The packaging
> changelog serves it's own useful purpose.  The fact that it doesn't
> also serve this purpose is not a deficiency in debian/changelog.
> That's out of scope for it.
> 
> OTOH, it's difficult enough for technical people to write text that is
> sensible to non-technical users.  Please don't insist I learn some new
> markup language too.

Fair enough. We don't want to be in Microsoft's situation of waiting to
release a security update until a corresponding Knowledge Base article
has been written and translated into 23 languages.

So, one thing that might help is a log of "What this update does"
separate from debian/changelog (or maybe this can be demarcated inside
debian/changelog somehow).

Second, providing template plain-English text for maintainers to use for
different kinds of update -- even as simple as "Fixes a problem where
______ would ______" or "Fixes a security problem where an infected
document could ______".

Third, setting up a team of recognized tech writers for small tasks like
this, so someone preparing an SRU can hop into an IRC channel and get
advice on text for their update.

>...
>> That's true. The App Review Process is a very small step.
> 
> It's not a technically well founded step.  We should be doing the
> engineering of something that is suitable for a lightweight review and
> approval process before we deploy one.  The current App Review Process
> if more like shuffling the deck chairs on the Titanic.

So, given that the ARP already exists, what would a lightweight process
to replace it look like?

>...
>> <http://launchpad.net/ubuntu/+spec/foundations-n-backports-notautomatic>
> 
> That's the one.  It covers changes to the apt resolver to deal with 
> dependencies in a non-automatic repository, changes to make -backports
> not automatic, and U/I to present multiple versions of packages to
> users sensibly (once backports is not automatic, they'd need to be able
> to pick if they want the stable release one or the new one from
> backports).

Ok, that seems like it would involve tweaks to the design of Update
Manager (and maybe Ubuntu Software Center too). Subscribed.

>...
> Right, but Android Marketplace is primarily a source for external 
> applications.  In a Linux distribution that isn't the case.  I
> relatively routinely run into bugs or mailing list messages  where
> people are complaining about PPA packages, so I already see this as a
> problem.  Third party applications (or changes to existing packages)
> are already too closely identified with Ubuntu.
>...

We already distinguish "Provided by Ubuntu" vs. "Independent" in Ubuntu
Software Center. But as we accumulate independent applications, it will
become more important for USC to say *who* develops a particular
application.

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkysXBQACgkQ6PUxNfU6ecrwXQCfdH1/SyHko/rpRSnialRkBW4e
99IAn2LGVp7iog0btbQxYwHV9487A+vP
=Yysj
-----END PGP SIGNATURE-----