On Wed, Jun 28, 2006 at 11:24:17AM +0200, Adrian Schroeter wrote: > Robert, as we discussed it before via IM, you know that we know about that > problem and mls has atm also other high priority work. > > I do understand that it is not satisfying for you, when we tell you that this > problem has not on the highest priority at us atm. But it is the most honest > answer I was able to give you. > > It is also not that easy only to apply a patch, Michael wants to debug what > actually wents wrong and needs to review the code (his and yours) before he > is able to solve it.
You are mixing up things now. What might actually be required to be done is reviewing the code I attached in the sense that it does not do any harm. This should be a very fast process because someone with basic perl knowledge can easily see that the code is a) almost completely copied from the known drpmsync code with just code removed that is not needed for this purpose and one simple loop added and b) does not open any file for writing anyway or call any other critical system function and thus can not do any harm even if a fatal bug was included. Debugging what went wrong in the drpmsync server implementation is a competely different thing. Or do you want to allow different ways of doing something only if your current way has ultimately proven to be the wrong way? My way of doing things would only add one extra file of about 3MB to the factory distribution without hurting the current drpmsync server or other infrastructure in any way thus there is no reason to mix these things up. > The reason why it has not the highest priority is that we are at the end > phase > of SLES 10 and that the drpmsync service has only a small number of users. So > I hope this is reasonable. But this process will only consume much time if you try to solve all related problems at one point in time before doing anything else. If you only did look at the code provided by me in the aspect that it does not do any harm to your internal infrastructure and dumped its output to a file within the repository then this would not take much time and a solution was available that allowed other people (like me) could continue their work. > Michael does not read this list btw, so you will not get an answer from him > here. Please contact him directly to get feedback, but he had no time to look Ok, adding him to CC of this mail. > into this issue yet. I hope he can see the difference between running my code snippet in the repository and fixing the problem in the server and not consider this as one issue that must be solved together or not at all. > Btw, the client limit has been removed again to debug this. Stricter ulimits > are set this time. And the configuration change (no_deltacombine), suggested > by you is also still active. Ok, then one can at least sync again now. But I'd still like to continue development of an alternative way of doing things because I believe that this is the better way of doing it even when the current problem in the drpmsync server is fixed. You might have a different view here but if you even don't give me a chance to implement the idea and prove my point of view then I don't see what I should do here. If you provided the file created from my script, we had a drpmsync client that does not need a drpmsync server at all thus nullifying all problems that exist because no mirror admin wants to provide a drpmsync server. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:[EMAIL PROTECTED] "Quidquid latine dictum sit, altum sonatur."
pgp9Ogrnriaeb.pgp
Description: PGP signature
