On Thu, Sep 24, 2009 at 12:44, Peter Robinson <[email protected]> wrote: >>>> 6. Ease of creation of activity packages >>>> Moving to distro-based packaging will not effect the difficulty of >>>> developing activities, since packaging is something you do after >>>> development, not before. >>>> It will affect packaging and distribution. My suggested model (as >>>> employed all over the open source world) is that the developers would >>>> release source distributions and let distributions do the packaging >>>> and distribution. >>>> Even though a Sugar system with distro-installed packages is crippled >>>> (activities cannot be erased or updated through any realistic means), >>>> we've *already* found some great packagers from Ubuntu, Debian, Fedora >>>> and SUSE who have been distributing activity packages. >>>> In many cases it will be enough just to point out to distros that >>>> you've developed an awesome new activity, but maybe in some cases we >>>> will have to lend a hand to those distributions in order to get things >>>> packaged up. However, there are also a huge amount of people with >>>> packaging expertise who are keen to help. Over the last few years I >>>> have personally dabbled in packaging for Gentoo, Fedora and Ubuntu. >>>> I'm far from an expert in any and have had to ask various questions >>>> every single time, but all of my problems have been quickly solved by >>>> other people more experienced than myself. There is also a huge amount >>>> of documentation available. This is the distributions core business - >>>> they like to package good things, and they are good at doing so. >>>> It is indeed an increase in difficulty of packaging (for the >>>> situations where developers will have a role in packaging, which will >>>> hopefully be less and less), but it also allows us to hand this off to >>>> other people (or at least access a huge amount of expertise), and it >>>> does represent an increase in the quality of our processes and a >>>> solution to some problems. >>> >>> I have a possible solution to this which would allow automatic >>> creation of rpms. I need to get time to sit down and see if this is >>> going to work which I don't think I'll get until late Oct at the >>> earliest but it should get us to a point where a Activity is tagged in >>> git and a while later a rpm in available in a repository. I'll post >>> more once I get the time to test my theory. If its proven it will >>> basically remove the arguement of "rpms are too hard for the >>> developers to make and they don't have the time to do so". >> >> But we also have activity authors that don't want to go through the >> hassle of learning git :/ > > This is getting completely ridiculous. So how do they manage the > versions and releases of their packages? Do these get put on a.sl.o? > If so how do we verify the source code and whether it can be > distributed? How do we verify any binary content they might include? > What they do privately is their own business but if it appears on > a.sl.o it needs to be verify able and trackable. There needs to be a > minimum set of requirements.
In these cases, I don't expect those activities to contain binary code. Also, I don't think ASLO is intended to be the only way to distribute activities. I'm personally ok with ASLO containing only activities with code in public repositories, etc. >> And even worse, we want people who are not yet able to create >> activities from scratch to do simple modifications to existing >> activities and redistribute them. > > That's fine. Its open source and it then becomes their problem but it > shouldn't be a central issue what they want to do with modified > activities. The activities hosted on a.sl.o should meet a minimum > requirement. Otherwise we get into a situation where there's no > guarantee of the Activity whether that been the source or the > stability of it. Agreed. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
