Re: [oi-dev] Lets talk about Git
I like the idea but I'm not sure how you'd go about setting something like that up. How would you ensure both repositories are kept in sync? The usual method as I understand it is to have one repository as the master and the rest as mirrors but this doesn't allow you to commit to the mirrors so they're not really equal. From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Sun, 12 Feb 2012 15:10:39 + To: OpenIndiana Developer mailing list oi-dev@openindiana.org Subject: Re: [oi-dev] Lets talk about Git I recall the discussion developing along the lines of co-existence and agnosticism between git and hg, not conversion per se. On Sun, Feb 12, 2012 at 2:49 PM, Andrew Stormont andyjstorm...@gmail.com wrote: Hi all, At the Illumos meetup in Brussels it was proposed that we migrate illumos-userland to GitHub. There were several good reasons for making the switch but the two main ones were: git is faster (because most of it is written in C) and git is more popular (which hopefully means there are more people familiar with it). I would like us to add this to the agenda for the next #oi-meeting and in the mean time please feel free to reply with your thoughts/opinions about switching to git. Thanks, Andrew ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
When the subject came up on IRC last week, I went ahead and registered the organization OpenIndiana on Github. Whether it goes under that organization, or as a team under the Illumos organization, makes no difference to me. -M On Feb 12, 2012, at 9:49 AM, Andrew Stormont wrote: Hi all, At the Illumos meetup in Brussels it was proposed that we migrate illumos-userland to GitHub. There were several good reasons for making the switch but the two main ones were: git is faster (because most of it is written in C) and git is more popular (which hopefully means there are more people familiar with it). I would like us to add this to the agenda for the next #oi-meeting and in the mean time please feel free to reply with your thoughts/opinions about switching to git. Thanks, Andrew ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Hi Andrew, Andrew Stormont píše v ne 12. 02. 2012 v 14:49 +: Hi all, At the Illumos meetup in Brussels it was proposed that we migrate illumos-userland to GitHub. There were several good reasons for making the switch but the two main ones were: git is faster (because most of it is written in C) and git is more popular (which hopefully means there are more people familiar with it). is it really faster on Illumos? How did you measure that? And about familiarity - shouldn't it be more about usability/simplicity? I would like us to add this to the agenda for the next #oi-meeting and in the mean time please feel free to reply with your thoughts/opinions about switching to git. Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Andy, I'd think we could use the same tools that illumos uses to mirror from their authoritative repo to BitBucket and GitHub. I'd expect there are two non-exclusive ways to approach mirroring: you can add hooks to the canonical repo that cause it to push to the DVCS hubs as part of the commit, or you can have a looser consistency sync with cron, which could catch you up if a sync on canonical commit fails. I think most of the case for git is a case for co-existence. People potentially interested in OI but not previously involved in OpenSolaris are more likely to know git than mercurial, so not having git available is a potential limit for people who aren't sure the project is so cool they want to bother with a first step that's a new tool. For existing developers, there's not enough differentiation between the two that people necessarily want to commit the time to learning how to use git properly because they doubt it will ever save them a comparable amount. I think both sides are right, which is why I favor allowing both. The significant complication between how we approach DVCS and the way illumos does it is that RTI limits the number of commiters. Ideally I'd prefer to be able to take commits via DVCS pull requests and a bit of workflow, which is something else we talked about at the meetup. I also think this makes the commit process a bit less daunting. I've done some research and feel I've got a decent grasp on what we'd need to do to make this work, and you said you had some previous experience with the APIs that you could contribute to getting it to work. How about we put our heads together around the next meeting and sort this out? Cheers, Bayard On Sun, Feb 12, 2012 at 3:28 PM, Andrew Stormont andyjstorm...@gmail.comwrote: I like the idea but I'm not sure how you'd go about setting something like that up. How would you ensure both repositories are kept in sync? The usual method as I understand it is to have one repository as the master and the rest as mirrors – but this doesn't allow you to commit to the mirrors – so they're not really equal. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
2012/2/12 Andrew Stormont andyjstorm...@gmail.com On 12/02/2012 16:06, Milan Jurik milan.ju...@xylab.cz wrote: And about familiarity - shouldn't it be more about usability/simplicity? Hi, Hopefully this will answer your questions http://whygitisbetterthanx.com/# Avert your eyes, children, the bikeshed may assume other forms! The three differentiators with hg are marginal and can in any case be equalized with bookmarks (cheap local branching, which is probably least applicable to us), cadmium (staging area), and BitBucket (GitHub). Again, I think there are enough strengths to both to argue for enabling both (even if there's a cost to that), and I think the strongest thing git has going for it isn't on the list: all the cool kids already know it. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Sun, 12 Feb 2012 17:20:33 + To: OpenIndiana Developer mailing list oi-dev@openindiana.org Subject: Re: [oi-dev] Lets talk about Git 2012/2/12 Andrew Stormont andyjstorm...@gmail.com On 12/02/2012 16:06, Milan Jurik milan.ju...@xylab.cz wrote: And about familiarity - shouldn't it be more about usability/simplicity? Hi, Hopefully this will answer your questions http://whygitisbetterthanx.com/# Avert your eyes, children, the bikeshed may assume other forms! The three differentiators with hg are marginal and can in any case be equalized with bookmarks (cheap local branching, which is probably least applicable to us), cadmium (staging area), and BitBucket (GitHub). Again, I think there are enough strengths to both to argue for enabling both (even if there's a cost to that), and I think the strongest thing git has going for it isn't on the list: all the cool kids already know it. I just want to say straightaway that I apologise. My intention is not to start a flamewar or bike shedding but to merely show that there are benefits to offering git as an alternative to mercurial. I'm sure if the URL was 'whygitisagoodalternativetox.com' I wouldn't need to have to clarify this ;) Andrew ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Hi, Andrew Stormont píše v ne 12. 02. 2012 v 17:13 +: On 12/02/2012 16:06, Milan Jurik milan.ju...@xylab.cz wrote: Hi Andrew, Andrew Stormont píše v ne 12. 02. 2012 v 14:49 +: Hi all, At the Illumos meetup in Brussels it was proposed that we migrate illumos-userland to GitHub. There were several good reasons for making the switch but the two main ones were: git is faster (because most of it is written in C) and git is more popular (which hopefully means there are more people familiar with it). is it really faster on Illumos? How did you measure that? And about familiarity - shouldn't it be more about usability/simplicity? Hi, Hopefully this will answer your questions http://whygitisbetterthanx.com/# no, it speaks about testing one project on one platform :-) Additionally - why should we have the 3rd different rcs for consolidations needed for 1 distro? I believe 2 are enough. Btw. how is status of cadmium features on git? Like recommit? All I see from this is that git is finally learning from others how to be user-friendly. Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
On 02/12/12 09:29 AM, Milan Jurik wrote: Btw. how is status of cadmium features on git? Like recommit? git rebase is far more powerful useful than cadmium recommit, especially once you learn git rebase --interactive. The cadmium features that are missing from git are the ones more specific to the opensolaris project, such as webrev integration and checking project policy (nits, pbchk, etc.). -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Hi Alan, Alan Coopersmith píše v ne 12. 02. 2012 v 10:01 -0800: On 02/12/12 09:29 AM, Milan Jurik wrote: Btw. how is status of cadmium features on git? Like recommit? git rebase is far more powerful useful than cadmium recommit, especially once you learn git rebase --interactive. I know rebase is very powerfull but as recommit is key part of the process, rebase power is also danger. recommit is simple enough to be nearly 100% safe to use by everybody. The cadmium features that are missing from git are the ones more specific to the opensolaris project, such as webrev integration and checking project policy (nits, pbchk, etc.). I think there is support for git in webrev in queue. pbchk support probably not yet. Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
richlowe's been working on both, but neither are in use with OI. My preference for all of this functionality would be to have the validation done by the pull request. Webrevs could be generated automatically, and the applicable nits would give feedback requesting either that they be resolved for a subsequent pull or by providing quick notes or tick boxes to explain why they aren't strictly necessary. You're provided an issue tracker ID for the submit request, and that tracks these kinds of things and is responsible for generating the webrev and sending out the review mail once issues immediately applicable to the submission are resolved. Workflow would also be responsible for checking CI build and test status as a prereq. An issue tracker could used to provide all the workflow state, but if that's too clunky (or the issue tracker too unreliable), it could be put into a database. That's my cocktail napkin sketch of workflow (or at least the basics--there are other pieces I have in mind), which fuses some stuff I talked about at the illumos hackathon with the floor discussion on the contribution process we had at FOSDEM. On Sun, Feb 12, 2012 at 6:27 PM, Milan Jurik milan.ju...@xylab.cz wrote: Hi Alan, Alan Coopersmith píše v ne 12. 02. 2012 v 10:01 -0800: On 02/12/12 09:29 AM, Milan Jurik wrote: Btw. how is status of cadmium features on git? Like recommit? git rebase is far more powerful useful than cadmium recommit, especially once you learn git rebase --interactive. I know rebase is very powerfull but as recommit is key part of the process, rebase power is also danger. recommit is simple enough to be nearly 100% safe to use by everybody. The cadmium features that are missing from git are the ones more specific to the opensolaris project, such as webrev integration and checking project policy (nits, pbchk, etc.). I think there is support for git in webrev in queue. pbchk support probably not yet. Best regards, Milan ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Well I guess if we were to slightly modify the new integration process we discussed at Brussels we could achieve this quite easily: Developer pushes to Bit Bucket or Git Hub - Changeset is intercepted and passed to Jenkins for testing - Build completes successfully and changeset is pushed to master repo (illumos.org) - Sync of Bit Bucket and Git Hub repos is triggered. Andrew From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Sun, 12 Feb 2012 17:40:32 + To: OpenIndiana Developer mailing list oi-dev@openindiana.org Subject: Re: [oi-dev] Lets talk about Git On Sun, Feb 12, 2012 at 5:25 PM, Andrew Stormont andyjstorm...@gmail.com wrote: I just want to say straightaway that I apologise. My intention is not to start a flamewar or bike shedding but to merely show that there are benefits to offering git as an alternative to mercurial. I'm sure if the URL was 'whygitisagoodalternativetox.com http://whygitisagoodalternativetox.com ' I wouldn't need to have to clarify this ;) No need to apologize, my response was meant to be tongue-in-cheek, not trying to escalate this, just to warn that it becomes a bikeshed if we have to choose between the two, which is preferable to avoid. I'm pretty comfortable that we have a reasonable grasp on how to put together a technical solution to co-existence with complete parity. I'd pretty excited about the prospect of working with you to make sure that happens. I don't think we should keep hg around because it's the best in some absolute sense, I think we should keep it around because it's adequate to our needs and conversion requires cat-herding of existing developers that's best avoided. We should maintain perspective: git has momentum and a very large user base because plenty of people do agree that git is better than the alternatives, and we need to respect that by letting people who like it continue to use it. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Sounds about right to me. The other bits we'd need to sort out as per Brussels is some kind of permissioning for established contributors. This would be something like being granted the Developer role for illumos-userland in Redmine and providing the same ssh key both for your Redmine registration and your DVCS hub account (no other ssh keys allowed, such that this confirms that no one is being clever by registering one public key for impersonation and using another to push, although I suppose there might remain a possible time of use/time of check attack). I think it would still be good to have automatically generated webrev generated for everything that clears Jenkins, with a further list mailed for all submissions requiring review. In the context of CI, I think we should have some kind of dependency graph triggered so that any packages that are dependent on the package being changed are also automatically rebuilt and tested, which particularly helps us for components that may not have their own test suites. On Sun, Feb 12, 2012 at 6:44 PM, Andrew Stormont andyjstorm...@gmail.comwrote: Well I guess if we were to slightly modify the new integration process we discussed at Brussels we could achieve this quite easily: Developer pushes to Bit Bucket or Git Hub - Changeset is intercepted and passed to Jenkins for testing - Build completes successfully and changeset is pushed to master repo (illumos.org) - Sync of Bit Bucket and Git Hub repos is triggered. Andrew From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Sun, 12 Feb 2012 17:40:32 + To: OpenIndiana Developer mailing list oi-dev@openindiana.org Subject: Re: [oi-dev] Lets talk about Git On Sun, Feb 12, 2012 at 5:25 PM, Andrew Stormont andyjstorm...@gmail.comwrote: I just want to say straightaway that I apologise. My intention is not to start a flamewar or bike shedding but to merely show that there are benefits to offering git as an alternative to mercurial. I'm sure if the URL was 'whygitisagoodalternativetox.com' I wouldn't need to have to clarify this ;) No need to apologize, my response was meant to be tongue-in-cheek, not trying to escalate this, just to warn that it becomes a bikeshed if we have to choose between the two, which is preferable to avoid. I'm pretty comfortable that we have a reasonable grasp on how to put together a technical solution to co-existence with complete parity. I'd pretty excited about the prospect of working with you to make sure that happens. I don't think we should keep hg around because it's the best in some absolute sense, I think we should keep it around because it's adequate to our needs and conversion requires cat-herding of existing developers that's best avoided. We should maintain perspective: git has momentum and a very large user base because plenty of people do agree that git is better than the alternatives, and we need to respect that by letting people who like it continue to use it. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Hi, regarding the git vs mercurial part I have one suggestion. There is a project, which enables pushing using mercurial client into git repositories. Project is called hg-git (http://hg-git.github.com/). One has to install it and enable it in hgrc. After he has done one, he can commit to git repositories. From my point of view, it is not hard to deploy. However, it all depends on developers if they are willing to do so. This should also be settled down during the next oi-meeting as was proposed. Adam On Feb 12, 2012, at 7:59 PM, Bayard Bell wrote: Sounds about right to me. The other bits we'd need to sort out as per Brussels is some kind of permissioning for established contributors. This would be something like being granted the Developer role for illumos-userland in Redmine and providing the same ssh key both for your Redmine registration and your DVCS hub account (no other ssh keys allowed, such that this confirms that no one is being clever by registering one public key for impersonation and using another to push, although I suppose there might remain a possible time of use/time of check attack). I think it would still be good to have automatically generated webrev generated for everything that clears Jenkins, with a further list mailed for all submissions requiring review. In the context of CI, I think we should have some kind of dependency graph triggered so that any packages that are dependent on the package being changed are also automatically rebuilt and tested, which particularly helps us for components that may not have their own test suites. On Sun, Feb 12, 2012 at 6:44 PM, Andrew Stormont andyjstorm...@gmail.com wrote: Well I guess if we were to slightly modify the new integration process we discussed at Brussels we could achieve this quite easily: Developer pushes to Bit Bucket or Git Hub - Changeset is intercepted and passed to Jenkins for testing - Build completes successfully and changeset is pushed to master repo (illumos.org) - Sync of Bit Bucket and Git Hub repos is triggered. Andrew From: Bayard Bell buffer.g.overf...@gmail.com Reply-To: OpenIndiana Developer mailing list oi-dev@openindiana.org Date: Sun, 12 Feb 2012 17:40:32 + To: OpenIndiana Developer mailing list oi-dev@openindiana.org Subject: Re: [oi-dev] Lets talk about Git On Sun, Feb 12, 2012 at 5:25 PM, Andrew Stormont andyjstorm...@gmail.com wrote: I just want to say straightaway that I apologise. My intention is not to start a flamewar or bike shedding but to merely show that there are benefits to offering git as an alternative to mercurial. I'm sure if the URL was 'whygitisagoodalternativetox.com' I wouldn't need to have to clarify this ;) No need to apologize, my response was meant to be tongue-in-cheek, not trying to escalate this, just to warn that it becomes a bikeshed if we have to choose between the two, which is preferable to avoid. I'm pretty comfortable that we have a reasonable grasp on how to put together a technical solution to co-existence with complete parity. I'd pretty excited about the prospect of working with you to make sure that happens. I don't think we should keep hg around because it's the best in some absolute sense, I think we should keep it around because it's adequate to our needs and conversion requires cat-herding of existing developers that's best avoided. We should maintain perspective: git has momentum and a very large user base because plenty of people do agree that git is better than the alternatives, and we need to respect that by letting people who like it continue to use it. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
On Sun, Feb 12, 2012 at 15:49, Andrew Stormont andyjstorm...@gmail.com wrote: Hi all, At the Illumos meetup in Brussels it was proposed that we migrate illumos-userland to GitHub. There were several good reasons for making the switch but the two main ones were: git is faster (because most of it is written in C) and git is more popular (which hopefully means there are more people familiar with it). I would like us to add this to the agenda for the next #oi-meeting and in the mean time please feel free to reply with your thoughts/opinions about switching to git. Thanks, Andrew I think this is a two part discussion: 1. Switching from Mercurial to Git. 2. Switching to a repository hosted on an external hosting site, with the features is provides. I am not going to go into the first part, since I am sure whichever tool we choose have the features we may need. If I had to vote for one of them, it would however be Git, since that's what I'm used to working with, and I don't really see any downsides to using Git. I would instead like to go further in depth on how the contribution process can open up to new developers, if/when we switch to an external code hosting site, and how the process of contributing changes may look. The following flowchart should show my idea for how contributions work: http://files.tenzer.dk/contribution-process.png (I am using GitHub as an example for the flowchart, that could be replaced with Bit Bucket or another site.) To quickly talk through it - new developers first of need to have a user on GitHub. That way they can create a fork of the illumos-userland repository on the site. They should create a new branch on their own fork for each change/package they want to add, since they then can put in a pull request to get the changes from one branch merged into the illumos-userland main repository. When a pull request gets in, it will trigger a build in Jenkins. Jenkins will then write a comment on the pull request with the results of the build. In case it failed, the contributor can work further on the code, and when new commits are added to the branch, it will start a new Jenkins build. When the build gets successful, the pull request will be tagged with needs review, which then requires a moderator/trusted developer to look through the patch and accept it, or let the contributor know of any changes which may be required before we can accept it. For trusted developers, they can choose one of two things (this should probably be up for discussion). 1. Commit directly into the illumos-userland repository, the most direct way of putting stuff in. 2. Create the commits as they normally would, but instead of pushing them directly to illumos-userland, they make a pull request in order to get the commit checked by Jenkins. If the build is successful, we can make Jenkins accept the pull request by checking the user who made the pull request against the list of users with commit access to illumos-userland. Ideally everything should go through a pull request in order to get built by Jenkins so we make sure the code in illumos-userland can be build at all times. It only requires one extra step - to go and create a pull request, which basically just is a matter of clicking a button, and shortly describe what the pull request does. It is however up to the developers if they think this is reasonable or not. -- Venlig hilsen / Kind regards Jeppe Toustrup (aka. Tenzer) ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Lets talk about Git
Thanks for the write-up and diagram, Jeppe. I don't think the idea is that trusted means that a commit goes right to the repo: I think trusted means if it clears CI, it's good to go. Everyone else has to have eyeballs and peer review. Maybe core people can do manual pushes straight to the repo, but I think that must be a separate level of trust from a developer whose put forward some clean commits. Some areas may not be verifiable through CI (e.g. changes to the userland tools themselves), and I'd suggest those should always require peer review. One other thing we need is a set of ground rules about what people should change. In particular, I don't think we want to have a lot of volatility in terms of what functionality is or isn't enabled in a component. We need to set a clear expectation that changing those build characteristics must be done with a dedicated issue and changeset, and I'd suggest that such changes are an area where we might want to maintain some kind of peer review just to check consensus. We may not be able to check that programmatically, but the norm should be that doing an end-run around that means losing developer status and having eyeballs on everything you do. On Sun, Feb 12, 2012 at 9:56 PM, Jeppe Toustrup openindi...@tenzer.dkwrote: To quickly talk through it - new developers first of need to have a user on GitHub. That way they can create a fork of the illumos-userland repository on the site. They should create a new branch on their own fork for each change/package they want to add, since they then can put in a pull request to get the changes from one branch merged into the illumos-userland main repository. When a pull request gets in, it will trigger a build in Jenkins. Jenkins will then write a comment on the pull request with the results of the build. In case it failed, the contributor can work further on the code, and when new commits are added to the branch, it will start a new Jenkins build. When the build gets successful, the pull request will be tagged with needs review, which then requires a moderator/trusted developer to look through the patch and accept it, or let the contributor know of any changes which may be required before we can accept it. For trusted developers, they can choose one of two things (this should probably be up for discussion). 1. Commit directly into the illumos-userland repository, the most direct way of putting stuff in. 2. Create the commits as they normally would, but instead of pushing them directly to illumos-userland, they make a pull request in order to get the commit checked by Jenkins. If the build is successful, we can make Jenkins accept the pull request by checking the user who made the pull request against the list of users with commit access to illumos-userland. Ideally everything should go through a pull request in order to get built by Jenkins so we make sure the code in illumos-userland can be build at all times. It only requires one extra step - to go and create a pull request, which basically just is a matter of clicking a button, and shortly describe what the pull request does. It is however up to the developers if they think this is reasonable or not. -- Venlig hilsen / Kind regards Jeppe Toustrup (aka. Tenzer) ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
