[sugar] Activity versioning schema

[Martin Dengler]

On Wed, Jul 16, 2008 at 06:52:28PM -0400, Michael Stone wrote:
> Do you require more justification?

Yes, qualified: not now, being the main qualification.  Tell everyone
to sod off and wait until update.2's out :).  Wait til then unless you
cannot, and in that case just declare something by fiat and tell
people to wait a month or two.

> Regards,
> 
> Michael

Martin

PS - I read your cited wiki pages (even found myself tangentially
included in one tiny circumstance) and I think most of the
confusion/discussion is *not* about why the package manager / updating
process needs to be done by olpc-specific code, but how the
olpc-specific UI thereunto needs to be managed.

I think you're scaring the pro-package managers away unnecessarily:
your specific objections fall into two categories:

1) ones for which a credible, (olpc) implemented solution exists; and

2) ones lacking that (unrealized or unrealistic - 1 to 3 yrs out -
goals).

For Category 1) objections, existing package managers can be improved,
as they're goals of a large portion of big package managers' users
(yum's, at least :)).

For Category 2) objections, unless you have a credible plan to
implement such features, it seems unusual to justify the time spent
re-implementing package managers' features with the reason they have
some unimplemented features.

To support this classification and its conclusion:

>   - Our users often can't make informed decisions about what software
>     they should be running.

Category 2)

You're saying that your average Windows/OSX/Ubunto/Fedora/Debian user
does?  Most of the time they either don't even recognize a software
updater[1] or never, ever want to change *anything* once it's working
(which of course everything shipped with an XO does/will ;)).  I can
stop right there, I think, to make this point: this is mainly a UI
issue.

>   - Our users probably do not have root on their machines, yet still
>     need to perform package-management-like tasks.

Category 1) (arguably, though how many people that want to do
"package-management-like" tasks have succeeded without root?  You've
seen the "my activities are all gone, what do I do?" questions on IRC,
which means people have gotten past using root :)).  And aren't you
contradicting yourself?  Just previously you said "our users can't
make informed decisions [about package-management-like tasks]" and now
you're saying "[our users] need to perform package-management-like
tasks", IIUC.

>   - In addition to accepting code hierarchically from upstream
>     providers, we want to share code fluidly between XOs.

Category 2), but if it were 1), this seems less a package
formnat/management issue and more a Journal/Shell UI one.

>   - We want the software we provide to support a higher standard of
>     security (defined in Bitfrost) than other systems strive to provide.

Category 1) for "software we provide", even though I don't think
package managers/formats need inherently get in the way of Bitfrost
(their UI or assumptions about where package contest *go* might,
but...that's UI or per-package assumptions, not package formats), no?

Category 2) for "software we have made possible but others will
provide".

>   - We must attempt to minimize bandwidth usage while moving bits
>     around and must tolerate long networking delays.

Category 1).

>   - We cannot rely on any established public key infrastructure to
>     verify the identities of code providers or the authenticity of the
>     code they are providing.

Category 1)

>   - We expect users will be constantly redistributing modified versions
>     of software that they downloaded to their systems.

Category 2).  You say that "our users often can't make informed
decisions about what software [versions] they should be running", and
yet you want them to be constantly redistributing modified versions?
UI issue at worst.

>   - We expect that our user groups will, in general, NOT share common
>     languages with one another (or, necessarily, with us).

Category 1) (and isn't this already the case for other package
managers?)

>   - We expect that many users will be translating their own
>   - software.

Category 1)

>   - We MAY NOT assume that users have global connectivity with which to
>     satisfy dependencies, verify claims about information, distribute
>     their work, etc.

Kind of broad, but either it's a trivial, Category 1) problem
(distribute an xo/rpm), or a hard one - satisfy dependencies of such
an rpm/xo - which is Category 2).

1. Many people *that I observe daily* either a) have had "System
Updater - iTunes updates ready" windows showing on their desktops for
weeks (nice machine uptime, I know), or b) just click "Reboot later"
every time MS Automatic Updates bothers them until they either disable
it or give in and reboot.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080717/2c63da2b/attachment.sig>