<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Erol,<div><br><div><div>On Jul 10, 2013, at 11:50 PM, Erol Zavidic <<a href="mailto:erolms@gmail.com">erolms@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Good evening folks,<div><br></div><div style="">thanks for your feedbacks so far, here's the summary clustered in some way:</div><div style=""><br></div><div style="">1.0 - Release Engineering:</div><div style="">1.1 - should not be bureaucratic, i.e. rather an internal agreement (Alex)</div></div></blockquote>I support this type for now.<br><blockquote type="cite"><div dir="ltr">
<div style="">1.2 - the process of pushing updates to /dev or /stable repos is undefined (Alex)</div></div></blockquote><blockquote type="cite"><div dir="ltr"><div style="">1.3 - safeguarding /stable repo (Jon)</div><div style="">1.4 - streamline code review and integration process LGTMs (Adam)</div>
<div style="">1.5 - build of many desktop packages impossible due to missing Manifests (David)</div><div style="">1.6 - creation of development, release and stable branches within hipster repository (Erol)</div><div style="">
1.7 - implementing feature requests (as Ken did), assigning tasks to available developers (Erol)</div><div style=""><br></div><div style="">2.0 - Build toolset / infrastructure</div><div style="">2.1 - package dependencies influencing build/installation of other packages (Alex)</div>
<div style="">2.2 - build tools outdated and need refresh (David)</div><div style=""><br></div><div style="">3.0 - General topics</div><div style="">3.1 - decide on direction of /hipster effort (David)</div><div style=""><br></div>
<div style="">Here some my thoughts about the topics above, please share your opinion.</div><div style=""><br></div><div style="">ad 3.1: hipster is in my opinion a bleeding edge / unstable type of repo. It should not be limited to core or server packages, ideally a source of all packages for stable/dev repos. Building a server or desktop ISO should be left then for the people creating these. I personally use desktop version of OI, but that was my choice to use it.</div></div></blockquote><div>I am interested in server aspects of OI and will work towards that direction (simple illumos-based server with available security fixes and packages in the repository, similar to the common linux model). I am not sure that it is the best to concentrate on all development branches. OpenIndiana hasn't made any stable release so far (at least none I am aware off) and this kills it. People are afraid of everything that is called /dev, /experimental or /prestable. I and others have been using prestable builds of OpenIndiana for some time now and I declared that it is rock-solid and suitable for /stable release. Therefore, if we want to create some branches, I would definitely go for bleeding edge (/hipster) and make /stable out of current /dev. The questionn here is if we have enough man power to support /stable.</div><br><blockquote type="cite"><div dir="ltr">
<div style="">ad 1.1, 1.4: agree here; LGTMs process failed and caused people to stop contributing. Using branches in git we can easily setup quick review process and contributors can send their pull requests towards hipster repository. Integration is then easily done by people having rights to do this (Alex, David, Adam, etc).</div></div></blockquote><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><br></div><blockquote type="cite"><div dir="ltr">
<div style="">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>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><br><blockquote type="cite"><div dir="ltr"><div style="">ad 1.5: it is an issue and I would label it with prio 2 at this very moment. Can we exactly identify which packages are missing?</div></div></blockquote><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><br><blockquote type="cite"><div dir="ltr">
<div style="">ad 1.6: would it make sense to create stable, dev, release and edge branches within hipster repository to stabilize releases a bit? Propagation from edge to dev and stable would be easy-peasy with git. As a rough Idea how it could look alike have a look at Vincent Driessen <a href="http://nvie.com/posts/a-successful-git-branching-model/">blog entry</a>.</div>
<div style=""><br></div><div style="">ad 1.7: consider Ken's email with request for LibreOffice as a good example where we could implement scrum method, delivering sprints and assigning tasks to available volunteers. Which tool to use I cannot tell. JIRA is obviously very common. Using milestones and issues in github one could mimic the behavior.</div></div></blockquote><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><br><blockquote type="cite"><div dir="ltr">
<div style="">ad 2.1: package dependencies is indeed a prio 1 issue. I like the Alex's idea of having BUILD and INSTALL dependencies listed. Would be manual effort unless we can automate this. Any scripts to do this?</div></div></blockquote><div>I am not aware any scripts to do this. Everytime I create new development environment for myself I just simply install everything because it is the easiest thing to do. I propose that packages have build.deps file, which contain FMRIs of dependencies. If a contributor is committing a new package, he should be aware of package build dependencies. We should think about build dependency tracking, once we have those files. I find having up-to-date dynamic languages as the highest priority for now.</div><br><blockquote type="cite"><div dir="ltr">
<div style="">ad 2.2: prio 1* - needs immediate attention. David, you listed a few, can we get a full list and split amongst us who is taking which tool to update?</div></div></blockquote><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/">https://hg.openindiana.org/users/xenol/oi-build/</a></div><br></div><div>Seeing open discussion about release engineering and organization is great and motivating for moving things forward. However, let's not kill most of our efforts by talking and taking no action. Let's just keep things KISS and do some small coordination.</div><div><br></div><div>Cheers,</div><div>Adam </div><br></div></body></html>