[Sugar-devel] Distributors mixing across Sugar branches (Was: Terminal v25 (attention distro managers!!))

[Gary C Martin]

On 1 Apr 2009, at 15:09, David Farning wrote:

> On Wed, Apr 1, 2009 at 6:29 AM, Jonas Smedegaard <dr at jones.dk> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Wed, Apr 01, 2009 at 12:43:04PM +0200, Morgan Collett wrote:
>>> On Wed, Apr 1, 2009 at 11:12, Jonas Smedegaard <dr at jones.dk> wrote:
>>>> - From a distributor point of view, it would be nice to be able to
>>>> look at the Homepage of each part of Sugar (sugar-toolkit,
>>>> sugar-base, sugar, hulahop, Browse, etc) and see not only a  
>>>> download
>>>> link for the latest and greatest release of that piece, but a
>>>> download link for the latest and greatest release for *each* of  
>>>> your
>>>> development tracks (i.e. currently 0.82, 0.84 and "bleeding edge")
>>>> and also a brief note on which changes are not backwards- 
>>>> compatible.
>>>
>>> +1
>>>
>>> Also publishing the changelogs for each release would be good -
>>> currently they seem to be only sent in the release announcement  
>>> mail.
>>
>>
>> With the risk of writing stuff that you all know better than me
>> already, let me elaborate a bit on that:
>>
>> There is several levels of "changes".  In Debian we may have the
>> following, for each single software package:
>>
>>  * VCS commit notes, describing each atomic edit
>>  * Changelog entries, grouped per release
>>  * NEWS items about eventual major changes, grouped by release
>>  * Status pages, tracking newest events for each branch
>>  * Long description, describing the product in few sentences
>>  * Short description, describing the product in one line
>
> As our activity ecosystem matures, I think that we will want to focus
> on setting a method for activity developers to _opt in_ to joining the
> Sugar Labs release cycle.

Hmmm unless I've misunderstood, I actually think exactly the  
opposite :-)

As our activity ecosystem matures, Sugar Labs should be arriving at a  
more and more solid and stable Sugar platform, one that Activity  
developers can build for with less and less worry about burning their  
life away trying to work in, and develop for, an unstable Sugar  
release, just because "it's the next one where we break your work  
again."

If you're developing an Activity that relies on a bleeding edge new  
feature, then expect to get broken and need to work right up to the  
release wire. That's a very good reason for a core set of fructose  
activities tied to the release cycle. They are the ones that have to  
work well for a new release as they provide the agreed base line  
utility, they can also lead the way on supporting new core features  
that are getting rolled out (act as proof of concept for other's to  
pick up on).

For mid to long term Activity development to be successful, we need to  
free activity developers to be as far as they like from the core Sugar  
Labs release cycle (by providing a stable activity platform). Activity  
developers need to work to their own release time cycles. Without  
this, very few activities will get to maturity.

Regards,
--Gary

P.S. All the above is with the understanding that Sugar has not  
reached version 1.0 yet (and I doubt it'll be there for another year),  
so it's understandable that Activities will get broken from time to  
time – but I like to think that is a short to mid term issue, and not  
the Sugar Labs long term goal ;-)

> It could start something simple like just a check list of items listed
> you and Morgan listed above.
>
> david
>
>> I probably forgot some.
>>
>> Above list is ordered in after how often it typically needs updating.
>> (yes, short and long descriptions are also a form of status info:  
>> Debian
>> Sugar packages currently mention that Sugar is mostly for XOs ;-) ).
>>
>> An important issue (that I thankfully haven't noticed abused at
>> Sugarlabs but frequently in Debian) is that each and every item in  
>> above
>> channels should be somewhat self-contained.  It is ok to reference
>> external resources (like bug-number being closed) but it is wrong to
>> write "Fixed earlier problem properly now" without mentioning *what*
>> problem it is, in the entry itself.
>>
>>
>>  - 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)
>>
>> iEYEARECAAYFAknTUBkACgkQn7DbMsAkQLjvHwCeJpui2oc8eYzIeLGzJVLY2ZxI
>> 69UAoJX+VBL7FI689W5sUtWiBKjdLF11
>> =xHeu
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel