Re: [Sugar-devel] Autosave and Keep button
On Wed, Sep 1, 2010 at 16:28, Bert Freudenberg b...@freudenbergs.de wrote: On 01.09.2010, at 14:01, Sascha Silbe wrote: Excerpts from Gary Martin's message of Tue Aug 31 20:07:12 +0200 2010: My first gut reaction (not having seen it yet) is that the Keep button is a real problem generally (and causes confusion and misunderstanding in Sugar). Habitually training kids to click that icon each time before exiting will, for all other activities, generate many confusing duplicate Journal entries over time and make matters even worse. +1 For the Etoys case, as a workaround for not knowing your clean/dirty state, I think having the regular Stop UI button that when clicked _always_ displayed some sort of Do you want to Keep the changes to this project in the Journal? Keep/Don't Keep dialogue. Having the Stop button ask which version (the one in the Journal or the one currently loaded) to destroy is a bad idea, but unsolvable without version support. Please avoid the Keep terminology in this context; it's only going to confuse users even more. Sascha That's one of the reasons I did not want to overload the exit button with saving functionality. It simply exits (after confirming) without ever saving now. To avoid confusion, it does not look like a regular stop button: But you can't really discuss autosaving and keeping separately. They go hand in hand. If an activity cannot autosave, it has to rely on the keep button, right? And keeping should create a new entry - that's how it is in every activity. Only autosave destructively overwrites the current entry. I am warming up to Gary's suggestion though because it's the only way to avoid needless Journal entries, unless we introduce a save/save-as distinction. Incidentally, on other platforms Etoys does versioning itself - every project saved has a version number embedded in the file name that is not visible in the UI. In the file-open dialog, all but the highest numbered versions are hidden. Now maybe if the Journal had a hide attribute for an entry, the Journal would look less cluttered. Also, when running out of space the hidden entries could be used to free up space. Wait, that's re-inventing the trash can ... but maybe not a bad idea after all. The (some?) plans for versioning in the journal called for hiding the less relevants revisions in the main view and only displaying them in the detailed view. Regards, Tomeu - Bert - ___ 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] how many maintainers? (was Re: Bug tracking Vs Patch review)
On Wed, Sep 1, 2010 at 16:18, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió: And we have how many full-time maintainers? We have several, no? You, erikos, alsroot... plus several part-time ones. Collabora is sponsoring me between 1 and 2 weekly days to do anything related to Sugar apart from the collaboration work, this includes maintenance but also quite a bit of other stuff (such as reading and replying emails). I'm pretty sure OLPC is not contracting Simon just for maintenance work. Is Aleksey hired full-time for maintenance work? What about Anish? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] jhbuild breakage (was Re: Bug tracking Vs Patch review)
On Wed, Sep 1, 2010 at 16:18, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió: Patches were promptly made available in the mailing list and some have already been accepted by Sascha into jhbuild. Still doesn't work here, neither with jhbuild nor with Fedora packages. It's not a mere dependency issue: http://bugs.sugarlabs.org/ticket/2269 http://bugs.sugarlabs.org/ticket/2270 Are you *sure* you applied the patch in http://bugs.sugarlabs.org/ticket/2228 ? I have just went through a clean checkout and build of jhbuild on F13 and it just worked (the patch there has bitrotten a bit but the merge is trivial). If you indeed applied the patch and it's something system-specific we'll need more information than what is available on the tickets right now. If there are other people having trouble with jhbuild right now would be good if they shared their experiences in this thread. Thanks, Tomeu A few days ago I was also seeing another error in the logs about a missing changed-activity signal, but it seems to have disappeared now. Regardless, we proceeded to release 0.89.5 tarballs that downstreams promptly turned into broken packages (tested on Fedora). You clearly had different results than me when testing on F14, have you filed bugs or reported them in some place? What distro did you use? It also fails on Ubuntu and Fedora 13 according to other people on #sugar. Did you really hear about this for the first time for me? By the way, this is called integration testing and it happens every cycle in GNOME's jhbuild and again when stuff gets packaged at first in Fedora. We're not talking about a minor integration glitch. It's broken on 3 distros (minimum). The problems found during the integration phase are due to the unexpected effects of putting together for the first time specific versions of hundreds of different dependencies built with specific sets of build options (such as the gnome-keyring issue with mission-control). How did you expected to catch those by reading Sugar patches? Not by reading patches, but by having the maintainer test that at least jhbuild still runs before pushing, or at least before releasing tarballs. But I'm assuming that Sugar is currently broken for everyone, which does not seem to be the case at least for you. We seem to be missing the equivalent of a product manager... someone who cares for the product as a whole. In a different occasion, Walter noted the need for an architect, but in a project like ours these are very much the same thing, just with an emphasis on the present or on the future. It would help if you described that role in some details, otherwise can mean too many different things. This is more or less what I'm thinking of: http://en.wikipedia.org/wiki/Product_manager This is common business practice. If you prefer the agile software development terminology, we need a Product Owner for Sugar. Walter some time ago called for an Architect, which is something close, but with a focus on technical aspects of the product and long-term evolution of the codebase. We merged a total of 355 patches in sugar over the last 365 months. Exactly one patch per day. Over the same period, Linus merged 100 times this number of patches, Looks like you are onto something big here. After you fix Sugar you can go fix GNOME and the rest of FOSS projects, then with 100 times more productivity Microsoft, Apple and Google will disappear in a puff of smoke. meaning that maintaining Sugar should be feasible even as a part-time job. And we have how many full-time maintainers? We have several, no? You, erikos, alsroot... plus several part-time ones. So complaining that we don't have enough maintainers for merging 350 patches per year is clearly missing the point. The problem we have is one of organization, not one one of resources. The number of new features and bugfixes in Dextrose proves that there are abundant resources for Sugar development. We're just blocking them from contributing effectively because the processes we have in place don't work well. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] sugar broken in F14? (was Re: Bug tracking Vs Patch review)
On Wed, Sep 1, 2010 at 16:18, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió: Regardless, we proceeded to release 0.89.5 tarballs that downstreams promptly turned into broken packages (tested on Fedora). You clearly had different results than me when testing on F14, have you filed bugs or reported them in some place? What distro did you use? It also fails on Ubuntu and Fedora 13 according to other people on #sugar. Did you really hear about this for the first time for me? I'm testing daily the Sugar 0.90 packages that Peter (big thanks!) is doing on F14 and the tarballs that you see I'm making are intended to fix issues I find there. I'm still updating, but as of yesterday Sugar was starting correctly and I couldn't find any major issues. I alone won't find all the issues so if you (and others) can file the bugs you find, I will be able to fix them faster. Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] how many maintainers? (was Re: Bug tracking Vs Patch review)
On 09/02/2010 09:50 AM, Tomeu Vizoso wrote: On Wed, Sep 1, 2010 at 16:18, Bernie Innocentiber...@codewiz.org wrote: El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió: And we have how many full-time maintainers? We have several, no? You, erikos, alsroot... plus several part-time ones. Yes, I can spend a bit of my working time on maintenance. Though I do as well release management. And of course I can not do upstream work all day :) And until recently I did maintenance in my spare time. It is probably fair to say that until recently Tomeu did most of the maintenance work of the development branch. So yes, having more maintainers would speed up that part of our work. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Sucrose 0.89.5 Development (Beta) Release
Dear Sugar Community,
this is our development release number 5 in the 0.90 development cycle
[1]! This is our Beta release! We would like to invite you for testing
now. The plan is to have a Soas build with the latest 0.90 Sugar
packages available by the end of the week. We will send another
announcement when it is ready for download.
We now reached String Freeze [2], no string changes may be made without
confirmation from the localization team and notification to the release
team! We encourage translators to translate the new strings that has
been introduced by the various new Features.
Furthermore Tomeu Vizoso made great progress in fixing integration bugs
introduced by the Remove Presence Service Feature [3].
The Etoys team reports that the first beta release of Etoys 4.1 is now
available. The biggest change is that stopping the Etoys activity will
no longer save to the Journal. To save, you will have to press the keep
button. The octagonal stop button is replaced by a circular exit button
to indicate the new behavior. It puts up a warning before actually
quitting. More about the rationale for this change can be found at [4].
Full release notes can be found at [5].
Thanks everyone for your great contributions!
In behalf of the sugar community,
Your Release Team
[1] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule
[2] http://wiki.sugarlabs.org/go/Development_Team/Release#String_Freeze
[3] http://wiki.sugarlabs.org/go/Features/Remove_Presence_Service
[4] http://lists.sugarlabs.org/archive/sugar-devel/2010-August/026398.html
[5] http://wiki.sugarlabs.org/go/0.90/0.89.5_Notes
== Compatibility ==
There are no known compatibility issues, as of today.
== Update to this version ==
Please use the instructions for your distribution (SoaS, Fedora, Ubuntu,
Debian etc) of choice to upgrade to this release. Note that it may take
a while until the release is packaged for each distribution.
== Glucose modules==
===Updated===
*
http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.89.7.tar.bz2
*
http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.89.5.tar.bz2
*
http://download.sugarlabs.org/sources/sucrose/glucose/etoys/etoys-4.1.2384.tar.gz
== Glucose news ==
=== sugar ===
* AP: signal strength update not separate from state change {{Bug|2246}}
(Simon Schampijer)
* Listen to changes to the nick and jabber server settings and update MC
appropriately (Tomeu Vizoso)
* Journal: Alert if an error occurs when copying to devices in the
detail view {{Bug|1842}} (Simon Schampijer)
* Sugar GConf settings breaks mouse buttons behavior in gnome session
{{Bug|1544}} (Aleksey Lim)
=== sugar-toolkit ===
* sugar.presence: Remove dead code and make clear which methonds are
deprecated (Tomeu Vizoso)
* Read the public and private keys lazily (Tomeu Vizoso)
* Use Account.ConnectionStatus instead of Account.Connection.Status
(Tomeu Vizoso)
=== Etoys ===
* no save on stop under Sugar, must use keep button (enable
sugarAutoSave to revert to old behavior)
* easier to make flap (see supplies)
* GSoC addition: scriptable speech bubbles
* translatability of Text object must be enabled explicitly
* minor fixes
* updated translations from Pootle
* added languages zh_CN, ca, sk, pap, pl, km, en_GB, ar_SY
* revised Italian, Portuguese, and German QuickGuides
== What is new for packagers ==
New API has been added to telepathy-gabble and telepathy-salut to
support the work on the collaboration framework, which results in
needing 0.9.16 for tp-gabble and 0.3.13 for tp-salut.
One of the goals of the collaboration refactoring was dropping
functionality in sugar that has been implemented in
[http://telepathy.freedesktop.org/wiki/Mission%20Control
telepathy-mission-control], so Sugar now depends on tp-mission-control
5.4.3.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Autosave and Keep button
On 02.09.2010, at 09:27, Tomeu Vizoso wrote: On Wed, Sep 1, 2010 at 16:28, Bert Freudenberg b...@freudenbergs.de wrote: On 01.09.2010, at 14:01, Sascha Silbe wrote: Excerpts from Gary Martin's message of Tue Aug 31 20:07:12 +0200 2010: My first gut reaction (not having seen it yet) is that the Keep button is a real problem generally (and causes confusion and misunderstanding in Sugar). Habitually training kids to click that icon each time before exiting will, for all other activities, generate many confusing duplicate Journal entries over time and make matters even worse. +1 For the Etoys case, as a workaround for not knowing your clean/dirty state, I think having the regular Stop UI button that when clicked _always_ displayed some sort of Do you want to Keep the changes to this project in the Journal? Keep/Don't Keep dialogue. Having the Stop button ask which version (the one in the Journal or the one currently loaded) to destroy is a bad idea, but unsolvable without version support. Please avoid the Keep terminology in this context; it's only going to confuse users even more. Sascha That's one of the reasons I did not want to overload the exit button with saving functionality. It simply exits (after confirming) without ever saving now. To avoid confusion, it does not look like a regular stop button: But you can't really discuss autosaving and keeping separately. They go hand in hand. If an activity cannot autosave, it has to rely on the keep button, right? And keeping should create a new entry - that's how it is in every activity. Only autosave destructively overwrites the current entry. I am warming up to Gary's suggestion though because it's the only way to avoid needless Journal entries, unless we introduce a save/save-as distinction. Incidentally, on other platforms Etoys does versioning itself - every project saved has a version number embedded in the file name that is not visible in the UI. In the file-open dialog, all but the highest numbered versions are hidden. Now maybe if the Journal had a hide attribute for an entry, the Journal would look less cluttered. Also, when running out of space the hidden entries could be used to free up space. Wait, that's re-inventing the trash can ... but maybe not a bad idea after all. The (some?) plans for versioning in the journal called for hiding the less relevants revisions in the main view and only displaying them in the detailed view. Regards, Tomeu Yes, I know. However, real versioning seems to be far too complicated to actually get implemented and adopted. It might be too large a step. It would be (IMHO) much simpler if updating a Journal entry would just make a hidden copy with the old contents and metadata first. This poor man's versioning would alleviate the destructive nature of auto-save. It *would* be possible to access overwritten versions if necessary. OTOH that's tangential to the Etoys problem, which would not be solved even by a real versioning scheme. In Etoys, auto-save is rarely what the user needs. Maybe if the explicitly kept versions were preferred over the auto-saved ones ... But then it's hard to tell. Hmm, remind me again why resume-by-default from the home view was a good idea. I know I supported it at the time we discussed it. It works well for e.g. Terminal. But for activities like Etoys it gets in the way. How about we allow activities to disable it in activity.info? - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] how many maintainers? (was Re: Bug tracking Vs Patch review)
On Thu, Sep 2, 2010 at 2:50 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Sep 1, 2010 at 16:18, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 31-08-2010 a las 10:33 +0200, Tomeu Vizoso escribió: And we have how many full-time maintainers? We have several, no? You, erikos, alsroot... plus several part-time ones. Collabora is sponsoring me between 1 and 2 weekly days to do anything related to Sugar apart from the collaboration work, this includes maintenance but also quite a bit of other stuff (such as reading and replying emails). I'm pretty sure OLPC is not contracting Simon just for maintenance work. Is Aleksey hired full-time for maintenance work? What about Anish? Activity Central has hired Aleksey to mentor new developers. I think this requires about 3 hour per day. This Leaving him the rest of his time to what every he wants -- Oinstall:) Activity Central and ParaguayEduca have jointly hired Anish to work onsite at ParaguaryEduca to improve the flow between their deployment and upstream Sugar and OLPC. david Regards, Tomeu ___ 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] [olpc-nz] Twi translation
I have forwarded this to sugar-devel. Often I have seen sysamindu handle these requests on IRC. But I believe he has returned to school. david On Thu, Sep 2, 2010 at 4:54 AM, Tabitha Roder tabi...@tabitha.net.nz wrote: On 31 August 2010 09:10, Brenda Wallace bre...@coffee.geek.nz wrote: My colleague, Charlie, has vounteered to do Twi translations of sugar text. Twi is the language of Ghana. Anyone on this list set up translation before? Can you point on the way to get an interface infront of Charlie so he can go for it? I got Tongan, Maori and Samoan started. Best thing to do is submit request to http://bugs.sugarlabs.org/ that says please create Twi language and add terminology project and glucose project. We suggest the terminology project (these are like keywords that give you a start point for all the other projects) and glucose project (the main file for the majority of words found in the Sugar interface) before tackling the others. The translation team should respond pretty quick. Charlie will need access to Sugar (on a Stick is fine) to see the words in context while doing the translation. Tabitha ___ olpc-nz mailing list olpc...@lists.laptop.org http://lists.laptop.org/listinfo/olpc-nz ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] Stability stuff
Weird, I really tried to trigger it on our last Dextrose build and never happened. The whole idea of killing activities is a little bit controversial I think, you have to assume to many things about activities, so far just a few activities in sugar uses all the proper mechanisms, I am afraid that in most of the cases kids would just loose their current work. What about... If the system load is already close to a critical point, SUGAR could just stop new activities from being executed with a proper warning, and suggestions. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #2230 UNSP: Fototoon 3 does not show controls when speech bubble first selected
Yes. I will. Gonzalo On Thu, Sep 2, 2010 at 7:27 AM, Sugar Labs Bugs bugtracker-nore...@sugarlabs.org wrote: #2230: Fototoon 3 does not show controls when speech bubble first selected --+- Reporter: carrott| Owner: godiard Type: defect | Status: assigned Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team Component: ActivityTeam |Version: 0.88.x Severity: Minor | Keywords: dextrose Distribution: Fedora | Status_field: Unconfirmed --+- Changes (by bernie): * owner: garycmartin = godiard Comment: Gonzalo, could you give a look at this bug? -- Ticket URL: http://bugs.sugarlabs.org/ticket/2230#comment:3 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] screenreader for sugar
On Wed, Sep 1, 2010 at 14:51, Esteban Arias ear...@plan.ceibal.edu.uy wrote: I install orca on xo 1.0 with gnome for f11. If I config to start session with orca, runs ok. But if I execute orca from terminal, dont run correctly: Hi Esteban, could be that your email arrived to us incomplete? Regards, Tomeu 2010/9/1 pbrobin...@gmail.com pbrobin...@gmail.com On Wed, Sep 1, 2010 at 10:24 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Aug 20, 2010 at 14:10, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Aug 20, 2010 at 14:08, Esteban Arias ear...@plan.ceibal.edu.uy wrote: hi, we can colaborate with this proyect. Excelent, have you tried already orca with Sugar? And with GNOME? I would say that the next step is for someone who knows how orca is used to give it a try and file tickets for the biggest issues. Not sure we can make much more until then. The gnome guys mentioned this the other day and there's going to be some more work done within gnome hopefully for F-14. So hopefully we should be looking better for that release. Peter -- Esteban Arias Investigación y Desarrollo - Plan Ceibal Avda. Italia 6201 Montevideo - Uruguay. Tel.: 2601.57.73 Interno 2228 E-mail : ear...@plan.ceibal.edu.uy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Patch review (was: Re: Community)
Excerpts from Tomeu Vizoso's message of Tue Aug 31 13:20:31 +0200 2010: What do you think about a model where we have some git repo that everyone can commit to after they got, say, at least two Reviewed-By (including one from a core / long-term developer)? The contributors would get more testing of their work (= less bugs in the release) and the module maintainers would be able to pick resp. skip the patches they feel (un)comfortable with. But then we would need to resync at some point or merging would get worst with time? We could rebase after each release, like (at least some of) the Linux folks are doing. Either on the master branch, or by creating a new branch for each release (like the OLPC kernel repo). Another idea would be a mailing list where early versions of patches are posted and can get some (incomplete) review. This would allow contributors to get fast easy feedback with a limited amount of time spent for the reviewers. Reviews could just point out a subset of issues; a thorough review and deciding whether it's good enough to be merged would happen like above. I liked how it worked in sugar-devel for a while, a separate mailing list would be also ok if the reviews do disturb people or whatever is the reason for having stopped doing that. To make it clear: Both the new mailing list and sugar-devel would carry reviews. The difference is that RFC / PoC style patches would land on the new mailing list, whereas those intended to get into mainline as-is would be on sugar-devel. This would give a clear indication about whether a patch is intended for mainline and also keep the newbie traffic off sugar-devel (IIRC some people have complained about the high traffic on sugar-devel). The drawback is that we might miss some feedback from people who only subscribe to sugar-devel but not to the new list. But then those are probably the same people that would have complained about the increased traffic. ;) An alternative would be to clearly mark patches with e.g. RFC in the subject and create mailing list topics to allow filtering out review related traffic. We already have [ANNOUNCE] and [RELEASE] topics to allow anyone to receive only important announcements. The drawback of this alternative is that few users notice this option and might unsubscribe instead of activating the topic filter. 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] Patch review (was: Re: Community)
On Thu, Sep 2, 2010 at 18:28, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Tomeu Vizoso's message of Tue Aug 31 13:20:31 +0200 2010: What do you think about a model where we have some git repo that everyone can commit to after they got, say, at least two Reviewed-By (including one from a core / long-term developer)? The contributors would get more testing of their work (= less bugs in the release) and the module maintainers would be able to pick resp. skip the patches they feel (un)comfortable with. But then we would need to resync at some point or merging would get worst with time? We could rebase after each release, like (at least some of) the Linux folks are doing. Either on the master branch, or by creating a new branch for each release (like the OLPC kernel repo). Sounds good. Another idea would be a mailing list where early versions of patches are posted and can get some (incomplete) review. This would allow contributors to get fast easy feedback with a limited amount of time spent for the reviewers. Reviews could just point out a subset of issues; a thorough review and deciding whether it's good enough to be merged would happen like above. I liked how it worked in sugar-devel for a while, a separate mailing list would be also ok if the reviews do disturb people or whatever is the reason for having stopped doing that. To make it clear: Both the new mailing list and sugar-devel would carry reviews. The difference is that RFC / PoC style patches would land on the new mailing list, whereas those intended to get into mainline as-is would be on sugar-devel. This would give a clear indication about whether a patch is intended for mainline and also keep the newbie traffic off sugar-devel (IIRC some people have complained about the high traffic on sugar-devel). The drawback is that we might miss some feedback from people who only subscribe to sugar-devel but not to the new list. But then those are probably the same people that would have complained about the increased traffic. ;) An alternative would be to clearly mark patches with e.g. RFC in the subject and create mailing list topics to allow filtering out review related traffic. We already have [ANNOUNCE] and [RELEASE] topics to allow anyone to receive only important announcements. The drawback of this alternative is that few users notice this option and might unsubscribe instead of activating the topic filter. I for one liked having patch submission and reviews in the same channel as we discuss other development stuff. But will subscribe to another mailing list if needed. Regards, Tomeu 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] Community
Excerpts from Martin Abente's message of Tue Aug 31 20:44:25 +0200 2010: [Organising a Sugar game session, e.g. Sauerbraten] Why not Quake?! Quake 2 coop mode was fun ;) AFAICT the Quake 2 game data is still proprietary, so not available to everyone (legally). Open Arena [1] would be an Open Source alternative. The latter (being based on Quake 3 which has a very different single player mode than Quake 2) shares the drawback of Sauerbraten that there's no co-op mode, though it does at least support bots (while Sauerbraten doesn't). Doom 2 with FreeDoom data files supports co-op mode; there's even an activity for it [2]. I have a feeling it incorporates binary code and won't work on most systems, but AFAIK most distros ship it so that's not an issue. ;) I am not suggesting to eliminate the current process, I am just saying that we should define clear parameters that could help to minimize the current bottle necks generated by the current number of maintainers/reviewers and the difficulties of agreement at the coding and designing stages, respectively. Do you have any concrete idea what we could do to improve or speed up the process? What would you consider the most important blocker / what took most of your time? Sascha [1] http://openarena.ws/ [2] http://wiki.laptop.org/go/Doom -- 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
[Sugar-devel] [PATCH] Make building GConf-dbus optional
Compiling this module frequently breaks, resulting in difficulties for novice developers and waste of time for everyone else. This patch simply makes GConf-dbus an optional compilation unit. If there's some consensus, I could follow up with a more aggressive patch removing it althogether. GConf-dbus is unmaintained and is no longer part of any Linux distribution. It was used to support multiple Sugar profiles within the same UNIX user, a feature of dubious usefulness that could be used to test collaboration without creating multiple accounts. Signed-off-by: Bernie Innocenti ber...@codewiz.org --- config/modulesets/glucose-0.84.modules |1 - config/modulesets/glucose-versionsupport.modules |1 - config/modulesets/glucose.modules|1 - 3 files changed, 0 insertions(+), 3 deletions(-) diff --git a/config/modulesets/glucose-0.84.modules b/config/modulesets/glucose-0.84.modules index 9d7e1cd..005988e 100644 --- a/config/modulesets/glucose-0.84.modules +++ b/config/modulesets/glucose-0.84.modules @@ -21,7 +21,6 @@ autotools id=sugar branch module=sugar/mainline.git revision=sucrose-0.84 checkoutdir=sugar/ dependencies - dep package=GConf-dbus/ dep package=sugar-base/ dep package=sugar-toolkit/ dep package=sugar-artwork/ diff --git a/config/modulesets/glucose-versionsupport.modules b/config/modulesets/glucose-versionsupport.modules index a26c8a6..372ddc0 100644 --- a/config/modulesets/glucose-versionsupport.modules +++ b/config/modulesets/glucose-versionsupport.modules @@ -21,7 +21,6 @@ autotools id=sugar branch module=sugar/silbe.git revision=t/versions checkoutdir=sugar/ dependencies - dep package=GConf-dbus/ dep package=metacity/ dep package=python-xklavier/ dep package=sugar-base/ diff --git a/config/modulesets/glucose.modules b/config/modulesets/glucose.modules index 2a9a8ce..12c8171 100644 --- a/config/modulesets/glucose.modules +++ b/config/modulesets/glucose.modules @@ -21,7 +21,6 @@ autotools id=sugar branch module=sugar/mainline.git checkoutdir=sugar/ dependencies - dep package=GConf-dbus/ dep package=metacity/ dep package=python-xklavier/ dep package=sugar-base/ -- 1.7.2.2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
El Wed, 01-09-2010 a las 23:43 +0100, Marco Pesenti Gritti escribió: We agree that we should try out reviews on the mailing list, let's just do it. If Tomeu is ok with it, I'll repost some of my old patches to the list to get them reviewed and, hopefully, approved. To recap, the submission rules I propose are really simple: 1) On the submitter end: git commit -s git format-patch -1 git send-email --to maintainer --cc list foo.patch 2) Anyone who sees the patch can reply with inline comments Multiple reviews are welcome. 3) The reviewer can conclude the message with one of these tags: Acked-by: Joe Hacker jhac...@sugarlabs.org Reviewed-by: Joe Hacker jhac...@sugarlabs.org Tested-by: Joe Hacker jhac...@sugarlabs.org Only module maintainers and peers can ack a patch. The meaning of these tags should be already self-explanatory. In case someone has doubts, here's the full explanation: http://lxr.linux.no/linux/Documentation/SubmittingPatches 4) if submitter has write access to the repository, he/she amends the patch, appending any collected tags to it: git commit --amend git push (submitters with multiple patches in their queue may need to rebase or switch to a clean branch) 5) in case the patch closes a bug in Trac, submitter closes the bug mentioning the commit ID as usual Let's get started this way. If needed, we could refine the rules later on. To avoid confusion, I'd wait updating the documentation in the wiki until we've tested this new workflow for a while. If a maintainer cannot stand to approve patches submitted to the mailing-list, I'd ask them to state it clearly, so we don't needlessly disappoint submitters. If a submitter still prefers the old workflow, they can keep filing patches in the bug tracker as before. Agreed? I'm pretty confident we can setup and improve patchwork to help us tracking patch status reliably. I don't have a lot of time but I will commit to help out with both infrastructure and the reviews themselves. We've already had Patchwork on this list for a while: http://patchwork.sugarlabs.org/project/sugar/list/ It's a useful aid on the side, but I don't think it needs to get in the middle of the patch workflow. People are generally good at keeping track of threads in mailing list within their MUA. In case a patch gets overlooked by the maintainer, the submitter can resend it after a while. If even the submitter forgets, someone else could ping. If nobody cares to ping, it means that patch wasn't very interesting after all. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar broken in F14?
El Thu, 02-09-2010 a las 10:44 +0200, Tomeu Vizoso escribió: I'm testing daily the Sugar 0.90 packages that Peter (big thanks!) is doing on F14 and the tarballs that you see I'm making are intended to fix issues I find there. I'm still updating, but as of yesterday Sugar was starting correctly and I couldn't find any major issues. Still broken here. I have F14 fully updated, plus the Sugar packages from updates-testing. If I remove ~/.sugar, I get to see the color selection screen before Sugar dies. Do you have any other non-standard rpms installed? Any other environment tweaks? I alone won't find all the issues so if you (and others) can file the bugs you find, I will be able to fix them faster. I've already filed 2... one happened to be yet another GConf-dbus issue, the other one still stands: http://bugs.sugarlabs.org/ticket/2269 -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
Excerpts from Bernie Innocenti's message of Thu Sep 02 22:02:29 +0200 2010: 1) On the submitter end: git commit -s git format-patch -1 git send-email --to maintainer --cc list foo.patch Just one amendment: In case the patch closes a bug in Trac, submitter includes the ticket reference in the subject. E.g. keyboard cpsection: don't choke on option group (SL#2022) Otherwise +1. 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] Bug tracking Vs Patch review
The ticket must be closed in Trac when the code its commited? Gonzalo On Thu, Sep 2, 2010 at 5:46 PM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Bernie Innocenti's message of Thu Sep 02 22:02:29 +0200 2010: 1) On the submitter end: git commit -s git format-patch -1 git send-email --to maintainer --cc list foo.patch Just one amendment: In case the patch closes a bug in Trac, submitter includes the ticket reference in the subject. E.g. keyboard cpsection: don't choke on option group (SL#2022) Otherwise +1. 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 -- Gonzalo Odiard Responsable de Desarrollo (pasando la antorcha...) Sistemas Australes ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SUGAR_PROFILE feature, slimming down sugar-jhbuild (was: [PATCH] Make building GConf-dbus optional)
Excerpts from Bernie Innocenti's message of Thu Sep 02 19:27:59 +0200 2010: Compiling this module frequently breaks, resulting in difficulties for novice developers and waste of time for everyone else. The only reason I still haven't removed GConf-dbus is that I lack patches for the _documentation_, not the code. We explain how to use SUGAR_PROFILE to run multiple instances of Sugar in parallel, but not how to do the same using multiple OS-level user accounts. As soon as somebody updates the wiki with a good HowTo, I will kick GConf-dbus out of sugar-jhbuild with *delight*. :) In general any help with removing packages from sugar-jhbuild is welcome. A good starting point would be to create backports of the very latest Telepathy packages for the supported distros. 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] [olpc-nz] Twi translation
On Fri, September 3, 2010 9:32 am, Brenda Wallace wrote: We have 2 volunteers coming tomorrow who are fluent in Tagalog (and a half dozen other languages) - Where do i look to find status of translations for the Philippines? Is there someone I can co-ordinate with? Where can they help most? The status of all languages can be found at http://translate.sugarlabs.org/ If the language is not on the list there or a project is missing from a language, then it needs to be added by the administrators. We had most luck raising a ticket and then updating the ticket with requests for action when they weren't actioned. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
On 02.09.2010, at 23:28, Bert Freudenberg wrote: On 02.09.2010, at 22:46, Sascha Silbe wrote: Excerpts from Bernie Innocenti's message of Thu Sep 02 22:02:29 +0200 2010: 1) On the submitter end: git commit -s git format-patch -1 git send-email --to maintainer --cc list foo.patch Just one amendment: In case the patch closes a bug in Trac, submitter includes the ticket reference in the subject. E.g. keyboard cpsection: don't choke on option group (SL#2022) Otherwise +1. On Fedora 13, git-send-email is not requires by sugar-jhbuild. If this is the official way to submit patches, then git-email should be added to sysdeps. - Bert - Also, mail sent this way gets blocked, see below. I'll send it again using my regular mailer. - Bert - From mailer-dae...@fedora13.localdomain Thu Sep 2 23:37:17 2010 Return-Path: mailer-dae...@fedora13.localdomain Received: from localhost (localhost) by fedora13.localdomain (8.14.4/8.14.4) id o82LbHmW020736; Thu, 2 Sep 2010 23:37:17 +0200 Date: Thu, 2 Sep 2010 23:37:17 +0200 From: Mail Delivery Subsystem mailer-dae...@fedora13.localdomain Message-Id: 201009022137.o82lbhmw020...@fedora13.localdomain To: b...@fedora13.localdomain MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary=o82LbHmW020736.1283463437/fedora13.localdomain Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --o82LbHmW020736.1283463437/fedora13.localdomain The original message was received at Thu, 2 Sep 2010 23:37:04 +0200 from fedora13.localdomain [127.0.0.1] - The following addresses had permanent fatal errors - b...@freudenbergs.de (reason: 550 Dial-Up IP address rejected) sugar-devel@lists.sugarlabs.org (reason: 554 5.7.1 Service unavailable; Client host [77.184.213.183] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=77.184.213.183) sas...@silbe.org (reason: 517-Domain does not exist: fedora13.localdomain.) - Transcript of session follows - ... while talking to mailin.rzone.de.: DATA 550 Dial-Up IP address rejected 550 5.1.1 b...@freudenbergs.de... User unknown 554 5.0.0 no valid recipients given ... while talking to solarsail.sugarlabs.org.: DATA 554 5.7.1 Service unavailable; Client host [77.184.213.183] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=77.184.213.183 554 5.0.0 Service unavailable 554 5.5.1 Error: no valid recipients ... while talking to b.mx.chost.de.: MAIL From:b...@fedora13.localdomain SIZE=5977 517-Domain does not exist: fedora13.localdomain. 517 Invalid domain, see URL:ftp://ftp.isi.edu/in-notes/rfc1035.txt 554 5.0.0 Service unavailable --o82LbHmW020736.1283463437/fedora13.localdomain Content-Type: message/delivery-status Reporting-MTA: dns; fedora13.localdomain Received-From-MTA: DNS; fedora13.localdomain Arrival-Date: Thu, 2 Sep 2010 23:37:04 +0200 Final-Recipient: RFC822; b...@freudenbergs.de Action: failed Status: 5.1.1 Remote-MTA: DNS; mailin.rzone.de Diagnostic-Code: SMTP; 550 Dial-Up IP address rejected Last-Attempt-Date: Thu, 2 Sep 2010 23:37:05 +0200 Final-Recipient: RFC822; sugar-devel@lists.sugarlabs.org Action: failed Status: 5.7.1 Remote-MTA: DNS; solarsail.sugarlabs.org Diagnostic-Code: SMTP; 554 5.7.1 Service unavailable; Client host [77.184.213.183] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=77.184.213.183 Last-Attempt-Date: Thu, 2 Sep 2010 23:37:08 +0200 Final-Recipient: RFC822; sas...@silbe.org Action: failed Status: 5.0.0 Diagnostic-Code: SMTP; 517-Domain does not exist: fedora13.localdomain. Last-Attempt-Date: Thu, 2 Sep 2010 23:37:17 +0200 --o82LbHmW020736.1283463437/fedora13.localdomain Content-Type: message/rfc822 Return-Path: b...@fedora13.localdomain Received: from fedora13.localdomain (fedora13.localdomain [127.0.0.1]) by fedora13.localdomain (8.14.4/8.14.4) with ESMTP id o82Lb3mW020734; Thu, 2 Sep 2010 23:37:04 +0200 Received: (from b...@localhost) by fedora13.localdomain (8.14.4/8.14.4/Submit) id o82Lb1DR020733; Thu, 2 Sep 2010 23:37:01 +0200 From: Bert Freudenberg b...@freudenbergs.de To: sas...@silbe.org Cc: sugar-devel@lists.sugarlabs.org, Bert Freudenberg b...@freudenbergs.de Subject: [PATCH] Build Squeak VM 4.0.3 from tarfile Date: Thu, 2 Sep 2010 23:36:17 +0200 Message-Id: 1283463377-20677-1-git-send-email-b...@freudenbergs.de X-Mailer: git-send-email 1.7.2.2 This is almost the same as my patch from April, which never made it in. Instead of building from the outdated olpc subversion branch, the Squeak VM is build from a release tarball. It adds a cmake dependency, and gives an error if make is run without running autogen.sh first. Also adds a clean make target to please jhbuild. Signed-off-by: Bert Freudenberg b...@freudenbergs.de --- config/modulesets/glucose-external.modules | 15 +++-
[Sugar-devel] [PATCH] Build Squeak VM 4.0.3 from tarfile
This is almost the same as my patch from April, which never made it in.
Instead of building from the outdated olpc subversion branch, the Squeak VM
is build from a release tarball.
It adds a cmake dependency, and gives an error if make is run without running
autogen.sh first.
Also adds a clean make target to please jhbuild.
Signed-off-by: Bert Freudenberg b...@freudenbergs.de
---
config/modulesets/glucose-external.modules | 15 +++-
config/modulesets/patches/squeak-autogen.patch | 28 +++
config/modulesets/patches/squeak-makefile.patch | 11 +
config/sysdeps/debian-family.xml|1 +
config/sysdeps/fedora-family.xml|1 +
config/sysdeps/mandrivalinux-2009.1.xml |1 +
6 files changed, 51 insertions(+), 6 deletions(-)
create mode 100644 config/modulesets/patches/squeak-autogen.patch
create mode 100644 config/modulesets/patches/squeak-makefile.patch
diff --git a/config/modulesets/glucose-external.modules
b/config/modulesets/glucose-external.modules
index d76b1f0..0577963 100644
--- a/config/modulesets/glucose-external.modules
+++ b/config/modulesets/glucose-external.modules
@@ -5,8 +5,8 @@
href=git://dev.laptop.org/projects/ /
repository type=git name=git.gnome.org
href=git://git.gnome.org/
- repository type=svn name=squeakvm.org
-href=http://squeakvm.org/svn/squeak/branches/; trunk-template=olpc/
+ repository type=tarball name=squeakvm.org
+ href=http://squeakvm.org/unix/release//
repository type=git name=git.imendio.com
href=git://git.imendio.com/projects//
repository type=tarball name=telepathy
@@ -61,10 +61,13 @@
dep package=abiword/
/dependencies
/tarball
- autotools id=squeak
-branch repo=squeakvm.org module=olpc checkoutdir=squeak/
-dependencies
-/dependencies
+ autotools id=squeak autogen-template=/bin/sh autogen.sh
--prefix=%(prefix)s
+branch module=Squeak-4.0.3.2200-src.tar.gz version=4.0.3.2200
+ repo=squeakvm.org
+
hash=sha256:87cd3f708cb3d330f6d74931fd7488784f45b0f467f14e2dc6fbdc9d3df97189
size=3623094
+ patch file=squeak-autogen.patch strip=0 /
+ patch file=squeak-makefile.patch strip=0 /
+/branch
/autotools
autotools id=hulahop
branch module=hulahop/mainline.git checkoutdir=hulahop/
diff --git a/config/modulesets/patches/squeak-autogen.patch
b/config/modulesets/patches/squeak-autogen.patch
new file mode 100644
index 000..ff9274d
--- /dev/null
+++ b/config/modulesets/patches/squeak-autogen.patch
@@ -0,0 +1,28 @@
+--- /dev/null 2010-09-02 18:58:30.359785873 +0200
autogen.sh 2010-09-02 22:07:35.577316348 +0200
+@@ -0,0 +1,25 @@
++#!/bin/sh
++EXCLUDE=gl FileCopyPlugin SqueakFFIPrims B3DAcceleratorPlugin
PseudoTTYPlugin UnixOSProcessPlugin XDisplayControlPlugin
++
++test -d bld || mkdir bld
++
++OPTIONS=
++for p in $EXCLUDE ; do
++ OPTIONS=$OPTIONS --without-${p}
++done
++
++(cd bld ../unix/cmake/configure $OPTIONS $@)
++
++cat Makefile __EOF__
++default:
++ make -C bld
++
++install:
++ make -C bld install
++
++check:
++ @echo SKIPPED: No tests defined for Squeak VM
++
++clean:
++ rm -rf bld Makefile
++__EOF__
diff --git a/config/modulesets/patches/squeak-makefile.patch
b/config/modulesets/patches/squeak-makefile.patch
new file mode 100644
index 000..043dc7d
--- /dev/null
+++ b/config/modulesets/patches/squeak-makefile.patch
@@ -0,0 +1,11 @@
+--- Makefile.orig 2010-09-02 22:11:03.702191222 +0200
Makefile 2010-09-02 22:21:14.580177789 +0200
+@@ -1,7 +1,5 @@
+ all : .force
+- test -d bld || mkdir bld
+- (cd bld; ../unix/cmake/configure)
+- (cd bld; make)
++ @test -d bld || (echo ERROR: run autogen.sh first; exit 1)
+
+ install : all
+ (cd bld; make install)
diff --git a/config/sysdeps/debian-family.xml b/config/sysdeps/debian-family.xml
index ce11329..9870451 100644
--- a/config/sysdeps/debian-family.xml
+++ b/config/sysdeps/debian-family.xml
@@ -3,6 +3,7 @@
package name=automake1.9/
package name=avahi-daemon/
package name=avahi-autoipd/!-- for ad-hoc network support --
+ package name=cmake/
package name=evince/
package name=g++/
package name=gcc/
diff --git a/config/sysdeps/fedora-family.xml b/config/sysdeps/fedora-family.xml
index 83ec629..f97efb4 100644
--- a/config/sysdeps/fedora-family.xml
+++ b/config/sysdeps/fedora-family.xml
@@ -7,6 +7,7 @@
package name=avahi-tools source=avahi/
package name=avahi-autoipd/!-- for ad-hoc network support --
package name=boost-devel/
+ package name=cmake/
package name=csound/
package name=dbus-devel/
package name=dbus-glib-devel/
diff --git a/config/sysdeps/mandrivalinux-2009.1.xml
b/config/sysdeps/mandrivalinux-2009.1.xml
index 0acac46..7fa1131 100644
--- a/config/sysdeps/mandrivalinux-2009.1.xml
+++ b/config/sysdeps/mandrivalinux-2009.1.xml
@@ -9,6 +9,7 @@
package name=dbus-devel/
package name=dbus-glib-devel/
Re: [Sugar-devel] Bug tracking Vs Patch review
Sascha Silbe wrote: Bernie wrote: 1) On the submitter end: git commit -s git format-patch -1 git send-email --to maintainer --cc list foo.patch In case the patch closes a bug in Trac, submitter includes the ticket reference in the subject. keyboard cpsection: don't choke on option group (SL#2022) I'm in agreement with the proposal by Bernie and Sascha. Regarding how to identify maintainers' patch submission preferences, I suggest this could be added to a MAINTAINERS file in each repository. While this information may be redundant, it would help new developers, and would be maintained along with the source rather than in a separate place. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Patch review, combining/splitting modules (was: Re: Patch review)
On 2 Sep 2010, at 21:21, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: BTW, I've recently changed my mind on the repo-combining: We should work on splitting up our code, not combine it in a single repo. Our modules are too tightly coupled; sometimes even from foo import bar doesn't work (cyclic dependencies?). Let's factor out stuff like - Sugarised / improved widgets (most of sugar.graphics?) - API wrappers (e.g. sugar.datastore.datastore) - Activity framework and make them as self-contained as possible, with a layering approach. E.g. the activity framework would use the API wrappers, but the API wrappers would not depend (w.r.t. code) on anything else. The widgets also wouldn't depend on anything else; the Object Chooser widget should be in the Journal and the code to invoke it (currently sugar.graphics.objectchooser) should be in the API wrappers package. Splitting in different packages can be helpful to mark more strongly the separation between components, but it's neither necessary nor sufficient to ensure proper modularity and decoupling. Our codebase is so tiny... Dependencies can be expressed just fine by the directories structure, without having to pay the maintenance and complexity costs of a gazillions of small packages. As I gather from recent threads on sugar-devel Gnome will force some incompatibilities on us for Sugar 0.92 anyway, so now is a good time to do this split (as it will break API). It's definitely a very good time to cleanup our API. Improving modularity would be awesome but I disagree it requires splitting packages even more. My hope is that having a separate list might lower the barrier of posting to it. People might feel more comfortable about posting unfinished / hacky stuff if there's a dedicated list for it instead of getting exposed on the main list. I don't know if it actually is a problem currently, but it's worth a try. I would make damn sure we have a problem before considering to complicate processes and create new mailing lists because of it. Cheers, Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug tracking Vs Patch review
On 2 Sep 2010, at 21:02, Bernie Innocenti ber...@codewiz.org wrote: Let's get started this way. If needed, we could refine the rules later on. To avoid confusion, I'd wait updating the documentation in the wiki until we've tested this new workflow for a while. If a maintainer cannot stand to approve patches submitted to the mailing-list, I'd ask them to state it clearly, so we don't needlessly disappoint submitters. If a submitter still prefers the old workflow, they can keep filing patches in the bug tracker as before. Agreed? Sounds good to me. I would put the notes somewhere on the wiki as experimental/unofficial so that we can integrate improvements. I'm pretty confident we can setup and improve patchwork to help us tracking patch status reliably. I don't have a lot of time but I will commit to help out with both infrastructure and the reviews themselves. We've already had Patchwork on this list for a while: http://patchwork.sugarlabs.org/project/sugar/list/ It's a useful aid on the side, but I don't think it needs to get in the middle of the patch workflow. People are generally good at keeping track of threads in mailing list within their MUA. Some people are, some are less, included our most active maintainer :) I think we agree about patchwork being an additional tool anyway. In case a patch gets overlooked by the maintainer, the submitter can resend it after a while. If even the submitter forgets, someone else could ping. If nobody cares to ping, it means that patch wasn't very interesting after all. This is a bit simplistic. The submitter might just think we don't care and stop submitting patches. Let's forget about that for now though, we need to make this work well for the existing contributors before we even start thinking about involving more. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
