<span style="font-family: verdana,sans-serif;">Dago wrote:</span><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; There is no need for it to be handled internally.</span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; Explanations are given in www.opencsw.org:/home/newpkgs/README </span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Not sure what you mean there, but <a href="http://opencsw.org/home/newpkgs/README">http://opencsw.org/home/newpkgs/README</a> doesn&#39;t exist, nor does [/export]/home/newpkgs/README on <a href="http://login.bo.opencsw.org">login.bo.opencsw.org</a>.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Trygve wrote:</span><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt;&nbsp; From what I can tell the major point WRT to the release process is getting</span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; every rule written down or put into code as a part of chkpkg.</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">+1</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Peter wrote:</span><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; It&#39;s impossible to code checkpkg to cover &quot;everything&quot;.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">This is not an argument against automated testing. Well, it is actually an /argument/ against automated testing, but a really bad one. The whole world of software development these days seems to have accepted that automated testing is good, and should be used to the maximum extent possible. We should try and code tests for every possible reason to reject a package (and document this too).</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt;But there will always be exceptoins.</span><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; At some point, there always comes a need for a human being to make a decision</span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; of &quot;yes this is acceptible/no this is not&quot;.</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">I disagree. If something passes all the testing, why not release it? The project board might want to retain a long-stop power to pull software that was defective in some previously unheard of, and therefore untested for, way. Other than that maintainers should be able to say &quot;this is good to go&quot;, provided it meets the published standard. Personally, I would also restrict this to automated builds that run off a gar or similar system, so hudson (or similar) does the build on the basis of a published make/spec file, and the testing/approval is fully automated.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; Peter seems to want to completely eliminate any human inspection of packages.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">There is an interesting parallel with a discussion at my workplace just this week. Some admins want to retain manual builds for much of the software stack. I want to see everything that can be automated. The tools are there, and I feel the benefits are clear. It seems OpenCSW is now having the same conversation.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; I say that this is not possible.</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">It is definitely possible. Do the benefits outweigh the disadvantages? I&#39;d say yes.</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">Peter then wrote:</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; I tried to convey that we can reasonably cover, lets say, 80% of cases through</span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; checkpkg, and 95% of cases via &quot;written down&quot;, but there&#39;s always going to be </span><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; a grey area left. Either that, or our &quot;standards documentation&quot; will become so</span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; ludicrously large, that it will become effectively USELESS</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Reasons for rejecting packages need to be documented and agreed upon, not subject to arbitary decisions. If the documentation gets too large... let&#39;s cross that bridge then. I don&#39;t see excessive documentation weighing down MacPorts or Fedora Packages or whatever. The &quot;grey area&quot; is just the exercise of individual discretion, and we should be looking to eliminate that from the quality control process.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Peter wrote some more:</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; Decide what?</span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; More than one person to decide what actually gets written down as standards?</span><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; More than one person, in case the primary person is on vacation or ill?</span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; Or to play a game of &quot;well, mom said I cant, so I&#39;ll go ask dad instead&quot;?</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">The standards should be agreed on by the board at the minimum, maybe the whole membership should vote on it.</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; In my opinion, it would be a bad thing, to have one set of packages that</span><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; are put into &quot;current&quot;&nbsp; via one person, that have strict consistency to them,</span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; and then have another set of packages, allowed to go into current</span><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; by a different person, that did not have consistency to them.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Of course, we should strive for consistency. However, in my country, there are many judges, juries and magistrates called upon to make legal judgements in different courts every day. They strive to be consistent with one another (we have Common Law system here). They may not actually be 100% consistent but that is the aim. No one suggests that in order to maintain perfect consistency we can only have one judge.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Sebastian wrote:</span><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; Has the release process with Phil as the single point of getting packages</span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; into current shown a major bottleneck so far?</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Well, depends what you call &#39;major&#39;. Certainly a bottleneck.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; Or is it the manual nature (effort on the maintainers side) of the release </span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;">&gt; process?</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">I don&#39;t like a manual process either. I like automation. I want to SVN check in a fresh file to GAR, and do basically nothing else if there are no problems... build it, test it, release to testing, wait, release to newpkgs, maybe email me and some others a status update as it moves through the system...</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; Did packages get rejected out of uncertain or non-understandable reasons?</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Yes</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">&gt; Do we have a truck factor issue with Phil as the only path to current at the moment? </span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">We call it the &#39;hit by a bus&#39; factor here, and yes. Again, personally, I don&#39;t think packages should have a single mainainer either, it should be minimum two. For release gatekeepers/GPG keyholders, I&#39;d like half a dozen.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Just my 2p...</span><br style="font-family: verdana,sans-serif;"><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Gary</span><br style="font-family: verdana,sans-serif;">
<span style="font-family: verdana,sans-serif;"></span><br style="font-family: verdana,sans-serif;">