2009/1/20 Philip Brown <span dir="ltr"><<a href="mailto:phil@bolthole.com">phil@bolthole.com</a>></span><br><div 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;">
<div class="Ih2E3d">On Tue, Jan 20, 2009 at 10:23:33PM +0000, Gary Law wrote:<br>
> OK, I have to say it hadn't occurred to me that I could ssh in... but I<br>
> can! However, as far as I can tell the file isn't there:<br>
> $ scp www.opencsw.org:/home/newpkgs/README .<br>
> scp: /home/newpkgs/README: No such file or directory<br>
<br>
</div>The original emailer, who wasnt me AFAIK, mistyped. If you actually log in and<br>
look in that directory, you will see that the actual file name is<br>
00-README or something like that.</blockquote><div><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Indeed, that's it.</span><br style="font-family: verdana,sans-serif;"> </div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Bottom line is, though, most people wont care about the file anyway. They<br>
will probably email me "why isnt my package released yet", and then *I*<br>
will go look at the file, to remind myself and them, the reasons why their<br>
package is still sitting in newpkgs. I put the reminder file there<br>
(instead of my home dir) , as an effort to be transparent to everyone about<br>
what is going on with things. Go read it, if you're curious.</blockquote><div><br><span style="font-family: verdana,sans-serif;">Thanks. That is a pointer to how things work. It is also a clear indication of how much of this process is currently handled by one person.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> that is to say, automated testing is nice, but it cannot cover<br>
<div class="Ih2E3d">
> everything that needs to be covered.<br>
><br>
> Perhaps I'd have a better idea if you could explain what needs to be<br>
> covered that's not automatable?<br>
<br>
</div>Are you familiar with "the halting problem" in software design?</blockquote><div><br><span style="font-family: verdana,sans-serif;">Err, I wasn't aware that checkpkg was actually trying to solve that problem.</span><br style="font-family: verdana,sans-serif;">
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Some things are fundamentally not solvable by fully automated methods.<br>
This is one of them.</blockquote><div style="font-family: verdana,sans-serif;"><br>*What* is one of them? What are these nebulous criteria that cannot be tested in an automated fashion -- or indeed in a consistent way by anyone other than you personally -- but packages must comply with before release? <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If i could explain "everything that needs to be covered" before ever seeing<br>
it, then not only would i be capable of designing a perfect AI, but i would<br>
also be clairvoyant. In which case, i'd be playing the stock market, and<br>
relaxing on a beach in the Bahamas instead of doing this :-)</blockquote><div><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Legislators face this problem every day. So do company managers. So so software designers. You make rules based on what you know, and what you anticipate. You don't expect it to be perfect, do you aim for 'good enough'. You accept that future revisions might require better rules/tests. That 'good enough' standard will be different if writing software for a content only website, or a bank teller system, or a fly-by-wire aircraft control system. I'm not asking you to explain everything you might find wrong in packages that don't yet exist; but I am suggesting we need to dispassionately look at proposed releases, against published criteria, and ideally automate the enforcement of the standard by failing to release things that fail a test. (I'm also not of the view that submission to one human being for arbitrary rubber stamp based on unpublished criteria should be the key determinant of the release process).</span><br style="font-family: verdana,sans-serif;">
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> You don't address the points concerning only having one gatekeeper on<br>
<div class="Ih2E3d">
> releases or on the use of individual discretion in this reply.<br>
<br>
</div>You havent given specifics why it is a bad thing. You have basically<br>
stated "it is bad", without saying what is actually bad about it.<br>
In constrast, I have given explicit reasons why it is a GOOD thing<br>
(consistency), and I have also given specific reasons why the<br>
"phil gets run over by a bus" claim to be concerned, is invalid.<br>
It has already been handled.</blockquote><div><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">Consistency is much more likely to be provided by automated tests, and well understood and broadly agreed standards. One person signing things off is more fallible IMHO. Even if you manage to be perfectly consistent with yourself this is not a scalable, or transparent, or open way of doing this. It does not encourage community participation. It's not a process I can explain to a potential new maintainer. It's also not consistent when you're not around for any reason, as the process just stops, which isn't consistent either.</span><br style="font-family: verdana,sans-serif;">
<br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">My last employer had a Change Advisory Board to decide on software releases. We tried to keep membership consistent from meeting to meeting, to maintain consistent decision making, but this never entirely possible. And it didn't matter much. The fact is good (automated) QA and agreed, published standards were more useful in the long term to raising standards in software than trying to keep the same bunch of people in a room, week in, week out. Companies signing off software with the potential to cost/make millions of $CURRENCY can do so on the basis of a inconsistent process like a CAB -- so why can't a volunteer effort release a couple of Solaris packages?</span><br style="font-family: verdana,sans-serif;">
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Let's not waste people's time rehashing things that have already been<br>
solved, please?<br></blockquote></div><br style="font-family: verdana,sans-serif;"><span style="font-family: verdana,sans-serif;">This isn't rehashing, it's the first time I've seen it properly discussed since OpenCSW was formed, and, from where I'm standing, this is so /not/ solved. I think you suggested putting it to a vote... something I'll be entirely in favour of as soon as my membership application is approved..... :)</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;"><br><br>-- <br>Gary Law<br>Email: <a href="mailto:glaw@opencsw.org">glaw@opencsw.org</a><br>
<br>