users December 2011

users@lists.genode.org

14 participants
15 discussions

Re: Proposal for issue tracking
by Julian Stecklina 19 Dec '11

19 Dec '11

Hello, just wanted to say that I only had good experiences so far with github, albeit with rather small codebases compared to Genode. Are there any other popular medium to large projects using github? Julian (Sorry for top posting, posting from phone) Christian Helmuth <christian.helmuth@...1...> schrieb: >Hello everyone, > >we're now walking the open path. Therefore, I want to discuss my ideas >about the future issue-tracking process of Genode here on the list. > > >The challenge > >The current "process" of handling issues is rather pragmatic and >little transparent for the community. Most issues are reported and >discussed on this mailing list. Hence, reports are mostly unstructured >and difficult to track. At Genode Labs, we maintain a private tracker >for our projects partially of interest for the Genode community. So, >the first step (as Norman already wrote) is to migrate these issues >into a publicly accessible tracker. > >Furthermore, issues have some quirks to keep in mind when deciding >upon on a tracking process. First, apparently resolved issues may rise >from grave and it's precious to have their history at hand to fight >them back. Also, the resolution of closed issues should be accessible >in the code repository to know when and how it works. Sometimes it's >also good to find out who fixed the issue and, thus, have a contact >for further questions. Finally, a well maintained issue database >reflects the current stage and activity of the project, assists >contributors to get started, and reflects which missing features are >already in the back of our minds. > >We decided to go for a public Git-based repository for Genode sources >and, so, it is natural to go for an open collaboration model. Two >widely used models are the "Fork + pull-request model" and patch-based >integration. IMO both should be supported. > >In the following, I will now and then evaluate features available from >GitHub to our requirements. We did not finally choose GitHub but I >must admit I'm a strong proponent of this platform. > > >Reporting an issue > >We definitely need a simple guide on "How to report an issue" to avoid >the tedious question-and-answer game. My proposal is: > >1. Summarize important information of your issue in the _title_. >2. Start the _body_ with steps to reproduce it. Name the affected > version/commit. >3. Sketch the expected behaviour. >4. Detail what happened instead. > > >The life cycle of an issue > >After the issue was reported it will undergo a life cycle until it's >eventually closed. Each life stage depends on the issue type and the >steps taken to resolve it. The important issue types I identified are >_bug_, _feature_, and _documentation_. The issue type should be marked >in the tracker and may be used for filtering/sorting. > >If someone works on a reported issue, he may want to submit a fix as >_patch_ or as _pull_ request. Pull request should come from a >persistent topic branch in a fork of the main repository. So, the >issue and its history can be tracked in the future. The fact of a >submitted fix shall also be marked in the tracker. Moreover, >discussions upon an issue should be attached to the issue in the >tracker. > >Eventually, a decision on the issue will be reached, which can be that >a _fix_ was accepted or incorporated, the issue was identified as a >_duplicate_ of an older issue filed, or the issue was _rejected_ by >some cause. If the issue revives it may be reopened and the cycle >starts over. > >Some optional features I did not investigate further, but that may >become useful are: assignment to team members, tagging an affected >release version, and an urgency marker. > > >Does it work every day with GitHub? > >To get hands-on with the issue tracking I added a playground >repository to my GitHub account. The associated issue tracker can be >found under > > https://github.com/chelmuth/playground/issues > >I added _tags_ to mark all the information mentioned before. > >The integration of Git and the GitHub platform is quite good. Issues >can be referenced in discussion threads of other issues as well as in >commit messages via '#<issue number>', e.g., #1. Issues also have >their own URL, e.g., > > https://github.com/chelmuth/playground/issues/4 > >Issues even can be closed from commit messages. The committer just >adds a recognizable text, e.g., 'Fixes #3'. For more information have >a look at > > https://github.com/blog/831-issues-2-0-the-next-generation > >Another interesting feature is the reference of other developers on >GitHub via '@<username>', e.g. @chelmuth. Hence, the involvement of >potential contributors into the discussion is straightforward. > >Finally, GitHub provides (on the web and via the 'hub' tool [1]) >excellent integration of the fork+pull collaboration model. This >feature is described in detail at > > http://help.github.com/send-pull-requests/ > >The idea of handling pull requests like issues including a discussion >thread is great. > > >I'm looking forward to your feedback. > >[1] http://defunkt.io/hub/ > >Kind regards >-- >Christian Helmuth >Genode Labs > >http://www.genode-labs.com/ · http://genode.org/ · /ˈdʒiː.nəʊd/ > >Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden >Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth > >------------------------------------------------------------------------------ >Learn Windows Azure Live! Tuesday, Dec 13, 2011 >Microsoft is holding a special Learn Windows Azure training event for >developers. It will provide a great way to learn Windows Azure and what it >provides. You can attend the event by watching it streamed LIVE online. >Learn more at http://p.sf.net/sfu/ms-windowsazure >_______________________________________________ >Genode-main mailing list >Genode-main(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/genode-main

4 5

Proposal for issue tracking
by Christian Helmuth 16 Dec '11

16 Dec '11

Hello everyone, we're now walking the open path. Therefore, I want to discuss my ideas about the future issue-tracking process of Genode here on the list. The challenge The current "process" of handling issues is rather pragmatic and little transparent for the community. Most issues are reported and discussed on this mailing list. Hence, reports are mostly unstructured and difficult to track. At Genode Labs, we maintain a private tracker for our projects partially of interest for the Genode community. So, the first step (as Norman already wrote) is to migrate these issues into a publicly accessible tracker. Furthermore, issues have some quirks to keep in mind when deciding upon on a tracking process. First, apparently resolved issues may rise from grave and it's precious to have their history at hand to fight them back. Also, the resolution of closed issues should be accessible in the code repository to know when and how it works. Sometimes it's also good to find out who fixed the issue and, thus, have a contact for further questions. Finally, a well maintained issue database reflects the current stage and activity of the project, assists contributors to get started, and reflects which missing features are already in the back of our minds. We decided to go for a public Git-based repository for Genode sources and, so, it is natural to go for an open collaboration model. Two widely used models are the "Fork + pull-request model" and patch-based integration. IMO both should be supported. In the following, I will now and then evaluate features available from GitHub to our requirements. We did not finally choose GitHub but I must admit I'm a strong proponent of this platform. Reporting an issue We definitely need a simple guide on "How to report an issue" to avoid the tedious question-and-answer game. My proposal is: 1. Summarize important information of your issue in the _title_. 2. Start the _body_ with steps to reproduce it. Name the affected version/commit. 3. Sketch the expected behaviour. 4. Detail what happened instead. The life cycle of an issue After the issue was reported it will undergo a life cycle until it's eventually closed. Each life stage depends on the issue type and the steps taken to resolve it. The important issue types I identified are _bug_, _feature_, and _documentation_. The issue type should be marked in the tracker and may be used for filtering/sorting. If someone works on a reported issue, he may want to submit a fix as _patch_ or as _pull_ request. Pull request should come from a persistent topic branch in a fork of the main repository. So, the issue and its history can be tracked in the future. The fact of a submitted fix shall also be marked in the tracker. Moreover, discussions upon an issue should be attached to the issue in the tracker. Eventually, a decision on the issue will be reached, which can be that a _fix_ was accepted or incorporated, the issue was identified as a _duplicate_ of an older issue filed, or the issue was _rejected_ by some cause. If the issue revives it may be reopened and the cycle starts over. Some optional features I did not investigate further, but that may become useful are: assignment to team members, tagging an affected release version, and an urgency marker. Does it work every day with GitHub? To get hands-on with the issue tracking I added a playground repository to my GitHub account. The associated issue tracker can be found under https://github.com/chelmuth/playground/issues I added _tags_ to mark all the information mentioned before. The integration of Git and the GitHub platform is quite good. Issues can be referenced in discussion threads of other issues as well as in commit messages via '#<issue number>', e.g., #1. Issues also have their own URL, e.g., https://github.com/chelmuth/playground/issues/4 Issues even can be closed from commit messages. The committer just adds a recognizable text, e.g., 'Fixes #3'. For more information have a look at https://github.com/blog/831-issues-2-0-the-next-generation Another interesting feature is the reference of other developers on GitHub via '@<username>', e.g. @chelmuth. Hence, the involvement of potential contributors into the discussion is straightforward. Finally, GitHub provides (on the web and via the 'hub' tool [1]) excellent integration of the fork+pull collaboration model. This feature is described in detail at http://help.github.com/send-pull-requests/ The idea of handling pull requests like issues including a discussion thread is great. I'm looking forward to your feedback. [1] http://defunkt.io/hub/ Kind regards -- Christian Helmuth Genode Labs http://www.genode-labs.com/ · http://genode.org/ · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 2

Session object pool
by Александр Домо 08 Dec '11

08 Dec '11

Hello! I'm writing a server application which acts as a communicator between it's clients. Each of my sessions needs to know about other active sessions, so what I'd like to know is if there is a way to access the session object pool directly, or should I maintain my own list of running sessions? Also, a question about "doing it the right way". I transfer data chunks (not more than several Kbytes) to/from clients using RPC calls (initiated by clients), and I use Signal_transmitter objects to notify clients about data & other stuff. Is that normal? ;) Thanks! A.D.

2 2

lwIP port to Genode - lwip_recv()
by Amadeo Casas Cuadrado 07 Dec '11

07 Dec '11

Hello, Question about the lwIP port to Genode. Is it possible to receive a large amount of data with lwip_recv()? A quick test shows me the maximum amount of data that is received is 1460 bytes (properly matching TCP_MSS in lwipopts.h). What if I am expecting a larger amount of data? Do I need to perform the defragmentation explicitly in my program? My apologies beforehand for posting to this list if this is a limitation of lwIP stack, and not of its port to Genode. Thanks, Amadeo

2 2

Steps towards an open development process
by Norman Feske 07 Dec '11

07 Dec '11

Hello everyone, over the past four years, the Genode OS Framework has seen rapid progress. Skimming over the release notes of the past releases makes me very proud. It is clear that the project's development is going stronger than ever. However, at the same time, I recognize that progress on a technical level is only one part of a successful Open-Source project. A certainly even more important part is the participation of a diverse community. This is where our project is vastly underdeveloped. By continuing the development at status quo, Genode will continue to steadily improve but it will not be able to capture a significant position in the operating-systems world. Instead, it will possibly remain a curiosity. Therefore, we Genode developers regard the transition of our work to an open and transparent development process as the next big challenge we want to tackle. Review of the situation Even though Genode is an Open-Source project, its development has been pursued largely behind the closed doors of our company Genode Labs. The planning of the road map, most technical discussions, issue tracking, and revision management were used to be done within the company. There had been two reasons for this policy namely the preservation of exclusivity and the efficiency of coordination. Regarding the first reason, when we started our business, we desired to preserve a certain degree of competitive advantage to ourselves by keeping some information "protected" from the public eye. For example, we thought that revealing the detailed history of the over 5000 source-code revisions of the project would enable any outsider or competitor to deeply analyze the way of how our company works. These concerns had been acknowledged by other startup companies with statements in the line of "Open-Source has hurt our business". The second reason is the way of how humans intuitively work together in a non-distributed environment such as a our small company. Instead of discussing technical matters on a mailing list, it appears to be much easier and presumably more efficient to engage in face-to-face conversations. The writeup of our releases notes at regular intervals served us as an instrument to recapture the rationale behind our discussions and document it. This worked exceedingly well. In comparison, discussing every detail on a mailing list seems to be inconvenient and long-winding. Why do we desire a change? The answer to this question can be put quite simply as "to make the project relevant". But it goes deeper than that. First, we see ourself as Free-Software AND Open-Source advocates. I wholeheartedly disagree with statements that suggest that Open Source is incompatible with having a business. For our company, the contrary is true. Without Free and Open-Source Software, there would be no Genode Labs. The great wealth of the GNU software stack forms the basis of all the tools we use every day and it plays a significant role for our passion to develop software. Furthermore, Genode would not be of much value without all the great building blocks in the form of existing Open-Source code that we reuse in our context. Hence, it is our personal desire to contribute to the Free and Open-Source software world and to intensify the collaboration with other projects in the same spirit. We still see the preservation of a certain degree of exclusivity as important for our dual-licensing business model. If we made Genode available under the BSD license, there would be not point in pursuing this model. However, hiding the development process from the public is not only poor-spirited but it creates an artificial barrier for people who want to participate. The book "Producing Open Source Software" (http://producingoss.com) by Karl Fogel was an eye opener to us. Regarding the efficiency of collaboration, I have to admit that the statement above about how great the current way works is really not well-founded - simply because we haven't tried the alternative to discuss everything in public, yet. Obviously, we are risking to spoil our presumed efficiency by changing the mode of collaboration. On the other hand, by documenting the process of solving each problem in the form of public mailing-list postings, we give everyone the chance to contribute to and to learn from our findings. Reaching people outside of Genode Labs is the only way to make our project relevant on a larger scale. The next steps We take the current release cycle as opportunity to execute our plan to open the development process. Our coarse schedule is to migrate our internal issue tracker to the public until mid of December. From this day on, all issues will be tracked publicly. The place for all technical discussions will be the Genode mailing list. Until mid of January, we will prepare a new public source tree in the form of a Git repository that we will then use as mainline development tree. There will be no distinction between our development repository and the public repository anymore. As a further change of policy, we plan to include all documentation as found on the website in the mainline repository and remove the Wiki. This way, contributions to the documentation will be handled in the same fashion as code contributions. Hoping that our designated change is in the interest of all of you, I'm looking forward to see how it will unfold and improve the further progress of Genode. Best regards Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users December 2011