From Fedora Project Wiki

Revision as of 22:46, 16 January 2009 by Ianweller (talk | contribs) (→‎Transcript: hmm my regexps did not work as well as they should have.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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!