[Sugar-devel] [SoaS] Policy for activities for downstream inclusion
dfarning at gmail.com
Wed Sep 15 04:41:20 EDT 2010
On Wed, Sep 15, 2010 at 2:25 AM, Tomeu Vizoso <tomeu at sugarlabs.org> 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>
>>>> 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:
I took Simon's comment earlier in the the thread that we shouldn't use
git repos and instead us XO bundles as the weird part:( To help
understand the .deb work flow:
1. Select activities to include -- Use the Soas activities ( no need
to reinvent that wheel) + a few requested activities.
2. Research activity -- Look up activity on ASLO to find latest
release and 'Homepage.'
3. Find Tarball -- Poke around on
http://download.sugarlabs.org/sources/ for a recent tarball -- The
external, honey, sucrose, fructose, glucose categorizes inapproachably
named. _Every_one_ wastes time trying to figure out what they mean
and what goes where:(
4. Find git repo. -- This is usually pretty straight forward based on
information found on the 'Homepage'.
5. Determine if the get repo is properly tagged.
6. Contact upstream author and encourage them to tag their repo.
7 Skip package.
If a we find what we need at any any step 3-6 we can package the
activity. If not, we continue down the check list. Having work on
both sides( upstream and downstream) of the problem, I think this is a
reasonable work flow, it is not optimal for either party but it is
sane for both.
My single biggest complaint -- clever names. The clever Sugar
'variations' for naming things is hard to learn and hard to
remember.... especially for non-native English speakers.
> 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
>> 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.
> Btw, we may want to review our release process in light of:
>>> I have cced jonas for an official position.
>> Thanks for notifying me, David.
>> - Jonas
>> * Jonas Smedegaard - idealist & 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.10 (GNU/Linux)
>> -----END PGP SIGNATURE-----
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel