Proposing a New App Developer Upload Process

[Matthew Paul Thomas]

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

Scott Kitterman wrote on 06/09/12 22:02:
> 
> On Thursday, September 06, 2012 09:36:05 PM Matthew Paul Thomas 
> wrote:
> 
> ...
>> Scott Kitterman wrote on 06/09/12 14:22:
> ...
>>> To pick just one example, rolling delivery of applications and 
>>> offering multiple versions of the same package (which is what 
>>> the BSD Unixes do, although not in a way I've personally found 
>>> at all satisfying as a user) implies huge changes in package 
>>> management. Not the least of which is the ability to support 
>>> downgrades, including migrating per user settings back to 
>>> previous versions.
>> 
>> Windows, OS X, iOS, and Android all let an author issue a new or 
>> updated application within a week or so of wanting to, which I 
>> guess is what you mean by "rolling delivery". This whole 
>> discussion is predicated on that being a requirement for a 
>> mass-market OS.
> 
> On iOS and Android there's rather more extreme sandboxing than is 
> being proposed here that make potential interactions between 
> applications less of an issue.  The term DLL hell was invented for 
> Windows.  I don't think it's at all obvious that replicating the 
> existing systems is a path to success.

DLL hell or no, Windows and (lesserly) Mac OS were both popular for
decades before they both introduced sandboxing this year. But let's
leave aside the definition of "success".

What kind of sandboxing, specifically, do you think would be necessary
for hundreds of thousands of Ubuntu applications not to interfere with
each other? It seems to me there are four possible points of contention:
1.  package names (versus the OS archive, and versus each other)
2.  installed files
3.  saved documents and settings
4.  resource use (memory, CPU, network, peripherals) while running.

All four might have benefits, but for this particular goal I think
it's sufficient to have technical measures for #1 and #2. Do you at
least agree on that?

> There is an assumption here that there's a vast user base that 
> awaits if only it weren't so hard to run the latest versions of 
> things.

That's a misunderstanding. There are, indeed, users who get annoyed
when they can't play a game like Hedgewars online because the packaged
version of the game is too old for the server. (Raises hand.)

But the main motivation is that one of the things we need for a vast
user base is an order of magnitude more and better applications. And
one of the things we need to attract those application developers is
the ability for them to issue new and updated applications at will.
It's not sufficient, but it is necessary.

> ...
> 
>> None of those OSes offer application downgrades (though 
>> individual applications might). None of them migrate user 
>> settings to previous versions. ("The file “iTunes Library” cannot
>> be read because it was created by a newer version of iTunes.
>> Would you like to download iTunes now?") And absent that settings
>> problem, OS X is the only one that makes multiple application
>> versions moderately easy ("portable apps" on Windows being the
>> exception rather than the rule). That tells me that while they
>> might be desirable, none of those three things is a requirement
>> for a mass-market OS.
> 
> It is also quite normal for things to get screwed up on other 
> operating systems and people do a full reinstall to fix it.  One
> of the fundamental design principles behind package management in 
> Debian and by extension Ubuntu is that once installed, systems can 
> just be upgraded.  Reinstalls should not be needed.  I think this 
> is an important feature that should not be lightly abandoned.  I 
> think the implication of that is you've got to find a way to 
> support downgrades.

It is not an implication of that, because Debian and Ubuntu have never
allowed downgrades. Upgradeability may be a design principle behind
package management in Debian and Ubuntu, but downgradeability is not.

Lack of rollback in general is a big problem: woe betide you if your
battery runs out during an update. But again, that doesn't mean that
problem is best solved together with the app developer upload problem.
If you think it should be, now is the time to explain why.

> I think it's feasible, perhaps using something like etckeeper, but 
> it would take work.
> 
> Allowing areas where we beat the proprietary competition in 
> quality/ capability to degrade to their level is not a recipe for 
> success.

Beat them how? Windows Installer allows rollback to a known-good
state. dpkg does not.

> ...
> 
> The current ARB process and this new proposal are focused on a 
> specific class of applications that make use of some specific 
> restricted features of the operating system.  The current proposal 
> is geared towards that.  If the real goal though, is to deliver
> all applications this way, I think this proposal is not very
> useful because I don't think it's extensible in the ways it would
> need to be to grow into that.
> 
> ...

What else would it need? Be specific.

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBJxhMACgkQ6PUxNfU6ecrD/wCfXm48S0B0OfrL4RcQxRUmXatn
UF8An0saEjcrTWed9znx8bgfuWh7pNrV
=EXfy
-----END PGP SIGNATURE-----