[Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar

[Peter Robinson]

>>> 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.

> 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.

Peter