Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 09/20/2010 11:10 PM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Mon Sep 20 12:45:28 +0200 2010: Do you expect only developers of activities in Fructose to follow that process (documented on the Development Team/Release [1] page on the wiki) or others as well? Ideally all of them, as (a) there are not many activities in Fructose and (b) concluding from this thread that the packagers would be happy about it. Then we need to extend a.sl.o to host source tarballs as well. Right now activity developers need to either have a sunjammer account or abuse the wiki if they want to publish tarballs. Yes, I think that the tarballs would fit there perfectly well. I think we can live with the increased load of the storage demand for each activity (please correct me if that is wrong). If I remember Aleksey correctly, from a technical point of view this would not be a hard thing to do. If the latter, we should start by documenting this requirement. I couldn't find any place in the wiki (that could do with some spring cleaning, BTW) explaining how to get your activity published at all, let alone how to please packagers. Absolutely, that should be documented. I leave this to the activity maintainers and packagers to define that policy and adding a wiki page for it - as those are the ones that need to follow it and request it. Let's hope the subject drew enough attention to make someone actually adjust the wiki. Yes, and thanks for helping discussing this. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 09/21/2010 03:49 AM, Gary Martin wrote: On 20 Sep 2010, at 22:10, Sascha Silbesascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Simon Schampijer's message of Mon Sep 20 12:45:28 +0200 2010: Do you expect only developers of activities in Fructose to follow that process (documented on the Development Team/Release [1] page on the wiki) or others as well? Ideally all of them, as (a) there are not many activities in Fructose and (b) concluding from this thread that the packagers would be happy about it. Then we need to extend a.sl.o to host source tarballs as well. Right now activity developers need to either have a sunjammer account or abuse the wiki if they want to publish +1 though FWIW the timeline for this is likely to wait until a python port/upgrade of ASLO has happened, perhaps well into next year. Oh? Isn't it just another upload option as we have already for the .xo? If the latter, we should start by documenting this requirement. I couldn't find any place in the wiki (that could do with some spring cleaning, BTW) explaining how to get your activity published at all, let alone how to please packagers. Absolutely, that should be documented. I leave this to the activity maintainers and packagers to define that policy and adding a wiki page for it - as those are the ones that need to follow it and request it. Let's hope the subject drew enough attention to make someone actually adjust the wiki. A major point for activity separation from core in my view (and the reason I try to avoid contributing code to Sugar core) is to keep out of, and as far away as possible, from the release cycles. I have no idea what I'll get the chance to work on tomorrow, or next week, even though I keep a detailed todo list. The best I can do is try to shuffle relevant tasks about to try and fit in, but that leaves me working on things inefficiently, and often that I'm least motivated by at the time. But uploading a tarball or not has nothing to do with the release cycle, right? If the packagers know that activities are announced a certain way (ASLO email) they can package the new activities as they see fit. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 09/15/2010 04:27 PM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Wed Sep 15 12:33:30 +0200 2010: Personally I'm moving to the point where if there's not a tarball I won't spend my time packaging it. Yes, I think the effort for uploading a bundle that can be easily generated with the tools in sugar is not asked to much to have the activity then packaged in a distribution. Do you expect only developers of activities in Fructose to follow that process (documented on the Development Team/Release [1] page on the wiki) or others as well? Ideally all of them, as (a) there are not many activities in Fructose and (b) concluding from this thread that the packagers would be happy about it. If the latter, we should start by documenting this requirement. I couldn't find any place in the wiki (that could do with some spring cleaning, BTW) explaining how to get your activity published at all, let alone how to please packagers. Absolutely, that should be documented. I leave this to the activity maintainers and packagers to define that policy and adding a wiki page for it - as those are the ones that need to follow it and request it. If those people agree that this is what should be done they should make this happen as an outcome of this thread. Personally I think it is worth it. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
Excerpts from Simon Schampijer's message of Mon Sep 20 12:45:28 +0200 2010: Do you expect only developers of activities in Fructose to follow that process (documented on the Development Team/Release [1] page on the wiki) or others as well? Ideally all of them, as (a) there are not many activities in Fructose and (b) concluding from this thread that the packagers would be happy about it. Then we need to extend a.sl.o to host source tarballs as well. Right now activity developers need to either have a sunjammer account or abuse the wiki if they want to publish tarballs. If the latter, we should start by documenting this requirement. I couldn't find any place in the wiki (that could do with some spring cleaning, BTW) explaining how to get your activity published at all, let alone how to please packagers. Absolutely, that should be documented. I leave this to the activity maintainers and packagers to define that policy and adding a wiki page for it - as those are the ones that need to follow it and request it. Let's hope the subject drew enough attention to make someone actually adjust the wiki. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 20 Sep 2010, at 22:10, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Simon Schampijer's message of Mon Sep 20 12:45:28 +0200 2010: Do you expect only developers of activities in Fructose to follow that process (documented on the Development Team/Release [1] page on the wiki) or others as well? Ideally all of them, as (a) there are not many activities in Fructose and (b) concluding from this thread that the packagers would be happy about it. Then we need to extend a.sl.o to host source tarballs as well. Right now activity developers need to either have a sunjammer account or abuse the wiki if they want to publish +1 though FWIW the timeline for this is likely to wait until a python port/upgrade of ASLO has happened, perhaps well into next year. If the latter, we should start by documenting this requirement. I couldn't find any place in the wiki (that could do with some spring cleaning, BTW) explaining how to get your activity published at all, let alone how to please packagers. Absolutely, that should be documented. I leave this to the activity maintainers and packagers to define that policy and adding a wiki page for it - as those are the ones that need to follow it and request it. Let's hope the subject drew enough attention to make someone actually adjust the wiki. A major point for activity separation from core in my view (and the reason I try to avoid contributing code to Sugar core) is to keep out of, and as far away as possible, from the release cycles. I have no idea what I'll get the chance to work on tomorrow, or next week, even though I keep a detailed todo list. The best I can do is try to shuffle relevant tasks about to try and fit in, but that leaves me working on things inefficiently, and often that I'm least motivated by at the time. --Gary Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ 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
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Wed, Sep 15, 2010 at 00:51, Jonas Smedegaard d...@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 si...@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 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. 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: http://www.metux.de/index.php/de/component/content/article/57.html Regards, Tomeu 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) iQIcBAEBCgAGBQJMj/x5AAoJECx8MUbBoAEhW8cQAIYyYCa90vhzC5cXmkq+HZIk 74HZZ7qUeb8rXTRedHf/GM3Pd5TaE36xQ/9JSvjkGilZd6zBEh+9OmgQLcOa9i86 en5aKiuPhXXccRqXMFP6CZRCC/g3avwgidgDjbMoWTvigQ35KRuYQEKQx4HxQ6Uw hYuxfh8YizlLw5Cw9nuhJsBinJkZDSFk8LThZlsD8s6yirGOhK2CTbyPKJcUj155 g/EXthvxUzhZjdYr3rjTTlh3RQIzQvLu4PLHKBAuXgkpZpsHlmvRMi6vDV3dHGlz dwDPAhB+EqFj2jblRvG74s1KGO/AMrIo5mgSihjg9FgAs9HGx+yerSy8O1uin+ry ooqsFVEvAXdbDM2X3egbhPomWGg9Und2WKJG2KYd4VCQU5kXx1DxRGxIu7a3TJBW 95kzxkwBPqgX3b1xxUWyfcrZPwjj5GDvcJOEBImpqv47IOvM0vYxSYJozV0CBJcp y0+JMVVutGLEwExseGXdZ/OWiXJmoaNCpEiL+9xMYWidmIMq/vhGOcrtZ9iuzunG 4iHQGfyYbJips3Q3MzjUPNVyVUTeJFM6Fu9SYiA5TGC/bk35N6aFQW87l6JYkyUM 4jKGGCgG35XZ/RkM/IUHGEYFCKumdlaKKBYZLB4YmnU2nKCUBbu8HjLNX/sAMxL4 sEBf/45CK7FqIMQcY2Tl =QpBn -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
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Wed, Sep 15, 2010 at 2:25 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Sep 15, 2010 at 00:51, Jonas Smedegaard d...@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 si...@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: 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. /begin rant. 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. /end rant. david http://wiki.sugarlabs.org/go/Development_Team/Release#Fructose 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. 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: http://www.metux.de/index.php/de/component/content/article/57.html Regards, Tomeu 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) iQIcBAEBCgAGBQJMj/x5AAoJECx8MUbBoAEhW8cQAIYyYCa90vhzC5cXmkq+HZIk 74HZZ7qUeb8rXTRedHf/GM3Pd5TaE36xQ/9JSvjkGilZd6zBEh+9OmgQLcOa9i86 en5aKiuPhXXccRqXMFP6CZRCC/g3avwgidgDjbMoWTvigQ35KRuYQEKQx4HxQ6Uw hYuxfh8YizlLw5Cw9nuhJsBinJkZDSFk8LThZlsD8s6yirGOhK2CTbyPKJcUj155 g/EXthvxUzhZjdYr3rjTTlh3RQIzQvLu4PLHKBAuXgkpZpsHlmvRMi6vDV3dHGlz dwDPAhB+EqFj2jblRvG74s1KGO/AMrIo5mgSihjg9FgAs9HGx+yerSy8O1uin+ry ooqsFVEvAXdbDM2X3egbhPomWGg9Und2WKJG2KYd4VCQU5kXx1DxRGxIu7a3TJBW 95kzxkwBPqgX3b1xxUWyfcrZPwjj5GDvcJOEBImpqv47IOvM0vYxSYJozV0CBJcp y0+JMVVutGLEwExseGXdZ/OWiXJmoaNCpEiL+9xMYWidmIMq/vhGOcrtZ9iuzunG 4iHQGfyYbJips3Q3MzjUPNVyVUTeJFM6Fu9SYiA5TGC/bk35N6aFQW87l6JYkyUM 4jKGGCgG35XZ/RkM/IUHGEYFCKumdlaKKBYZLB4YmnU2nKCUBbu8HjLNX/sAMxL4 sEBf/45CK7FqIMQcY2Tl =QpBn -END PGP SIGNATURE-
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
Excerpts from Simon Schampijer's message of Tue Sep 14 16:14:08 +0200 2010: In the .deb side of the universe, we prefer tarballs but we can work directly from the git repository. We should not go from the git repository. Either use the .xo or a tarball. Why? And who is we in this case? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
Excerpts from Gary Martin's message of Wed Sep 15 01:58:07 +0200 2010: [activity release tarballs] I've been uploading me since Bernie kindly un blocked my shell account, though I totally understand why others might not manage this workflow, there's already many hoops to jump though for a casual activity developer to do for a release. What exactly are the hoops you need to jump through? What could we do to make it easier? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 09/15/2010 01:58 AM, Gary Martin wrote: On 14 Sep 2010, at 15:14, Simon Schampijersi...@schampijer.de wrote: Thanks David and Walter for the feedback, On 09/14/2010 04:09 PM, Walter Bender wrote: On Tue, Sep 14, 2010 at 10:05 AM, David Farningdfarn...@gmail.com wrote: On Tue, Sep 14, 2010 at 5:27 AM, Simon Schampijersi...@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. We should not go from the git repository. Either use the .xo or a tarball. Is it not still the practice to put tarballs on download.sl.o ??? -walter Well, the latest mails I have seen about activity releases (besides Chat) does come from ASLO and only state the .xo. If there are tarballs at d.sl.o they have not been announced ;D I've been uploading me since Bernie kindly un blocked my shell account, though I totally understand why others might not manage this workflow, there's already many hoops to jump though for a casual activity developer to do for a release. Are all the ASLO emails not enough? I'm getting three separate emails from the system for every release already! Regards, --Gary Hi Gary, for me having one email from ASLO is fine. But the tarball if it exist should be referenced in the mail. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 09/15/2010 10:41 AM, David Farning wrote: On Wed, Sep 15, 2010 at 2:25 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Wed, Sep 15, 2010 at 00:51, Jonas Smedegaardd...@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 Schampijersi...@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: 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:( We should not go from the git repository. Either use the .xo or a tarball. To quote myself. Ideally there would be tarballs that only contain sources (like Peter said). Those should be used. If not I prefer the .xo, since this is clearly a released Version of the activity. 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:( Wow, if there is a tarball and it has not been announced as a packager I would not go looking through all the sources at sugarlabs.org if I may be lucky finding one. A release email should contain the link or a note to use the .xo imho. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 09/14/2010 11:15 PM, pbrobin...@gmail.com wrote: On Tue, Sep 14, 2010 at 3:09 PM, Walter Benderwalter.ben...@gmail.com wrote: On Tue, Sep 14, 2010 at 10:05 AM, David Farningdfarn...@gmail.com wrote: On Tue, Sep 14, 2010 at 5:27 AM, Simon Schampijersi...@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. Is it not still the practice to put tarballs on download.sl.o ??? No its not! Sebastian and I got sick of sounding like broken down records so I have no idea of the current status. Heh, I can see that frustration. When I saw the the spec that took the xo to extract the sources I thought there might have been an agreement between activity authors and packagers. Seems not. It looks more like resignation. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
Hi Peter, thanks for your feedback. On 09/14/2010 11:19 PM, pbrobin...@gmail.com wrote: On Tue, Sep 14, 2010 at 11:27 AM, Simon Schampijersi...@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). In some cases we've used .xo files but its not ideal and its caused us packaging issues in Fedora as in a lot of cases the .xo files include binary blobs which is against Fedora packaging policies so we have to jump through extra hoops and its generally a pain we'd like to avoid! Personally I'm moving to the point where if there's not a tarball I won't spend my time packaging it. Yes, I think the effort for uploading a bundle that can be easily generated with the tools in sugar is not asked to much to have the activity then packaged in a distribution. And is the email from ASLO enough for packagers to know about new releases? Any other notification that packagers need? That is generally enough but a direct link to both the .xo and tarball makes it quicker for me to update packages as I can grab it from the email. Yes, I think that effort can be requested when someone does a release. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Wed, Sep 15, 2010 at 09:25:57AM +0200, Tomeu Vizoso wrote: On Wed, Sep 15, 2010 at 00:51, Jonas Smedegaard d...@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 si...@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 signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Wed, Sep 15, 2010 at 4:47 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Simon Schampijer's message of Tue Sep 14 16:14:08 +0200 2010: In the .deb side of the universe, we prefer tarballs but we can work directly from the git repository. We should not go from the git repository. Either use the .xo or a tarball. Why? And who is we in this case? For the entire 'why' I will have to refer you to the the Debain mailing lists. /me ducks The short answer is Debian packaging is premised on the idea of a 'pristine source' which historically has been a publicly available tarball. Over the last couple of years Jonas has modified the CDBS (Common Debian Build System) to grab from a properly tagged git repo. 'We' is anyone interested in having their activity packages accepted into Debain. david Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ 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
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 09/15/2010 11:47 AM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Tue Sep 14 16:14:08 +0200 2010: In the .deb side of the universe, we prefer tarballs but we can work directly from the git repository. We should not go from the git repository. Either use the .xo or a tarball. Why? AFAIK, most downstreams prefer/use tarballs as David and Peter has been replying. And who is we in this case? we is imho in this case. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Wed, Sep 15, 2010 at 07:28:05AM -0500, David Farning wrote: On Wed, Sep 15, 2010 at 4:47 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Simon Schampijer's message of Tue Sep 14 16:14:08 +0200 2010: In the .deb side of the universe, we prefer tarballs but we can work directly from the git repository. We should not go from the git repository. Either use the .xo or a tarball. Why? And who is we in this case? For the entire 'why' I will have to refer you to the the Debain mailing lists. /me ducks The short answer is Debian packaging is premised on the idea of a 'pristine source' which historically has been a publicly available tarball. Over the last couple of years Jonas has modified the CDBS (Common Debian Build System) to grab from a properly tagged git repo. I want to clarify a bit here: Debian still very much favor tarballs. If upstreams do not ship tarballs, we need to create a tarball ourselves as part of our packaging efforts. This is bad in my opinion, as there is a higher risk of introducing errors that can go unnoticed: If repackaging accidentally adds, alters or skips some files, then the distributor is unlikely to notice because it is treated as upstream code, and obviously upstream is unlikely to notice too since in fact the (altered) code never appeared upstream. For the Sugar packages in Debian I have gone beyond the minimal requirements in Debian (which includes that mandatory tarball!) in also tracking upstream Git. I do *not* like redistributing directly from Git, and have in the past raised my concern about David Farning and his team of Ubuntu developers packaging directly from Git rather than pushing upstream (i.e. you Sugar guys) to always release tarballs. 'We' is anyone interested in having their activity packages accepted into Debain. He he - I do that typo too. I even mistype my own name as Joans :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 09/15/2010 03:22 PM, Jonas Smedegaard wrote: On Wed, Sep 15, 2010 at 07:28:05AM -0500, David Farning wrote: On Wed, Sep 15, 2010 at 4:47 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Simon Schampijer's message of Tue Sep 14 16:14:08 +0200 2010: In the .deb side of the universe, we prefer tarballs but we can work directly from the git repository. We should not go from the git repository. Either use the .xo or a tarball. Why? And who is we in this case? For the entire 'why' I will have to refer you to the the Debain mailing lists. /me ducks The short answer is Debian packaging is premised on the idea of a 'pristine source' which historically has been a publicly available tarball. Over the last couple of years Jonas has modified the CDBS (Common Debian Build System) to grab from a properly tagged git repo. I want to clarify a bit here: Debian still very much favor tarballs. If upstreams do not ship tarballs, we need to create a tarball ourselves as part of our packaging efforts. This is bad in my opinion, as there is a higher risk of introducing errors that can go unnoticed: If repackaging accidentally adds, alters or skips some files, then the distributor is unlikely to notice because it is treated as upstream code, and obviously upstream is unlikely to notice too since in fact the (altered) code never appeared upstream. For the Sugar packages in Debian I have gone beyond the minimal requirements in Debian (which includes that mandatory tarball!) in also tracking upstream Git. I do *not* like redistributing directly from Git, and have in the past raised my concern about David Farning and his team of Ubuntu developers packaging directly from Git rather than pushing upstream (i.e. you Sugar guys) to always release tarballs. Thanks Jonas for sharing your downstream experience! I absolutely agree that repackaging tarballs is calling for errors. Besides that - I mean doing a tarball is that easy and makes the live of the packagers so much simpler - tbh I don't even know why we have to talk about that over and over again. Can we get over this and just make it a policy that maintainers do tarballs and make it visible? Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
Excerpts from David Farning's message of Wed Sep 15 14:28:05 +0200 2010: We should not go from the git repository. Either use the .xo or a tarball. For the entire 'why' I will have to refer you to the the Debain mailing lists. /me ducks The short answer is Debian packaging is premised on the idea of a 'pristine source' which historically has been a publicly available tarball. I understand that part. However it sounded like Simon implied it would be bad behaviour if a distro maintainer fetched from git even if the git repo is appropriately tagged and exactly matched the tarball. But maybe I just misinterpreted his mail. FWIW, the ability to pull both Debian package management files and updated upstream source from git repos and combine them locally to produce snapshot packages for testing has been very useful to me. I would love to see more maintainers use git repos in a way that enables this. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Tue, Sep 14, 2010 at 5:27 AM, Simon Schampijer si...@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. I have cced jonas for an official position. david Regards, Simon * Of course any other downstreams that package/include activities are happy to reply to this email too. ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Tue, Sep 14, 2010 at 10:05 AM, David Farning dfarn...@gmail.com wrote: On Tue, Sep 14, 2010 at 5:27 AM, Simon Schampijer si...@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. Is it not still the practice to put tarballs on download.sl.o ??? -walter I have cced jonas for an official position. david Regards, Simon * Of course any other downstreams that package/include activities are happy to reply to this email too. ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
Thanks David and Walter for the feedback, On 09/14/2010 04:09 PM, Walter Bender wrote: On Tue, Sep 14, 2010 at 10:05 AM, David Farningdfarn...@gmail.com wrote: On Tue, Sep 14, 2010 at 5:27 AM, Simon Schampijersi...@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. We should not go from the git repository. Either use the .xo or a tarball. Is it not still the practice to put tarballs on download.sl.o ??? -walter Well, the latest mails I have seen about activity releases (besides Chat) does come from ASLO and only state the .xo. If there are tarballs at d.sl.o they have not been announced ;D Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Tue, Sep 14, 2010 at 3:09 PM, Walter Bender walter.ben...@gmail.com wrote: On Tue, Sep 14, 2010 at 10:05 AM, David Farning dfarn...@gmail.com wrote: On Tue, Sep 14, 2010 at 5:27 AM, Simon Schampijer si...@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. Is it not still the practice to put tarballs on download.sl.o ??? No its not! Sebastian and I got sick of sounding like broken down records so I have no idea of the current status. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Tue, Sep 14, 2010 at 11:27 AM, Simon Schampijer si...@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). In some cases we've used .xo files but its not ideal and its caused us packaging issues in Fedora as in a lot of cases the .xo files include binary blobs which is against Fedora packaging policies so we have to jump through extra hoops and its generally a pain we'd like to avoid! Personally I'm moving to the point where if there's not a tarball I won't spend my time packaging it. And is the email from ASLO enough for packagers to know about new releases? Any other notification that packagers need? That is generally enough but a direct link to both the .xo and tarball makes it quicker for me to update packages as I can grab it from the email. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 14.09.2010, at 23:15, pbrobin...@gmail.com wrote: On Tue, Sep 14, 2010 at 3:09 PM, Walter Bender walter.ben...@gmail.com wrote: On Tue, Sep 14, 2010 at 10:05 AM, David Farning dfarn...@gmail.com wrote: In the .deb side of the universe, we prefer tarballs but we can work directly from the git repository. Is it not still the practice to put tarballs on download.sl.o ??? No its not! Sebastian and I got sick of sounding like broken down records so I have no idea of the current status. Not sure I can parse what you mean. Are you saying it is not current practice but it should be? And (from your other msg) why do you want both zip (xo) and tar balls? - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Tue, Sep 14, 2010 at 10:51 PM, Bert Freudenberg b...@freudenbergs.de wrote: On 14.09.2010, at 23:15, pbrobin...@gmail.com wrote: On Tue, Sep 14, 2010 at 3:09 PM, Walter Bender walter.ben...@gmail.com wrote: On Tue, Sep 14, 2010 at 10:05 AM, David Farning dfarn...@gmail.com wrote: In the .deb side of the universe, we prefer tarballs but we can work directly from the git repository. Is it not still the practice to put tarballs on download.sl.o ??? No its not! Sebastian and I got sick of sounding like broken down records so I have no idea of the current status. Not sure I can parse what you mean. Are you saying it is not current practice but it should be? It seems it generally doesn't happen. No idea if its policy or not. And (from your other msg) why do you want both zip (xo) and tar balls? I just want sure source code only tarfiles. I presume for a.sl.o there's a need for ready to run .xo files which may or may not contain pre compiled binaries. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 15.09.2010, at 00:07, pbrobin...@gmail.com wrote: On Tue, Sep 14, 2010 at 10:51 PM, Bert Freudenberg b...@freudenbergs.de wrote: And (from your other msg) why do you want both zip (xo) and tar balls? I just want sure source code only tarfiles. I presume for a.sl.o there's a need for ready to run .xo files which may or may not contain pre compiled binaries. Thanks, that's clearer :) - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Tue, Sep 14, 2010 at 09:05:53AM -0500, David Farning wrote: On Tue, Sep 14, 2010 at 5:27 AM, Simon Schampijer si...@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, 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. 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 signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On 14 Sep 2010, at 15:14, Simon Schampijer si...@schampijer.de wrote: Thanks David and Walter for the feedback, On 09/14/2010 04:09 PM, Walter Bender wrote: On Tue, Sep 14, 2010 at 10:05 AM, David Farningdfarn...@gmail.com wrote: On Tue, Sep 14, 2010 at 5:27 AM, Simon Schampijersi...@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. We should not go from the git repository. Either use the .xo or a tarball. Is it not still the practice to put tarballs on download.sl.o ??? -walter Well, the latest mails I have seen about activity releases (besides Chat) does come from ASLO and only state the .xo. If there are tarballs at d.sl.o they have not been announced ;D I've been uploading me since Bernie kindly un blocked my shell account, though I totally understand why others might not manage this workflow, there's already many hoops to jump though for a casual activity developer to do for a release. Are all the ASLO emails not enough? I'm getting three separate emails from the system for every release already! Regards, --Gary Regards, Simon ___ 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
