[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-factory
Subject:    Re: [opensuse-factory] drpmsync.opensuse.org:8888/Factory ?
From:       Robert Schiele <rschiele () uni-mannheim ! de>
Date:       2006-06-28 11:10:05
Message-ID: 20060628111005.GW704 () schiele ! dyndns ! org
[Download RAW message or body]


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:rschiele@uni-mannheim.de

"Quidquid latine dictum sit, altum sonatur."

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]