Re: [Sugar-devel] Private vs Public conversations.
On Wed, Oct 23, 2013 at 1:48 PM, David Farning wrote: > On Wed, Oct 23, 2013 at 9:26 AM, Walter Bender > wrote: [snip] >> I don't understand what you are asking. Sugar Labs has always had a >> policy of working in the open. > > The degree of openness and transparency is our fundamental > disagreement. Best case is that the status quo works, Sugar Labs > thrives, and I am proven wrong. Worst case is that Sugar adopts to the > changing environment. > Not a clue as to what you are talking about. How about some transparency as to what our disagreement is? [snip] > > -- > David Farning > Activity Central: http://www.activitycentral.com -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] Private vs Public conversations.
On Wed, Oct 23, 2013 at 9:26 AM, Walter Bender wrote: > On Wed, Oct 23, 2013 at 12:04 PM, David Farning > wrote: >> I just wanted to bump this line of questions as, it is the critical >> set of questions which will determine the future viability of Sugar. >> >> If anyone as more informed, please correct me if I am sharing >> incorrect information: >> 1. The Association has dropped future development of XO laptops and >> Sugar as part of their long term strategy. I base this on the >> reduction of hardware and software personal employed by the >> Association. >> 2. The Association is reducing its roll within the engineering and >> development side of the ecosystem. I base this on the shift toward >> integrating existing technology, software, and content from other >> vendors on the XO tablet. >> 3. The Association is shifting away from its initial roll as a >> technical philanthropy to a revenue generating organization structured >> as a association. I base this on the general shift in conversations >> and decisions from public to private channels. >> > > I don't speak on behalf of the Association, but I think your positions > are overstated. I hope to be proven wrong and the laptop side of the Association regains momentum. > As far as I know, the Association is still pursing > sales of XO laptops and is still supporting XO laptops in the field. > Granted the pace of development is slowed and there is -- to my > knowledge -- no team in place to develop an follow up to the XO 4.0. I > don't have a clue as to what you mean by a "technical philanthropy" > but it remains a non-profit associated dedicated to enhancing learning > opportunities through one-to-one computing. The fact that the > Association has private-sector partners is nothing new. It has had > such partners since its founding in 2006. > >> Given financial constraints, these are reasonable shifts. While >> painful, the world is better of with a leaner (and meaner) OLPC >> Association which lives to fight another day. The challenge moving >> forward is how to develop and maintain the Sugar platform, the >> universe of activities, and the supporting distributions given the >> reduction in patronage from the OLPC Association. >> >> I, and AC, would be happy to work more closely with Sugar Labs if >> there are ways to establish publicly disclosed and mutually beneficial >> relationships. In the meantime we are happy to provide deployments >> support while seeding and supporting projects we feel are beneficial >> to deployments such as School Server Community Edition and Sugar on >> Ubuntu. > > I don't understand what you are asking. Sugar Labs has always had a > policy of working in the open. The degree of openness and transparency is our fundamental disagreement. Best case is that the status quo works, Sugar Labs thrives, and I am proven wrong. Worst case is that Sugar adopts to the changing environment. > That said, Sugar Labs volunteers (yes, > we are all volunteers), have on occasion done consulting for OLPC, AC, > deployments, and other third parties. Nothing new or unusual about > that either. > > The future of Sugar is incumbant upon its remaining relevant to > learning and its maintaining a vibrant upstream community. If you (and > AC) want to contribute to the future of Sugar, please work with us > upstream, e.g. report bugs upstream, submit patches upstream, test > code originating upstream, mentor newbies, etc. Par for the course for > any FOSS project. > >> >> On Sun, Oct 20, 2013 at 6:11 AM, David Farning >> wrote: >>> On Sat, Oct 19, 2013 at 2:43 PM, Gonzalo Odiard wrote: I agree with your analysis about slow deployment updates versus fast community cycles. In my view, there are two alternatives: * We can slow down a little the Sugar cycle, may be doing one release by year, but I am not sure if will help. The changes will take more time to go to the users? If a deployment miss a update, will need wait a entire year? * Someone can work in a LTS Sugar. That should be good if they can push the fixes they work upstream while they are working in their own project. >>> >>> If someone, individuals or a third party, were willing and able to >>> provide LTS support for a version of Sugar, how would you recommend >>> they go about doing it? >>> >>> With the recent changes to the ecosystem, I am unclear about the >>> current structure, culture, and politics of Sugar Labs. My concern is >>> that in that past several years a number of organization who have >>> participated in Sugar development have left or reduced their >>> participation. When asking them why they left, the most common >>> response is that that they didn't feel they were able to establish or >>> sustain mutually beneficial relationships within the ecosystem. >>> >>> Would you be interesting in looking at cultural, political, and >>> procedural traits which have enabled other free and opensource >>> projects to
[Server-devel] XSCE/xsce and activitycetral/dxs repository integration in a branch preserving history
My suggestion to integrate "activitycetral/dxs" into "XSCE/xsce" preserving history and using a branch for easier comparison is: 1. revert xsce/master to fa2d59, 2. create a 'dxs' branch 3. merge activitycentral/dxs commits to this new branch preserving history This new branch (XSCE/xsce@dxs) will be the canonical repository for the migration and everybody will pull request against this branch. Detailed procedure on a fresh repository 1. revert Clean repo: ``` git clone g...@github.com:XSCE/xsce.git cd xsce ``` The actual revert: ``` git revert -m 1 b1638cd --no-edit ``` Submit changes: ``` git push origin ``` 2. create branch ``` git branch dxs git checkout dxs git push origin dxs ``` 3. merge Fetch dxs repository: ``` git remote add dxs g...@github.com:activitycentral/dxs git fetch dxs ``` And now the critical part, the actual merge: ``` git merge --no-ff -s recursive -X ours --no-edit dxs/master ``` Push! ``` git push origin dxs So, anyone with write permission on xsce can do this. You can check how would be the resulting repo in my personal clone copy in https://github.com/migonzalvar/xsce. -- Miguel González Activity Central: http://www.activitycentral.com ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Sugar-devel] Private vs Public conversations.
On Wed, Oct 23, 2013 at 12:04 PM, David Farning wrote: > I just wanted to bump this line of questions as, it is the critical > set of questions which will determine the future viability of Sugar. > > If anyone as more informed, please correct me if I am sharing > incorrect information: > 1. The Association has dropped future development of XO laptops and > Sugar as part of their long term strategy. I base this on the > reduction of hardware and software personal employed by the > Association. > 2. The Association is reducing its roll within the engineering and > development side of the ecosystem. I base this on the shift toward > integrating existing technology, software, and content from other > vendors on the XO tablet. > 3. The Association is shifting away from its initial roll as a > technical philanthropy to a revenue generating organization structured > as a association. I base this on the general shift in conversations > and decisions from public to private channels. > I don't speak on behalf of the Association, but I think your positions are overstated. As far as I know, the Association is still pursing sales of XO laptops and is still supporting XO laptops in the field. Granted the pace of development is slowed and there is -- to my knowledge -- no team in place to develop an follow up to the XO 4.0. I don't have a clue as to what you mean by a "technical philanthropy" but it remains a non-profit associated dedicated to enhancing learning opportunities through one-to-one computing. The fact that the Association has private-sector partners is nothing new. It has had such partners since its founding in 2006. > Given financial constraints, these are reasonable shifts. While > painful, the world is better of with a leaner (and meaner) OLPC > Association which lives to fight another day. The challenge moving > forward is how to develop and maintain the Sugar platform, the > universe of activities, and the supporting distributions given the > reduction in patronage from the OLPC Association. > > I, and AC, would be happy to work more closely with Sugar Labs if > there are ways to establish publicly disclosed and mutually beneficial > relationships. In the meantime we are happy to provide deployments > support while seeding and supporting projects we feel are beneficial > to deployments such as School Server Community Edition and Sugar on > Ubuntu. I don't understand what you are asking. Sugar Labs has always had a policy of working in the open. That said, Sugar Labs volunteers (yes, we are all volunteers), have on occasion done consulting for OLPC, AC, deployments, and other third parties. Nothing new or unusual about that either. The future of Sugar is incumbant upon its remaining relevant to learning and its maintaining a vibrant upstream community. If you (and AC) want to contribute to the future of Sugar, please work with us upstream, e.g. report bugs upstream, submit patches upstream, test code originating upstream, mentor newbies, etc. Par for the course for any FOSS project. > > On Sun, Oct 20, 2013 at 6:11 AM, David Farning > wrote: >> On Sat, Oct 19, 2013 at 2:43 PM, Gonzalo Odiard wrote: >>> I agree with your analysis about slow deployment updates versus fast >>> community cycles. >>> >>> In my view, there are two alternatives: >>> >>> * We can slow down a little the Sugar cycle, may be doing one release by >>> year, >>> but I am not sure if will help. The changes will take more time to go to the >>> users? >>> If a deployment miss a update, will need wait a entire year? >>> * Someone can work in a LTS Sugar. That should be good if they can push >>> the fixes they work upstream while they are working in their own project. >> >> If someone, individuals or a third party, were willing and able to >> provide LTS support for a version of Sugar, how would you recommend >> they go about doing it? >> >> With the recent changes to the ecosystem, I am unclear about the >> current structure, culture, and politics of Sugar Labs. My concern is >> that in that past several years a number of organization who have >> participated in Sugar development have left or reduced their >> participation. When asking them why they left, the most common >> response is that that they didn't feel they were able to establish or >> sustain mutually beneficial relationships within the ecosystem. >> >> Would you be interesting in looking at cultural, political, and >> procedural traits which have enabled other free and opensource >> projects to foster thriving ecosystems? Are these traits present in >> Sugar Labs? >> >> While, I understand it is frustrating for an upstream software >> developer. A primary tenet of free and open sources software is that >> then anyone can use and distribute the software as they see fit as >> long as the source code is made available. The challenge for an >> upstream is to create an environment where it is more beneficial for >> individuals and organizations to work together than it
Re: [Sugar-devel] Private vs Public conversations.
I just wanted to bump this line of questions as, it is the critical set of questions which will determine the future viability of Sugar. If anyone as more informed, please correct me if I am sharing incorrect information: 1. The Association has dropped future development of XO laptops and Sugar as part of their long term strategy. I base this on the reduction of hardware and software personal employed by the Association. 2. The Association is reducing its roll within the engineering and development side of the ecosystem. I base this on the shift toward integrating existing technology, software, and content from other vendors on the XO tablet. 3. The Association is shifting away from its initial roll as a technical philanthropy to a revenue generating organization structured as a association. I base this on the general shift in conversations and decisions from public to private channels. Given financial constraints, these are reasonable shifts. While painful, the world is better of with a leaner (and meaner) OLPC Association which lives to fight another day. The challenge moving forward is how to develop and maintain the Sugar platform, the universe of activities, and the supporting distributions given the reduction in patronage from the OLPC Association. I, and AC, would be happy to work more closely with Sugar Labs if there are ways to establish publicly disclosed and mutually beneficial relationships. In the meantime we are happy to provide deployments support while seeding and supporting projects we feel are beneficial to deployments such as School Server Community Edition and Sugar on Ubuntu. On Sun, Oct 20, 2013 at 6:11 AM, David Farning wrote: > On Sat, Oct 19, 2013 at 2:43 PM, Gonzalo Odiard wrote: >> I agree with your analysis about slow deployment updates versus fast >> community cycles. >> >> In my view, there are two alternatives: >> >> * We can slow down a little the Sugar cycle, may be doing one release by >> year, >> but I am not sure if will help. The changes will take more time to go to the >> users? >> If a deployment miss a update, will need wait a entire year? >> * Someone can work in a LTS Sugar. That should be good if they can push >> the fixes they work upstream while they are working in their own project. > > If someone, individuals or a third party, were willing and able to > provide LTS support for a version of Sugar, how would you recommend > they go about doing it? > > With the recent changes to the ecosystem, I am unclear about the > current structure, culture, and politics of Sugar Labs. My concern is > that in that past several years a number of organization who have > participated in Sugar development have left or reduced their > participation. When asking them why they left, the most common > response is that that they didn't feel they were able to establish or > sustain mutually beneficial relationships within the ecosystem. > > Would you be interesting in looking at cultural, political, and > procedural traits which have enabled other free and opensource > projects to foster thriving ecosystems? Are these traits present in > Sugar Labs? > > While, I understand it is frustrating for an upstream software > developer. A primary tenet of free and open sources software is that > then anyone can use and distribute the software as they see fit as > long as the source code is made available. The challenge for an > upstream is to create an environment where it is more beneficial for > individuals and organizations to work together than it is to work > independently. > > To make things more concrete, three areas of concern are Control, Credit, > Money: > -- Control -- Are there mechanism for publicly making and > communicating project direction in a productive manner? Is > disagreement accepted and encouraged? > > -- Credit -- Are there mechanism for publicly acknowledging who > participates and adds value to the ecosystem? Is credit shared freely > and fairly? > > -- Money -- Are there mechanisms in place for publicly acknowledge > that money pays a role in the ecosystem? Is Sugar Labs able to > maintain a neutral base around which people and organizations can > collaborate? > > From my limited experience, I don't believe there is an single holy > grail type answer to any of these questions. Instead, the answers tend > to evolve as situations change and participants come and go. > >> On Sat, Oct 19, 2013 at 9:46 AM, David Farning >> wrote: >>> >>> For phase one this openness in communication, I would like to open the >>> discussion to strategies for working together. My interest is how to >>> deal with the notion of overlapping yet non-identical goals. >>> >>> As a case study, let's look at deployment and developer preferences >>> for stability and innovation. >>> >>> The roll out pipeline for a deployment can be long: >>> 1. Core development. >>> 2. Core validation.. >>> 3. Activity development. >>> 4. Activity validation. >>> 5. Update documentation. >>> 6. Update tra
