[PATCH] Re: Implement SSL certificate checking

[Sebastian Spaeth]

On Wed, 15 Dec 2010 12:26:20 +0100, Johannes Stezenbach <js at sig21.net> wrote:
> > It's not like I posted a monster-patch that is totally convoluted, after
> > all it is  "only" 3 files, 132 insertions(+), 72 deletions(-). I did
> > start work to break out some of the changes in a separate patch. I would
> > still like to hear whether the approach is ok, before I invest more time
> > in it. Release early, Release often is what I got told :).
> 
> Just look at "git log origin/next".  62712cbe15a was supposed to
> be a simple fix, but added a crap file which was removed in
> 667dd30afe.

I don't want to defend myself, but the current git workflow causes me to
ammend, split, rebase, and merge patches in ways I have never done
before. I apologize for accidental sneak-ins to those patches and I
hope I will learn to master git better over time.

> IOW, you're already exceeding the review bandwidth
> causing the maintainer to apply unreviewed patches.
> That sucks.

I have been explicitely asked to send patches and topics early and
often, and I guess we need to find a middle ground that is workable for all.

I've gone out of my way to address all and any concerns to my patches
that have been voiced by anyone on this list, which is why you often see
various iterations on the list.

I am not sending patches to change things for the sake of change. I am
sending patches that I feel a) fix bugs b) clean up the code and c)
prepare future improvements (as one-way syncing, and better debugging
without threads).

E.g. I think the certification verification is something that we should
address rather sooner than later. Nicolas said he wouldn't mind if we
are kicked out of Debian, but I would find that a pity. That's why I
hurried to get that one out.

If you feel that my patches do more harm than good I will keep them in
my private branches.

Sebastian

P.S. One question on the current workflow: We are asked to base our
patches against Master, but they will be merged into next (or pu),
right? Because I often develop against next as it contains fixes that I
rely on. So I have to rebase my patches against master, so Nicolas can
rebase them back to next before applying? I did get that piece right,
didn't I?