[Sugar-devel] Official homepages for activities are at laptop.org?

David Farning dfarning at sugarlabs.org
Sat May 30 14:37:55 EDT 2009


On Sat, May 30, 2009 at 1:05 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
> On Sat, May 30, 2009 at 05:03:34PM +0100, Gary C Martin wrote:
>>Hi Jonas,
>>
>>On 30 May 2009, at 09:44, Jonas Smedegaard wrote:
>>> While updating packages for Debian, I failed to find proper homepages
>>> for activities at wiki.sugarlabs.org - and core introduction at
>>> http://wiki.sugarlabs.org/go/Sugar_Application_Stack points to some
>>> of the Sucrose activities at wiki.laptop.org.
>>>
>>> Is that correct?  Are official activity homepages at wiki.laptop.org?
>>
>>Are you looking for user oriented pages, or developer pages?
>
>
> This is what I am looking for (taken from Debian Policy §5.6.23 about
> the "Homepage" stanza):
>
>>The URL of the web site for this package, preferably (when applicable)
>>the site from which the original source can be obtained and any
>>additional upstream documentation or information may be found.
>
>
> I am packaging software that was published by Sugarlabs.  So for the
> context of the package that I build for Debian, Sugarlabs is "upstream".
>
> I am looking for a single URL being the "home" (i.e. starting point for
> web browsing) of what Sugarlabs is providing, for each activity or
> Glucose part.

Activities.sl.o is intentionally designed to decentralize the control
of activity development anyone can upload their work to aslo to be
distributed.  Before becoming 'public' new activities and versions of
activities are given a review by the aslo editors.

aslo is a distribution tool rather than a developer tool.

How is the issue handled when packaging mozilla addons?

david

>
>
>>The activities.sugarlabs.org Mozilla addons based site is intended to
>>be the user facing site, with wiki.sugarlabs.org/go/Activities/
>><activity_name> being used for more technical notes activity if needed.
>
> Well, I guess I mean eveloper pages, then.
>
> activities.s.o seems a dead end for anyone but _your_ users, as those
> pages seemingly link only to .xo files and homepages of _your_ upstreams
> (Chat homepage is at OLPC, EToys homepage is at squeakland).
>
> Some Debian users arguably are your users too, but administrators of
> Debian systems are also Debian "users" and they want everything packaged
> and officially endorsed (a.k.a. "aged for some years" ;-) ) by Debian.
>
>
>>Activities that were OLPC deployed, generally have their pages still
>>on wiki.laptop.org, though as new (perhaps incompatible with 0.82)
>>releases are made this is slowly migrating over to SO.
>
> Ok.
>
> So links from http://wiki.sugarlabs.org/go/Sugar_Application_Stack
> should be updated?
>
> Are links from http://wiki.sugarlabs.org/go/Activities then the right
> ones?
>
> Or are there no "right", but only "luck"?
>
>
>
>>FWIW: Here are some other structures/locations that Activity
>>developers are asked to update if they want to help try and make
>>packagers lives easier:
>>
>>       http://download.sugarlabs.org/sources/honey/
>
> That's pages for download origin.  Makes sense to include too (in Debian
> packages such URLs are included in the file "copyright" and inside
> scripts for automated download and/or tracking newer upstream releases).
>
> I wouldn't use such pages as Homepages, however, as they do not contain
> any introduction, and barely link to anywhere: It's a dead end for
> anythong but downloading tarballs.
>
>
>>       http://wiki.sugarlabs.org/go/Development_Team/Source_Code
>
> Hmm.  According to that page, 0.82 is latest stable Sucrose, and most
> "Latest release" entries are too old as well.  I suggest dropping that
> column and instead in first column link to the directory containing
> source tarballs.  Perhaps also rename column titles to this:
>
>   Source | Description | Development repository
>
>
>
>>       http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap
>
> I suspect this is only relevant as inspiration for alternative
> distributions.
>
> Or is SoaS the recommended upstream source for other distributions?!?
>
>
>>Would be great if this (at some point) could be simplified to the
>>point where having a git repository at git.sugarlabs.org was enough
>>for all to work from. I think I've heard vague whispers that there
>>might be some process used (or being worked on) by the Soas distro for
>>pulling/building bundles from git**?
>
> Cool for SoaS, but again, how is this relevant for other distros?
>
> It might make sense for Sugarlabs to generate .tar.bz2, .deb, .rpm, .xo
> and various other format files automatically from git, but that will be
> in _addition_ to the packages maintained by each (larger) distribution,
> not replacing it.
>
>
>>** I guess we would need some clear git guidelines for Activity
>>authors to make sure their Activity mainline branch was always at the
>>latest stable release (with new version work happening in branch/s).
>
> Would be great, but does not in itself solve the problem of information
> scattered all over, and - back to my main point - the lack of a
> "homepage" to refer to from distributions.
>
> Suggestion: Setup an automated script that trawls
> http://download.sugarlabs.org/sources/**/${pkg}/*.tar.bz2 and generates
> http://packages.sugarlabs.org/${pkg} for each package, and either an
> index or a search page on the front page.
>
> Each page would contain link to newest tarball, directory with all
> tarballs, homepage at activities.sugarlabs.org, bugtracker page, git
> browser etc.
>
> In case of name clash between Glucose module and activity, show infor
> for them both, emphasizing the activity part.  In case of Fructose and
> Hony name clash, include both, emphasizing Fructose.
>
> The key point is that the information is automated, and only present
> references that match Sugarlabs standards.  If
> http://wiki.sugarlabs.org/go/Activities/Chat is missing then tough luck:
> then Chat won't have a wiki page promoted.  It might still have a
> "Legacy wiki" page or "OLPC downstream wiki" page if such are generally
> handled by the script, but noone gets to squeeze in temporary stuff that
> then goes stale.
>
>
> This proposal does not replace your dream about a super polished git
> taking care of everything - they go hand in hand: When that Git
> structure works, it simply means that the little boring script just
> fully presents everything properly :-)
>
>
>
> Kind regards,
>
>  - 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)
>
> iEYEAREDAAYFAkohdVoACgkQn7DbMsAkQLgCiwCfVMqnQ9iz/8Knkv8yAn3SZNKP
> xVoAn2F5XncvhDKIEEXwaR2x9ZAhvT41
> =RtLp
> -----END PGP SIGNATURE-----
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>


More information about the Sugar-devel mailing list