<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 style>1.2 - the process of pushing updates to /dev or /stable repos is undefined (Alex)</div><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 style><br></div><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 style><br></div><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 style><br></div><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 style><br></div><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 behaviour.</div>
<div style><br></div><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 style><br></div><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 style><br></div><div style>Looking forward to your feedbacks and discussions.</div>
<div style><br></div><div style>Cheers, Erol</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 10 July 2013 11:52, Jonathan Adams <span dir="ltr"><<a href="mailto:t12nslookup@gmail.com" target="_blank">t12nslookup@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>While not a contributor of code atm :(, I suggested something a system when OI started, which was sort of agreed to by some people at the time ...<br>
<br></div>1) stable repository, guarded rigorously by people who do not allow anything in unless it's been signed and sealed as core and stable, seriously if this was surrounded by the river styx and you had to pay with your soul to cross, that'd be sensible.<br>
<br></div>2) dev/apps repository where apps that are considered not core, and mostly stable go, and changes to core that need testing before going stable.<br><br></div>3) bleeding edge dev repository where apps and code that are basically considered volatile, latest releases and all core code changes go, for those who are happy with a suck-it-and-see approach.<br>
<br></div>this would allow risk-averse server admin to pick "stable", less risk-averse server admin (or risk-averse laptop/desktop users) to pick "dev", and those who like sky-diving on the way to work to pick "unstable"/"bleeding edge" ...<br>
<br></div>I would imagine /hipster to be in the latter, and the current /dev to be in "dev", but then, I'm an outsider.<br><br>Jon<br><div><div><div><div><div><br><br></div></div></div></div></div></div><div class="HOEnZb">
<div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">On 10 July 2013 10:34, David Höppner <span dir="ltr"><<a href="mailto:0xffea@gmail.com" target="_blank">0xffea@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I can speak only for myself, but I think its too early to try this. In<br>
my view hipster is currently<br>
only a developer effort. Too many core packages (automake, libtool,<br>
glib) still need to be updated<br>
to build some newer software. Even that ruby 1.8.7 update is End of<br>
Life now. Further many packages (desktop)<br>
can't be rebuild, because we have no Manifests in hipster for them yet.<br>
<br>
We should discuss the general direction of hipster (desktop,<br>
core package versions and updated (to build illumos)), but I think<br>
there are too many open problems<br>
to impose release quality at this stage.<br>
<span><font color="#888888"><br>
-- David<br>
</font></span><div><div><br>
On 10 July 2013 03:24, Erol Zavidic <<a href="mailto:erolms@gmail.com" target="_blank">erolms@gmail.com</a>> wrote:<br>
> Folks,<br>
><br>
> I just want to notice a thing or two from my side that might be relevant for the OI (hipster).<br>
><br>
> What I've seen and consider really important is to implement a kind of release engineering. And here I do not want some complicated process with many approvals and stuff - rather a sleek and streamlined (hipster) release management.<br>
><br>
> I've seen packages breaking builds because of incompatible versions (e.g. libmemcached bump made myself incompatible with php5.4, or ruby version breaking other stuff...).<br>
><br>
> Is it feasible to organise a non-bureaucratic release management setting the priorities which packages should get updated first and then possibly check for defects produced by it?<br>
><br>
> Just a thought - and willing to help with it. Let me know your thoughts.<br>
><br>
> Cheers, Erol<br>
> _______________________________________________<br>
> oi-dev mailing list<br>
> <a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a><br>
> <a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/mailman/listinfo/oi-dev</a><br>
<br>
_______________________________________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org" target="_blank">oi-dev@openindiana.org</a><br>
<a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/mailman/listinfo/oi-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
oi-dev mailing list<br>
<a href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a><br>
<a href="http://openindiana.org/mailman/listinfo/oi-dev" target="_blank">http://openindiana.org/mailman/listinfo/oi-dev</a><br></blockquote></div><br></div>