<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>I respectfully disagree that there are too few developers. Or maybe it is just that nobody can agree upon the direction OI should take. If Alasdair Lumsden reads this thread he can correct me if there are inaccuracies, but I recall him saying there were not many developers working on OI. He should know better than anyone.</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><span>But the fact that Jon Tibble seemed to do the work of releasing 151a8 himself, or mostly himself, seems to give credence to the number of
developers.<br></span></div><div><br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <hr size="1"> <font face="Arial" size="2"> <b><span style="font-weight:bold;">From:</span></b> Thomas Wagner <tom-oi-dev@tom.bn-ulm.de><br> <b><span style="font-weight: bold;">To:</span></b> OpenIndiana Developer mailing list <oi-dev@openindiana.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Saturday, August 17, 2013 11:21 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [oi-dev] current process for architectural decisions OI<br> </font> </div> <div class="y_msg_container"><br>
Hi Alexander<br>On Thu, Aug 15, 2013 at 09:44:36AM +0400, Alexander Pyhalov wrote:<br>> Hello, Thomas.<br>> <br>> Thomas Wagner писал 14.08.2013 22:28:<br>> > What is currenty the process / method / agreement for<br>> > architectural decisions in OI?<br>> > Is there any? If not, I take it that a single person<br>> > who gained write access to the repositories, can put<br>> > any change into the gates, right?<br>> <br>> I'm afraid you are right... There is no any formal process.<br>> However, I think we try to discuss.<br>> <br>> What do you suggest? I think the main problem with public discussion or<br>> formal process is that there is no enough developers<br>> for constructive discussions.<br><br>I don't think we have too few developers to comment or hold<br>discussions, in my view, it's more that we don't bring to<br>attention what is currently
developed. As a side effect<br>I believe making development more public attracts people<br>to comment on topics, even if they do not necessarily<br>do active OI development.<br>But their view, needs, knowledge, experience, concerns<br>should really be used to keep the quailty high in the<br>long term.<br><br>So I would suggest that there are two kinds of processes.<br>One for quick and simple changes, to primarily inform<br>the others about a planned change with little to no<br>risk or impact. That would be a little form to fill in.<br>Example would be "updating libz from 1.1 to 1.2,<br>comments, prolems solved, CVE-numbers, planned target<br>devel release".<br>In case others have cncerns they could ask for making<br>that a full case, as described next. Else, it is<br>just closed and approved.<br><br>Another process would be for large scale changes or<br>such changes where incompatibilites are introduced<br>or are expected.<br>That may be impact on OI's
own code, for example<br>large changes to the Gnome Desktop. Or changes in<br>OI which affect external Projects using OI as a<br>building block.<br>Example would be chaning default perl version or<br>a major change to the gcc compiler.<br><br>If a concern is raised, then this should be discussed<br>and come to a decision that the change is not ready<br>to be commited, or it is ready to be commited with<br>or without some described changes.<br>There are common ways to get such votes, say there<br>are no "-1" and at least two or three "+1" to get<br>the case approved.<br>If there is a "-1", this needs to be described why.<br>Additionally there should be said what needs to be<br>done to remove that "-1".<br><br>Those two processes could be very similar to what has<br>helped to get the Solaris ON code to the quality level<br>it has today: Fasttracks and full PSARC cases.<br>(Others can comment on that methods in more detail,<br>possibly they have a
description of the Solaris change<br>process)<br><br>Or we could use what illumos currently uses, I belive<br>it supports similar targets.<br><br>I don't know if there is a public description of the<br>illumos way and the old Solaris change process.<br><br>Main target should be that the whole process thing<br>is not overly complicated and keeps paperwork at a<br>minimum.<br><br>It *should* help asking other smart developers and<br>add their experience to get to decisions which are<br>good for long term quality.<br><br>Regards,<br>Thomas<br><br>_______________________________________________<br>oi-dev mailing list<br><a ymailto="mailto:oi-dev@openindiana.org" href="mailto:oi-dev@openindiana.org">oi-dev@openindiana.org</a><br>http://openindiana.org/mailman/listinfo/oi-dev<br><br><br></div> </div> </div> </div></body></html>