RPM vs XO FUDConF11 BarCamp session 20090110

Video of the session

http://alt.fedoraproject.org/pub/alt/videos/2009/FUDConF11/XO-vs-RPM.ogg

XO design goals not currently satisfied by RPM

1. Installing by "getting from a friend"
2. Kids can change and redistribute bundles.
   1. Kid bundles are "first class" (distributed versioning implies distributed dependencies)
3. Don't break the world at install time
4. Localizability in the absence of a cantralized repo
5. Novice programmers using [Pippy]

Questions

1. Should activities be noarch?

Wrap-up

• Short-term -- XO format not going away because of requirements not in RPM or any other package format.
• Other problems underneath -- development standards for activity developers. (What is testing, what is release.)
• This is the release, pull it from git, and build an installable package == something that helps XO and RPM potentially.

Short Term outcome

• keep the xo format and push on the activities addons infrastructure
• fructose (a basic set of activities) will keep on being packaged for the distros (debain, fedora, ubuntu...) offers a basic system to start from
• as fructose activities are installed by root every user on a multi-user system (school lab) have a basic system where he can not delete the core activities
• the core system follows a release cycle and quality standard
• show information in the UI when an activity can not be removed

Notes - other, raw

• Giving people freedoms and guidelines are not exclusive goals
• Reference point -- Firefox add-ons. Single platform question, then it installs; highly enables community of add-on (activity) creators.
• XO bundles are more like Java Applets than not -- from security framework, to the idea that you are grabbing and caching a webpage for playing with later.

Transcript

Transcript of Greg DeKoenigsberg's FUDCON11 session on .xo vs .rpm packaging for Sugar Activities, 2009 Jan 10 at 13:30-14:30 in Cambridge, MA, USA. Notes (including all errors) taken by Mel Chua, edits and revisions welcomed.

mchua	(Mel: Everything here is paraphrased.)
mchua	gdk: There's a whole bunch of questions tied up in writing Sugar Activities. Some of the questions pertain to some software development practices, and what practices Activity developers follow, like releases (what are they, should we have them, etc).
mchua	We've done some strange things in this regard. A lot of the open questions are about packaging. * spevack (n=spevack@fedora/mspevack) has joined #fudcon-xorpm
mchua	Question: Are we going to reinvent an already existing package system, does it make sense?
mchua	One of the main things to consider is user-installability.
mchua	mstone: <something about how uruguay uses stuff>
mchua	gdk: an .xo is basically a renamed .zip
mchua	that's it
mchua	We should enable people without XO hardware to be able to use this software.
mchua	This is a common goal, to be able to use things across distros etc.
mchua	(distros and other platforms)
mchua	one of the open questions is that we have this list of Activities of varying maturity
mchua	The .rpm way is to make them into .rpms
mchua	so we could make them all .rpms
mchua	Or we could just leave them as .xo files
mchua	What are the strengths and weaknesses of this?
mchua	cscott: could have them be installed via firefox extensions too.
mchua	<discussion on firefox as an exception re: installing package-like things>
mchua	jkatz: <discussion on firefox's versioning practices>
mchua	gdk: the reason this works is that they can treat firefox as a complete platform, and don't need to know about dependencies outside it. * cjl (i=chatzill@ool-45735eb0.dyn.optonline.net) has joined #fudcon-xorpm
mchua	jkatz: When you make stuff for a project, you need to package according to that project's conventions.
mchua	gdk: yes, but what do you package? You could imagine one .rpm with all of Sugar and another with all of the Activities. (Instead of individual ones for each Activity.)
mchua	bschwartz: Activities are independent of one another. One way of thinking about it is Activities are things you run through Sugar, like running scripts in a scripting environment. (Mel: This may be misphrased.)
spevack	much like you have a gnome-games packages that represents a bunch of the best/most stable games available for gnome in a given release (i'm sure someone will make this point)
spevack	you could a single rpm that provides a whole bunch of activities. * spevack doesn't know what he's talking about :)
mchua	cscott: As an example, think of Java games, you can download games and run them in Java, but you don't re-download Java for each game. Unless you need 2 different versions of Java.
mchua	spevack, is that something you want relayed to the room? (haven't looked around enough to see if you're here)
mchua	bschwartz and cscott: <discussing the lack or presence of Activities as dependencies of each other> * tomeu1 (n=tomeu@r9ci216.net.upc.cz) has joined #fudcon-xorpm
mchua	bernie: We can get new volunteers started dong simpler packaging work.
mchua	cscott: why can't we package them both as an rpm and have a native package format?
mchua	bschwartz: we are doing that.
mchua	jkatz: <talking with bernie, I can't catch it>
mchua	gdk: Let's talk about the design.
spevack	mchua: nah, don't interrupt greg's flow * mchua nods to spevack * spevack is not there, unfortunately -- just following along remotely via your transcription
mchua	gdk: one of the principles of sugar is collaboration - they can share easily with each other, they don't have to set up complicated things on their computer to do it.
mchua	bschwartz: this is a design goal, regardless of implementation.
mchua	bernie and jkatz: <questions about implementation>
mchua	cscott: no no, it's a design goal.
mchua	The second design goal is that the Activities would be user modifiable using tools that are on the laptop.
mchua	gdk writes on board: 1. Installable by "getting from a friend."
mchua	(Mel: This means not just collaboration, but if a friend has an Activity you don't, you can install it by just getting it from him or her, just as if you were collaborating on an Activity you already had.)
mchua	gdk writes on board: Kids can change and redistribute bundles. Kid bundles are "first class."
mchua	bschwartz: what this means is that if a kid has an Activity and they edit it and redistribute it, their new Activity isn't any "less a real Activity" than one that say the people in this room work.
mchua	This also means that version numbers get a little weird when software is forking so often.
mchua	In ways that are not necessarily centralized.
mchua	gdk on board: Don't break the world at install time.
mchua	gdk: some of these features are Sugar differentiators. A lot of the points we are making (Mel: and that I missed typing - details not as important) boil down to "collaboration."
mchua	Collaboration, to me, is the whole thing that makes Sugar interesting. peer to peer collaboration. * |tanya| (n=tanya@dhcp-18-190-60-36.dyn.mit.edu) has joined #fudcon-xorpm
mchua	mstone: Don't forget about localization.
mchua	gdk on board: Localizability
mchua	jkatz: There are a couple of things to look at - is Sugar intended to go beyond kids? This has a lot of implications. * mchua is happy to relay questions from the channel, for the record - |tanya|, spevack, tomeu1, cjl.
spevack	thanks
mchua	jkatz: The second thing is... well, we saw this problem, we didn't like how it was done, so we made our own system instead of trying to work with the systems that exist.
mchua	Maybe it's the right answer, but there is a larger context of software that this fits into.
mchua	gdk: That begs the question - is there enough of a commitment here to solve the problems that you're talking about? Maybe one of the problems, for example, is user infallibility.
cjl	Thank m_stonefor raising localization, to many Activitiesdon't have POT in Honey.
mchua	marcopg: <complaints about .rpm shortcomings>
mchua	gdk to marcopg: Are those really?
mchua	(Mel: Overall notes - jkatz is providing a lot of excellent constructive skeptical criticism - cscott and bmschwartz are teamed up countering them, and gdk is summarizing and refocusing every so often.)
mchua	gdk: Giving people guidelines != not giving them freedom. If we want to make an ecosystem, there are some assumptions we are going to have to tell people they might want to opt-in on. * |tanya| has quit ()
mchua	mstone: <discusses shortcomings of the .xo system in reaching the goals gdk wrote on the board>
mchua	bmschwartz: Yes, we're far from them, I'd like to talk about how we can get there.
mchua	cscott: We're not that far in some respects.
mchua	<discussion on how far or near we are from some of these goals>
mchua	gdk: Let me ask this: is dependencies something .xos should care about?
mchua	If so, we're going into the packaging world, because that's the problem packages were supposed to solve.
mchua	jkatz: At the very least, you need to have the "you need this version of Sugar to run this."
mchua	bmschwartz: We have that. * |tanya| (n=tanya@dhcp-18-190-60-36.dyn.mit.edu) has joined #fudcon-xorpm
mchua	gdk: having a piece of software be a platform != having a piece of software worry about dependencies - look at firefox!
mchua	It's cross-platform and essentially a platform of its own.
mchua	There are things it doesn't do that people in the "enterprise system" care about, like the ability to see what software is on the system at any given time.
mchua	The question is what the tradeoff is.
mchua	bmschwartz: maybe we need a way for these things to be created by novices.
mchua	gdk writes on board: novice programmers using pippy.
mchua	(Mel: for context, see http://wiki.laptop.org/go/Pippy)
mchua	cscott: All linux distros I know of have a canonical source of packages - centralized. If we really believe kids are modifying packages, that centralization goes *poof*
mchua	You get all sorts of microversions.
mchua	gdk: Distributed versioning with dependencies? *screams*
mchua	bmschwartz: Is one design assumption we are making that these kids might not have internet connectivity - only mesh networking with other local kids?
mchua	cscott: A lot new version control systems were made because of this need to be distributed.
mchua	bmschwartz: and maybe one of the things .rpms *can't* be made into is a distributed versioning system.
mchua	cscott: maybe version numbers fundamentally don't work in this case.
mchua	jkatz: Is this something the Sugar community feels strongly enough is vital to Sugar's success that you're willing to make those tradeoffs?
mchua	cscott: I don't see these options as an either/or.
mchua	You can package things whatever way you want.
mchua	gdk: Right now, we have a handful of .rpms, and all the Activities are .xos. You install them as .xos.
mchua	when I have to figure out whether I should go to the work of bundling up XOirc, or if I should just get the .xos, there's no incentive for me to do the former.
mchua	It's just so easy to do the former - trivially easy to download it from the website and it Just Works.
mchua	jkatz: But if I have a lab of many machines, does that "trivially easy" change?
mchua	gdk: This is the enterprise systems question.
mchua	cscott: It used to be you packaged because you had multiuser systems and you wanted everyone to have it.
mchua	jkatz: this design makes life hard for sysadmins.
mchua	bmschwartz: another design assumption is "we don't have sysadmins."
mchua	gdk: From my practical experience, the reason I want to see packages for other kids of software is that other software is complicated in a way Activities are not.
mchua	<protest from room>
mchua	gdk: so hear me out! Having to do things with complex makefiles, etc- ok, yes, you need rpms!
mchua	but the problem of installing a bunch of python files is totally not the same.
mchua	if I'm doing something like "install paste," then zomg, I want an .rpm and if need be I'll be the one that does it.
mchua	but for installing an Activity, then...
mchua	bmschwartz: extension of this thinking - we don't need a package manager to install html webpages. we just http get them and view them.
mchua	Activities are on that end of the spectrum.
mchua	bernie: <story about his friend porting Mono activities to the XO - summary was "It took him a few days.">
mchua	bmschwartz: I wrote an Activity, most of my work was writing shell scripts that unbundled .rpms.
mchua	(Mel: referring to an Activity he ported over from rpms, I believe.)
mchua	mstone: Fedora has, understandably, very strict guidelines about where things should go.
mchua	jkatz: Getting people to follow those standards is hard - if you write a standard nobody follows, that's no good.
mchua	jkatz: there are ruby gems, etc.
mchua	.jars, etc.
mchua	jkatz: <description of how one such standard within fedora became adopted>
mchua	Maybe we're all sitting here worrying about this for naught, when the point is really what the community will end up using anyway.
mchua	bernie: how much would it take to switch to packages?
mchua	marco, michael: <side conversation about this that I can't quite catch>
mchua	(the summary of what marco and michael are saying is mostly "not very hard")
mchua	bmschwartz: the .xo isn't the only thing that has been recently designed to solve the problem of installing arbitrary apps with no root access.
mchua	cscott: This is like a pendulum - when we had big multiuser systems and nobody had root, everything was local install. Then we had people with root on their own systems, and installing stuff as root became ok.
mchua	then now we have this new idea of a multiuser system where the users aren't necessarily different people, but different aspects of you - and each program then has different permissions for things that you're giving it access to see.
mchua	(Mel: see bitfrost and rainbow stuff on the OLPC wiki.)
mchua	(for context.)
mchua	jkatz: It's like xguest (Mel: did I get that right?) on the latest Fedora.
mchua	bmschwartz: we need to generate a system that automatically applies security to .xos that get installed. Sugar hasn't been able to find an existing system that they can borrow for this yet, hence "make your own."
mchua	The only thing we need different from .rpms is this non-root installation. all the other problems are same for .xos and .rpms.
mchua	My question is "do you want rpm to become the new usermode packaging installation system?"
mchua	jkatz: since new people have taken over rpm - we need to fix the problems that exist now before we build more things on top of it.
mchua	user installation is a goal, but a long-term one not on an immediate time horizon.
mchua	(user-level installation, in the sense of security - nonroot.)
mchua	bmschwartz: what using .rpms would gain Sugar devs is that it would save us the trouble of maintaining .xo management tools - not so that we can install through yum or anything.
mchua	gdk: nearly out of time. time to wrap up.
mchua	short version is that .xo isn't going to go away because other solutions like .rpms aren't there yet.
mchua	in the meantime, it seems that there are other problems underneath this level to be considered
mchua	like development standards with Activities.
mchua	for instance, there's no way of tagging a particular release as being released vs unstable, etc.
mchua	jkatz: that's one thing that distributed version control makes harder - centralized vcs has releases as "release == this snapshot in time."
mchua	gdk: we need the ability to tag something in git as "a release."
mchua	bmschwartz: my hope is that there will be lots of awful software written for Sugar.
mchua	that a lot of stuff for Sugar will be written by people that barely know how to program. That would be wonderful.
mchua	gdk: the key is making that stuff nondestructive.
mchua	<session wraps up>
mchua	*applause*

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!