<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Hi Gary,<div><br><div><div>Am 01.11.2008 um 11:33 schrieb Gary Law:</div><blockquote type="cite"><span style="font-family: verdana,sans-serif;" dir="ltr">2008/10/31 Dagobert Michelsen <<a href="mailto:dam@opencsw.org">dam@opencsw.org</a>></span><br style="font-family: verdana,sans-serif;"><div style="font-family: verdana,sans-serif;" class="gmail_quote"> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> > * **Source**.<br></blockquote><div><br>(*) The project should formally adopt GAR for Sol 9 and 10 builds and make use of GAR mandatory for all packages.</div></div></blockquote><div><br></div><div>That would be good, yes. However, we have quite a mount of existing</div><div>packages which are not in GAR and which are currently orphaned. Would</div><div>you drop them?</div><br><blockquote type="cite"><div style="font-family: verdana,sans-serif;" class="gmail_quote"><div>Future Solaris packaging standards might mean a switch to pkgbuild or something else entirely.</div></div></blockquote><div><br></div><div>It will become mandatory when Solaris 10 support is dropped. Until</div><div>then, we have to produce System V packages, and that will be for</div><div>quite some years from now.</div><br><blockquote type="cite"><div style="font-family: verdana,sans-serif;" class="gmail_quote"><div>Incidentally, not all my packages are in GAR and I don't like it as a tool, however, maintainers having private scripts to build stuff is untransparent and makes taking on the maintenance of an existing package very difficult in some cases.</div></div></blockquote><div><br></div><div>If I can help you moving your packages to GAR let me know.</div><div>Currently I am preparing some more docs and a presentation</div><div>with an introduction to GAR to be held during IRL.</div><br><blockquote type="cite"><div style="font-family: verdana,sans-serif;" class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> * **Key**.<br></blockquote><div><br>(*) The Key should be owned by all of and only the board members.</div></div></blockquote><div><br></div><div>That could be a solution and should be discussed during the meeting.</div><br><blockquote type="cite"><div style="font-family: verdana,sans-serif;" class="gmail_quote"><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">> * **Board**.</span></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For me this is the most important point. The<br> nomination/election is one of the keys on the meeting.</blockquote><div><br>(*) Can maintainers who don't attend vote?</div></div></blockquote><div><br></div><div>Not for the board at this time. If I got Ihsan correctly,</div><div>it is mandatory in Swiss law for the incorporated society</div><div>to meet in person at least once. After the founding, the</div><div>board can accept members which have a right to vote.</div><div>After that "remote-elections" should be possible.</div><br><blockquote type="cite"><div style="font-family: verdana,sans-serif;" class="gmail_quote"><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">> * **Release Process**.</span></div><div><br>You might want to take a look at Hudson, which is a nice Continuous Integration server that I've used for automated builds in the past.</div></div></blockquote><div><br></div>Like this :-)</div><div> <a href="http://buildfarm.opencsw.org/hudson/">http://buildfarm.opencsw.org/hudson/</a></div><div><br></div><div>It will become fully functional when a package can be checked out</div><div>individually (without checking out the whole tree).</div><div>Trygve set this up, thanks!</div><div><br><blockquote type="cite"><div style="font-family: verdana,sans-serif;" class="gmail_quote"><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">> * **Distributed**.</span></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> I don't know if distribution is really that good</blockquote><div><br>+1<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">. ... It may be sufficient to replicate the server<br> backups to different people so the infrastructure can be<br> rebuild quickly if anything happens. </blockquote><div><br> (*) The board members should maintain the infrastructure (delegating to corporations or people as they see fit). Everything should be replicated in two places, ideally I guess one in Europe and one in North America. LDAP, SVN, DNS, web servers, wiki servers... all of these things can be made to work in a fully redundant fashion across a WAN. NFS might be a struggle though.<br> </div>(*) I've got one more, and this is probably going to be a little controversial... we should move out of /opt/csw and into /opt/opencsw. Blastwave Inc is still distributing into /opt/csw and the scope for end user confusion and incompatible software releases is huge. Although this sounds like a lot of work, if everything is in GAR, and everything needs to be rebuilt for Sol 9 in the next six months, it's really not a lot of extra work. I've got big reservations about maintaining stuff through opencsw that installs into /opt/csw.</div></blockquote><br></div><div>Difficult. *If* we change the prefix, then there must be a<br></div><div>converter for installation to go from csw/ to opencsw/, but</div><div>personally I would like to postpone that until we see how</div><div>each project performs. Discussion welcome.</div><div><br></div><div><br></div><div>Best regards</div><div><br></div><div> -- Dago</div></div></body></html>