From Fedora Project Wiki

(add video)
(→‎Transcript: run irclog2html on transcript)
Line 38: Line 38:
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.
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.


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


Generated by irclog2html.py 2.7 by [mailto:marius@pov.lt Marius Gedminas] - find it at [http://mg.pov.lt/irclog2html mg.pov.lt]!


[[Category:FUDConF11 BarCamp sessions]]
[[Category:FUDConF11 BarCamp sessions]]
[[Category:Sugar]]
[[Category:Sugar]]

Revision as of 22:43, 16 January 2009

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!