[Sugar-devel] [SoaS] Policy for activities for downstream inclusion

Jonas Smedegaard dr at jones.dk
Wed Sep 15 06:39:25 EDT 2010


On Wed, Sep 15, 2010 at 09:25:57AM +0200, Tomeu Vizoso wrote:
>On Wed, Sep 15, 2010 at 00:51, Jonas Smedegaard <dr at jones.dk> wrote:
>> On Tue, Sep 14, 2010 at 09:05:53AM -0500, David Farning wrote:
>>>
>>> On Tue, Sep 14, 2010 at 5:27 AM, Simon Schampijer 
>>> <simon at schampijer.de> wrote:
>>>>
>>>> Hi,
>>>>
>>>> what is the current status for activity releases in order to 
>>>> include them in distributions like Soas*? Do you guys need tarballs 
>>>> or did you switch over to construct the rpms from the .xo? For 
>>>> example the latest Paint rpm uses the .xo AFAIK (build even the 
>>>> binaries from the non-python sources in the bundle).
>>>>
>>>> And is the email from ASLO enough for packagers to know about new 
>>>> releases? Any other notification that packagers need?
>>>
>>> In the .deb side of the universe, we prefer tarballs but we can work 
>>> directly from the git repository.
>>
>> True, the Debian workflow generally is optimized for (gzip or bzip2 
>> compressed) tarballs.  It is possible to step aside from that and 
>> custom generate tarballs based on whatever unusual formats provided 
>> upstream, e.g. pulling it out of Git repositories or extracting from 
>> xo packages.  But then we loose some of the nice infrastructure, like 
>> automatic tracking of new releases across all 30.000 upstreams.
>>
>> I believe Debian is not alone in preferring tarballs from upstream 
>> authors. I believe it is quite general in the FLOSS world.  Feel free 
>> to be weird and unusual also in this area,
>
>This time we weren't trying to outsmart everybody else ;)
>
>We actually do believe in tarballs and tagging, even if we don't get it 
>right always. We have these instructions for modules in glucose and 
>fructose and of course I recommend them as well to other modules:
>
>http://wiki.sugarlabs.org/go/Development_Team/Release#Fructose

Great.


>Note that we have lots of activities unmaintained, people maintaining
>several ex-orphaned activities, activity authors that have no idea how
>distros are made, etc. Ideally we would have some kind of support
>group to help those people out, but obviously we don't have such a
>thing.

I am fully aware of the "bad apples" that can be seen as the Sugar 
development community flourishing.  Those were not my aim in my rant.

It seems I misunderstood this thread, so simply apologize for my noise.


>> just beware that you put a slight higher burden on your downstreams 
>> every time you choose to stand out from the crowd.  So consider the 
>> benefits are worth the risk of loosing consumption from some 
>> downstreams.
>
>Hope that with the above you understand a bit better the situation we 
>are in.

Yes, I do. Thanks.


>Btw, we may want to review our release process in light of:
>
>http://www.metux.de/index.php/de/component/content/article/57.html

Wauw - that is a cool summary!


  - Jonas


P.S.

Please quote only relevant parts of emails.  E.g. my GPG hash is 
completely irrelevant to quote except when preserving my original post 
in its entirety (which is seldom relevant either).


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

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100915/4b1ab6ae/attachment.pgp 


More information about the Sugar-devel mailing list