Re: [Sugar-devel] Proposal: Adding Manuel Quiñones as a Sugar shell maintainer
Thanks for all the responses. Welcome Manuel [1]! Regards, Simon [1] http://wiki.sugarlabs.org/go/Development_Team/Release/Modules#Glucose On 08/08/2012 04:57 PM, Daniel Narvaez wrote: +1 ! (and I think the maintainers for sugar-artwork, sugar-toolkit and sugar should just be the same). On 7 August 2012 16:51, Simon Schampijer si...@schampijer.de wrote: Hi, Something I wanted to propose in todays developer meeting (but as it did not happen), I send it here for an async proposal. We are short on maintainers and we have to grow new members that helps us share the load. The patch list is long and help in that regard will be appreciated that especially small patches do not take so long to get in. Lately Manuel Quiñones have been stepping up as a Sugar module maintainer. He is already maintaining sugar-artwork and sugar-toolkit-gtk3 [1]. He has been showing great talent with porting the Browse activity to WebkitGtk [2] and he has been working on porting the Sugar theme and the sugar-toolkit to GTK+ 3. We are currently working on the shell port to GTK+ 3 and introspection and Manuel has been advancing already quite a lot [3]. As all of those Sugar sub-modules are interlinked I think it makes absolute sense to add him as a maintainer to the Sugar shell as well. To make sure: the general work-flow should not change, patches have to be sent to the mailing list for review. For non-trivial reviews a maintainer should have at least one review, preferred a review and acknowledgment from another maintainer. It is good practice to leave a patch for a few days so everyone maintainer can at least have a high level look if he disagrees with an approach. I hope we can address the issues listed in that way, Simon [1] http://wiki.sugarlabs.org/go/Development_Team/Release/Modules [2] http://git.sugarlabs.org/browse [3] http://git.sugarlabs.org/~manuq/sugar/manuqs-erikos-shell-port ___ 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] Proposal: Adding Manuel Quiñones as a Sugar shell maintainer
+1 ! (and I think the maintainers for sugar-artwork, sugar-toolkit and sugar should just be the same). On 7 August 2012 16:51, Simon Schampijer si...@schampijer.de wrote: Hi, Something I wanted to propose in todays developer meeting (but as it did not happen), I send it here for an async proposal. We are short on maintainers and we have to grow new members that helps us share the load. The patch list is long and help in that regard will be appreciated that especially small patches do not take so long to get in. Lately Manuel Quiñones have been stepping up as a Sugar module maintainer. He is already maintaining sugar-artwork and sugar-toolkit-gtk3 [1]. He has been showing great talent with porting the Browse activity to WebkitGtk [2] and he has been working on porting the Sugar theme and the sugar-toolkit to GTK+ 3. We are currently working on the shell port to GTK+ 3 and introspection and Manuel has been advancing already quite a lot [3]. As all of those Sugar sub-modules are interlinked I think it makes absolute sense to add him as a maintainer to the Sugar shell as well. To make sure: the general work-flow should not change, patches have to be sent to the mailing list for review. For non-trivial reviews a maintainer should have at least one review, preferred a review and acknowledgment from another maintainer. It is good practice to leave a patch for a few days so everyone maintainer can at least have a high level look if he disagrees with an approach. I hope we can address the issues listed in that way, Simon [1] http://wiki.sugarlabs.org/go/Development_Team/Release/Modules [2] http://git.sugarlabs.org/browse [3] http://git.sugarlabs.org/~manuq/sugar/manuqs-erikos-shell-port ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Proposal: Adding Manuel Quiñones as a Sugar shell maintainer
Hi, Something I wanted to propose in todays developer meeting (but as it did not happen), I send it here for an async proposal. We are short on maintainers and we have to grow new members that helps us share the load. The patch list is long and help in that regard will be appreciated that especially small patches do not take so long to get in. Lately Manuel Quiñones have been stepping up as a Sugar module maintainer. He is already maintaining sugar-artwork and sugar-toolkit-gtk3 [1]. He has been showing great talent with porting the Browse activity to WebkitGtk [2] and he has been working on porting the Sugar theme and the sugar-toolkit to GTK+ 3. We are currently working on the shell port to GTK+ 3 and introspection and Manuel has been advancing already quite a lot [3]. As all of those Sugar sub-modules are interlinked I think it makes absolute sense to add him as a maintainer to the Sugar shell as well. To make sure: the general work-flow should not change, patches have to be sent to the mailing list for review. For non-trivial reviews a maintainer should have at least one review, preferred a review and acknowledgment from another maintainer. It is good practice to leave a patch for a few days so everyone maintainer can at least have a high level look if he disagrees with an approach. I hope we can address the issues listed in that way, Simon [1] http://wiki.sugarlabs.org/go/Development_Team/Release/Modules [2] http://git.sugarlabs.org/browse [3] http://git.sugarlabs.org/~manuq/sugar/manuqs-erikos-shell-port ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal: Adding Manuel Quiñones as a Sugar shell maintainer
On Tue, Aug 7, 2012 at 10:51 AM, Simon Schampijer si...@schampijer.de wrote: Hi, Something I wanted to propose in todays developer meeting (but as it did not happen), I send it here for an async proposal. We are short on maintainers and we have to grow new members that helps us share the load. The patch list is long and help in that regard will be appreciated that especially small patches do not take so long to get in. Lately Manuel Quiñones have been stepping up as a Sugar module maintainer. He is already maintaining sugar-artwork and sugar-toolkit-gtk3 [1]. He has been showing great talent with porting the Browse activity to WebkitGtk [2] and he has been working on porting the Sugar theme and the sugar-toolkit to GTK+ 3. We are currently working on the shell port to GTK+ 3 and introspection and Manuel has been advancing already quite a lot [3]. As all of those Sugar sub-modules are interlinked I think it makes absolute sense to add him as a maintainer to the Sugar shell as well. To make sure: the general work-flow should not change, patches have to be sent to the mailing list for review. For non-trivial reviews a maintainer should have at least one review, preferred a review and acknowledgment from another maintainer. It is good practice to leave a patch for a few days so everyone maintainer can at least have a high level look if he disagrees with an approach. I hope we can address the issues listed in that way, Simon What a great tragedy, we have contributions coming in faster than we can approve them :-) Here are my observations: We have been blessed by a larger than usual number of contributors to the core modules this cycle, just to mention a few of the new contributors and apologies to anyone I've missed, dnarvaez, danielf, Caspar and several others that are contributing via Activity Central. As a community we want to encourage this influx by giving rapid feedback (and ideally acceptance) of their contributions as a fitting form of thanks for their efforts. This will be an unusually disruptive development cycle because of the underlying technology shift from gtk2 to gtk3, the removal of obsoleted technologies like hippo, the introduction of introspection, etc., etc., etc. There is a large amount of ground to cover. This cycle will see nearly every module touched and modified in some fundamental way, which requires lots of coordination and careful review of contributions against the big picture. Given the larger number of contributors, having a larger number of gatekeepers performing that detailed review and high-level integration is essential to achieve the ambitious goals of this development cycle. This cycle is seeing the proposed integration of a substantial series of carefully considered feature enhancements coming from Activity Central's Dextrose 3. These features were all based on end-user requests and all have been extensively field tested in deployments running Dextrose. Nonetheless, reviewing and accepting them is a substantial task and again, it is only appropriate that Activity Central's effort in developing these and offering them back to the upstream should be recognized by a respectful consideration of their contributions for inclusion. Code shuffling: Please forgive me if I mis-characterize anyone's proposals, but I have seen ideas floated about rearranging functional elements for a variety of reasons, whether it is abstracting text-to-speech to a higher level or modularizing the control panel functions to provide great flexibility for customization, there are a number of ideas out there on moving bits of functionality about in the code base in ways that clearly make sense to the proposer (and probably many others) and are certainly worthy of consideration. All of the above is more-or-less without really breaking any new ground, but we also have the impending need to support touch input and on screen keyboards being driven by OLPC's technology developments, which will likely see the integration of new bits of code with widespread potential impact. There is a lot of work to be done and we need trusted hands guiding that work into our repository and releases, I am entirely in favor of granting manuq the privilege of tackling a portion of that important effort in collaboration with silbe and erikos (doesn't dsd own an OLPC-specific element of this as well? I can't recall clearly.) Manuel has my confidence that he will do the right thing. Given the scope of the effort being undertaken this development cycle, it will be a minor miracle if we do not hit a flag day at some point, but I am fairly confident that if we do, it will not be out of sloppiness or inattention by the maintainers, but because of the leaps forward being taken. In the immortal words of Robert Browning Ah, but a man's reach should exceed his grasp -- or what's a heaven for? On a more somber note, the testing and QA phase at the end of this development cycle will be all
Re: [Sugar-devel] Proposal: Adding Manuel Quiñones as a Sugar shell maintainer
After the long reply from cjl, I only can say ... +1 to have manuq as new maintainer in sugar module Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
