Re: [Sugar-devel] Distributors mixing across Sugar branches (Was: Terminal v25 (attention distro managers!!))
On Wed, Apr 1, 2009 at 11:12, Jonas Smedegaard d...@jones.dk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 01, 2009 at 10:12:07AM +0200, Tomeu Vizoso wrote: On Tue, Mar 31, 2009 at 22:55, Simon Schampijer si...@schampijer.de wrote: Wade Brainerd wrote: Yeah, v24 introduced tabs. v25 is a bugfix of v24. Hmmm, it has been packaged for Fedora 11 already. And F11 should only contain Sucrose 0.84. Please make clear what Sucrose version it is for when you announce new releases - since otherwise packagers pick it up and put it in 0.84? Wonder if that's a problem for SugarLabs? If a packager wants to include an activity that is not part of the stable release of Sugar that they are shipping, isn't that their choice? I'd say so too. What I see that Sugarlabs can do to help encourage distributors to not fuck up is to more clearly document what breaks by mixing. I have been guilty of mixing: Debian 0.82-based packages contain a too new Browse. That activity will not run on an XO, but Debian contains a newer underlying library so it works proberly anyway (I believe). But I couldn't find anywhere a list of what I would break by mixing - I learned about this particular shortcoming by following this upstream development list closely, until someone mentioned it. (I think I even posted an explicit question about it at somepoint, which I think was ignored). I am not complining here, not at all: If we distributors mess your carefully composed dependencies, then we are to blame for breaking anything. But your carefull composition is based on some assumptions of the underlying OS which are not universally true, and so does not apply to all versions of all distributions. - 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. Regards Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Distributors mixing across Sugar branches (Was: Terminal v25 (attention distro managers!!))
-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 d...@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 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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Distributors mixing across Sugar branches (Was: Terminal v25 (attention distro managers!!))
On 1 Apr 2009, at 15:09, David Farning wrote: On Wed, Apr 1, 2009 at 6:29 AM, Jonas Smedegaard d...@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 d...@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@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
