<div dir="ltr">On 11 July 2013 01:12, Adam Števko <span dir="ltr"><<a href="mailto:adam.stevko@gmail.com" target="_blank">adam.stevko@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="im"><blockquote type="cite"><div dir="ltr"><div>1.1    - should not be bureaucratic, i.e. rather an internal agreement (Alex)</div>
</div></blockquote></div>I support this type for now.</div></div></div></blockquote><div> <br></div><div>I believe this is commonly agreed now - we go on without complicated process, hack-on-go basis, sending reviews into the list and merging into repository.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>Unless there is greater number of contributors, I don't see point in using branches. I like Andrzej's idea of forking a oi-userland repository and posting link to a changeset for a review. Do you think that using branches will help us at the moment somehow? I think that it will complicate some things at this stage. However, I am open to any ideas, which will bring simple, non-bureacratic reviews. </div>
</div></div></blockquote><div><br></div><div>Branches could help us later on in the future for staging the code from "I'm hacking at it now" to "It's publishing fine and installs well without breaking anything" to "It's running fine for a while now and it might be a candidate for migration to /dev". This is just a suggestion. <br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="im"><div></div><blockquote type="cite">
<div dir="ltr">
<div>ad 1.3: clever release engineering is definitely required. It requires integration testing. Do we have resources and/or testing environments for this?</div></div></blockquote></div><div>hipster jenkins and repository, nothing else I am aware of. I checked OI boxes and there are old development zones after people, who left. i can create zones if needed, but keep in mind that dev01 is running 161a7 and dev02 151a8 from /dev-test (this was needed in order to support MIlan's work on JDS) and running /hipster zone on older version is not possible due to libc changes afaik (I had to fully upgrade my 151a7 build server to /hipster if I wanted to run /hipster build zones).</div>
</div></div></div></blockquote><div><br></div><div>I'll look at my hosting provider if I can get a box to run OI on it - but initial setup will be problematic with bootp and stuff.<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div>Almost every dynamic language, we have in the repository. If we could get to the point, that the users could install some common tools for every language (pip, gem, pecl, cpan, npm..) and up-to-date language version (python 2.7.3, ruby 1.9.x or 2.x for DTrace goodness, perl 5.14 or 5.16, lua etc), this would simplify porting other stuff. Next thing, I find important is absorbing as much as possible from ec-userland, because common server (and even desktop software) is there. ec-userland contains updated nginx, php, mysql, postgresql, apache and multimedia things like ffmpeg, vlc and their dependencies (which I am grateful for because I will have to deal with this in a week or so for my job. Thanks EC guys!). </div>
</div></div></div></blockquote><div><br></div><div>Alright, let's focus on scripting languages including tools for now. Do we have permission from EC guys doing this? If yes, where can I find their repositoriy?<br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br><div>I wouldn't complicate things with JIRA and just use Github. It is simple and we have it already. We have to just start creating issues and somebody should keep an overview. However, this can be very time consuming and the best thing we can do at the moment is to try coordination, so we don't duplicate our efforts and possibly concentrate our work on packages I mentioned above. For example, if few of us start to deal with one language, this should be done pretty quickly. </div>
</div></div></div></blockquote><div><br></div><div>Who has the rights on OI Github repository? Can I be added as a contributor there? I would enable Issues in Repo and start filling in first tasks. Easy coordination and task assignment + reduction of duplicate work.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>In the second half of 2012, I was working on making oi-build compilable by gcc. I started by updating the build infrastructure. Those pieces can be reused. I am aware of autoconf (updated in my WIP repo), binutils, libtool (update is already in userland-gate, but it is delivering older <span style="font-size:12px">libltdl)</span> and automake (updated in my WIP repo). At the moment, I am working on build-essential meta package, which will be based on ec-userland and openindiana wiki page. Having this single package will simplify our life. My old WIP repository can be found at <a href="https://hg.openindiana.org/users/xenol/oi-build/" target="_blank">https://hg.openindiana.org/users/xenol/oi-build/</a><br>
</div><div></div></div></div></blockquote><div><br></div><div>I like your build-essential meta package, I'll use it to verify latest versions available and create issues in github for everyone to see. Devs are welcome then to take over the piece and put their name behind the issue.<br>
<br></div><div>Cheers,<br>Erol<br></div></div></div></div>