> > Let me just reiterate that it doesn't make sense to do any of this > > post-November, since we're switching transport methods. My guess is that > > we'll probably have to discard most the current transport implementation. > > If we're going to get rid of the code anyway, then why are we cleaning it > up to make maintenance easier?
I was lead to believe that we were going to grow a sustaining tail at some point in the near future. I don't know any of the details, but it at least seemed reasonable to assume that different versions of our code might continue to live on, even if we're continuing to develop at the tip of the repository. Of course, I may have misunderstood. > I don't really care much one way or the other. If you think the change > will make your life easier in the future if and only if it gets in before > the November release, then the code looks sufficiently correct to me that I > have no objections. It's just not the way I'd go about it. Ok. Thanks for taking a look and providing feedback. I'll pick your brain more when we need to do the error handling for PyCurl. Keep in mind that these bits of code have evolved, mostly by taking one-offs on the previous version. > > If you haven't looked at the current TransportException schema, I'd > > encourage you to do so. Dan added a bunch of exceptions when he unified > > the multiple error output. We know how to cope with anything that's a > > subclass of TransportException. If the name annoys you, I can introduce > > yet another type of TransportException. We can call it > > RetryableTransportException, as you suggested. > > Are all TransportExceptions retryable, or are some fatal? If they're all > retryable, then my suggestions are irrelevant for that reason alone. TransportExceptions are retryable, but the <Transport>RetrievalExceptions are fatal. I realize that's a bit confusing. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
