[IAEP] [Sugar-devel] activites known not to either work at all or not on certin platforms

[Jonas Smedegaard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Feb 13, 2009 at 12:06:44PM -0800, Edward Cherlin wrote:
>On Tue, Feb 10, 2009 at 6:14 PM, David Van Assche <dvanassche at gmail.com> wrote:
>> ok? I guess this will be contreversial but it must be said and acted 
>> upon (much more importantly)
>>
>> Im gonna try and make this easy:
>>
>> SoaS - the latest fedora core based
>> I tried to impress my 9 year old gescwister... (related one)
>> Speak - it will not even launch.... why is it then on a disitributed 
>> stick?
>
>I have similar problems, and I don't even know where to submit bugs.

If you are an end user, then file a bugreport against the buggy software 
package to the bug tracking system of your distribution.

If you use a mixture from multiple sources, then you really are using 
your own unique distribution, and cannot expext any of your sources to 
want to deal with your problem: Your best bet is then to test yourself 
if same bug occur in a clean install from a single of your sources.

If you use SoaS, then your "distribution" is whoever put together that 
SoaS. It is *not* the distribution that was used as basis for the SoaS.


You might have luck anyway, filing bugreports against e.g. Debian if 
using an SoaS based on Ubuntu which is based on Debian. But be careful 
to mention clearly that you are using a "messy" setup, and don't be 
surprised if your bugreport is not taken seriously.


>We need some kind of organization now that we are in a matrix 
>situation. We have a multitude of .xo packages, and at least the 
>following platforms:
>
>o XO
>o Fedora
>o Debian
>o Ubuntu
>o Caixa Magica Linux (Venezuela)
>o Mobilis with Linux on XSCALE processor (Brazil)
>
>In addition to regular packages for installation, we want a LiveCD and
>SOAS for each one. That means that we need an automated build and QA
>infrastructure for all of these cases, and a reporting database. We
>are past the point where all-manual testing makes any sense.

I recommend Sugarlabs to *not* try to act as sub-distributor for 
anything containing Sugar.

1) You are _upstream_ of Sugar.

2) You might(!) want to be distributor too, for a _specific_ SoaS.

But really, I recommend to separate SoaS distribution and keep Sugarlabs 
aas only an upstream for Sugar.

What I mean is, play with SoaS, Ubuntu, Fedora, whatever, but make it 
very clear to non-Sugar-developers that you cannot support the crap 
you've thrown together - that it should not be considered a 
"distribution" but is solely meant as an internal testing mechanisms, 
and if it happens to work ok for others then that is pure luck.


...if anyone then wants to stand up and maintain support for a 
distribution, then great. Just don't mix upstream and distribution - 
they are very different tasks.


  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmV4rIACgkQn7DbMsAkQLgumgCeIZCZpnx8mR9+xMhhmX+Y+OCs
haEAoKYOXV0JwCLBg+wvOtIY3b5uMS+1
=a1Zw
-----END PGP SIGNATURE-----