On Mon, Feb 25, 2008 at 01:40:12PM +0100, Rado S wrote:
> =- James Cameron wrote on Mon 25.Feb'08 at  9:35:17 +1100 -=
> [...] 
> 
> > > Before breaking {what's supposed to be as it is} with a change
> > > to _my_ liking I want to know what there is more than I could
> > > think about why things are as they are.
> > 
> > It won't help though ... even if you just provide a patch to match
> > your understanding of what should happen, there may be some who
> > would fight you over it.
> 
> Exactly, that's why I ask in advance, to avoid fighting and/ or
> wasting time by hacking unfamiliar code.
> I rather spend the little time I can afford on things I can handle
> or learn just enough to make a problem go away, not all the code.

On the other hand, once you have invested the time in learning the code,
you will be able to argue more soundly and successfully.  The only
expert status I have comes from understanding or writing the code.  Even
Bill gets patches accepted, once he understands the code.

> > I'm more likely to accept a patch if it has a simple explanation
> > of what it fixes.
> 
> I don't expect immediate acceptance, but a discussion (at least
> about things unknown to me), so I better understand the current
> state and how to think about solutions.

The trouble I have is that I don't know exactly what you are proposing,
because it hasn't hit my mental model of the current situation.  My
mental model is integrated with the source code.

> Despite being subscribed to the various netrek-places, I'm not aware
> of all technical (in-)decisions of the past.
> 
> As said, I supposed that what is there and how it is were for a good
> reason. It's news to me that it isn't, and I'll keep in mind to
> question intention before arguing about it.
> 
> Why is conceptually broken code kept and -- worse -- used?
> Both filtering/ starting empty servers and dropping dead solicitors
> doesn't sound like a big problem.
> 
> > Intentions or reasons rarely matter to me. I'm more interested in
> > the code, and the future.
> 
> You're aware that you're contradicting yourself?
> Future == intention/ reasons.

That's an interesting viewpoint.  I didn't see a contradiction.

> > > > Yet how can we implement a way to delist that cannot be easily
> > > > abused by attackers? Source IP address is trivially forged.
> > > 
> > > By listing only those soliciting continuously and responding
> > > when checked after a timeout.
> > 
> > That is almost what is currently implemented, except that servers
> > are not contacted after a timeout.
> 
> Exactly, that's what I hoped to have patched with the simple code
> change suggested.
> 
> > > I gave it.
> > > A "patch(1)"-able format wouldn't give you any more information
> > > than I gave you already.
> > 
> > It would give the information I need to apply the patch.
> 
> You can't replace 1 single line of code (by copy&paste)?
> 
> > I will take a patch if I understand it and agree with it.
> 
> So, what's the problem understanding with 1 instruction replaced by
> another and its location?

Can't you use diff(1) yet?  It isn't difficult.  darcs even makes it
easier ... "darcs diff > proposed.patch"

Let me tell you what happens if you send a patch ...

1.  my mail reader flags it as a patch and places it ahead of every
other mail I've got to read,

2.  my mail reader extracts the patch and discovers which source code
repository (of 65) it relates to,

3.  on command, the patch is applied to a copied repository, to verify
the patch can be applied without error,

4.  on command, the patch is displayed in emacs, with hyperlinks from
each patch line to the source code in the old or new version of the
repository,

5.  any questions about side-effects or usage are resolved using the
emacs etags cross-referencer,

6.  compilation is tested by hitting a key,

7.  any stylistic changes can be made, and a new review patch written to
cover them,

8.  a decision is made on whether to accept the patch as is, augment it,
or reject it,

9.  the patch from you and any review patch from me are then pushed to
the external repository for others to use.

Steps 1 and 2 are replaced by a "darcs pull" for the developers who have
repositories available already.

> > > You like to keep it simple for yourself, but you overdo it at times,
> > > and then blame me for catching up with what you missed to add.
> > > Discussion is not a contest about the shortest answer, but a desire
> > > to proceed together.
> > 
> > Interesting, but not relevant.
> 
> *sigh*
> Ok, if you say so.

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/