Re: community involvement todo?
Hello. On Fri, 2007-06-08 at 02:41, Philippe De Swert wrote: So I would like to propose a todo list on the wiki. This should list a number of tasks which people can take up with a short explanation of what has to be done and what is expected. We already had some thoughts about such 'junior tasks'. I really like the idea to give interested people small tasks for a quick start. The real problem is to identify such tasks. Most of the stuff is still much work in progress. We should start such a list anyway. :) I'll see if I come up with some ideas in the next days. This coupled to a seperate email address or mailing list. After which the devs can add the patches I would vote against another ml. We already have enough. Just send the patch to the ml for the stuff you are hacking on: u-boot, kernel, application... Alternatively we can make sure that more bugs are filed in bugzilla with detailed explanations. This is of course always a godd idea. :) Any comments? People willing to take up co-ordinating, devs willing to check this out, ...? Please start the page in the wiki. You guys can already write down some tasks and I'll poke my colleagues to add some more. regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community involvement todo?
Stefan Schmidt wrote: We already had some thoughts about such 'junior tasks'. I really like the idea to give interested people small tasks for a quick start. Regarding quick starts, perhaps some sort of tutorial could be useful, e.g. - how to get the basic development/run-time environment - how to set up QEMU - how to add/change things to/in the run-time environment - step-by-step description for building a graphical hello world application (code layout, widgets, build process, packaging) - pointers to reference code for the most important widgets and/or use of infrastructure interfaces The real problem is to identify such tasks. Most of the stuff is still much work in progress. We should start such a list anyway. :) One problem is also that many small tasks involve a lot of context. So it's two weeks of learning, five minutes of coding, and even then you probably don't do it quite right. Of course, once the learning curve is mastered, things improve significantly. An example for an a bit meatier project, without too many dependencies may be the implementation of a working prototype of the finger splash input method: http://www.micropp.se/openmoko/ An example for a project with lots of cross-dependencies would be a cleanup of the u-boot build process. It would be great if the build process was non-verbose by default, like we have it for the Linux kernel. If anyone wants to tackle this, the best starting point would be u-boot upstream (and synchronize with the upstream developers). A build infrastructure idea: it would be great if BitBake would support entire quilt patchsets, e.g., by pointing to the series file. (Stefan, see yesterday's discussion on #openmoko-devel.) I would vote against another ml. We already have enough. Just send the patch to the ml for the stuff you are hacking on: u-boot, kernel, application... For reasonably self-contained small projects, we also have projects.openmoko.org - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community involvement todo?
Hello. On Fri, 2007-06-08 at 07:01, Werner Almesberger wrote: Stefan Schmidt wrote: We already had some thoughts about such 'junior tasks'. I really like the idea to give interested people small tasks for a quick start. Regarding quick starts, perhaps some sort of tutorial could be useful, e.g. - how to get the basic development/run-time environment - how to set up QEMU Should be both in the wiki already, no? - how to add/change things to/in the run-time environment Hmm, do you mean before the buil with OE or working on the live system? - step-by-step description for building a graphical hello world application (code layout, widgets, build process, packaging) - pointers to reference code for the most important widgets and/or use of infrastructure interfaces That's indeed a big missing point. On the other hand two projects already found it way in our tree, rss-reader and calculator, which means it seems possible to learn how it works. ;) Anyway we should fill this gap even if I don't know when we have time for this. :( The real problem is to identify such tasks. Most of the stuff is still much work in progress. We should start such a list anyway. :) One problem is also that many small tasks involve a lot of context. So it's two weeks of learning, five minutes of coding, and even then you probably don't do it quite right. Of course, once the learning curve is mastered, things improve significantly. Good point. [Examples] So the wiki page should have the following for every single task: Description, needed skills, links to reference code... If nobody beat me, *hint*, I'll add these tasks and perhaps some more to the wiki tonight. regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community involvement todo?
Stefan Schmidt wrote: Should be both in the wiki already, no? Yup, so the walk-through should just explain the easiest approach, and link to the more detailed background material for the rest. E.g., the QEMU part doesn't need all the background information from the QEMU page. Trimming the MokoMakeFile information may be a bit harder. - how to add/change things to/in the run-time environment Hmm, do you mean before the buil with OE or working on the live system? Pick one :-) The idea is to give an answer to how do I run my application on QEMU or my Neo, for testing. There are many possible answers. The getting started guide should give one that's reasonably efficient and reasonably fool-proof. That's indeed a big missing point. On the other hand two projects already found it way in our tree, rss-reader and calculator, which means it seems possible to learn how it works. ;) Yeah, but this should be really easy. Most beginners won't care to understand all the fine points of our build process, at least not initially. Anyway we should fill this gap even if I don't know when we have time for this. :( Perhaps this makes that one more item for the contributions we'd appreciate list. People who have gone through a certain learning experience recently are usually in the best position to describe it. Any bugs/inefficiencies can be filtered out through peer review. [ Tautology deleted ], I'll add these tasks and perhaps some more to the wiki tonight. Great ! :-) - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community involvement todo?
On 6/8/07, Stefan Schmidt [EMAIL PROTECTED] wrote: Hello. So the wiki page should have the following for every single task: Description, needed skills, links to reference code... If nobody beat me, *hint*, I'll add these tasks and perhaps some more to the wiki tonight. regards Stefan Schmidt Are we really suggesting that we manually maintain one set of information about all the tasks on the wiki, and another on the bugtracker? In my experience, it's hard enough to keep devs (myself included) documenting properly, and now we want to double the workload? What it seems you're saying is that the bugtracker isn't working for you, that's cool, but every red flag I have goes up when you're suggesting we duplicate the functionality across multiple systems. Looking at the bugtracker, I can see how it would be pretty daunting to start out, but I really think it would be a better call to fix that than try to keep them synchronized. I think doing anything more than keeping a list of possible first bugs on the wiki is just asking for trouble, but what do the rest of you think we could do to make the bug reports easier to get started on? -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
