[PATCH] Re: Implement SSL certificate checking

Nicolas Sebrecht nicolas.s-dev at laposte.net
Wed Dec 15 18:13:00 GMT 2010


On Wed, Dec 15, 2010 at 11:27:23AM -0600, Sebastian Spaeth wrote:
> On Wed, 15 Dec 2010 12:26:20 +0100, Johannes Stezenbach <js at sig21.net> wrote:
> > 
> > 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.

So, learn. :-)
This is why I like FOSS: share knowledge.

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

So, it's my fault too. I should have read the patch a bit more deeply
before merging it.

That said, he did public apologize about that. Do others learn from you
rather than only criticise them.

> 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.

This is workable as is. You may check your patches before sending them
more carefully, though.

> 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.

This isn't true. I just pointed out that

  1) debian urgency policy is not ours;
  2) debian maintainers looks a bit nervous today;
  3) the feedback given here about debian looks inapproppriate.

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

You're free to do so or continue the way you started. Boried users are
free to unsubscribe.

> 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?

I merge patches where I think it has to go. Are not merge them.

>        Because I often develop against next as it contains fixes that I
> rely on.

It depends how it "relies on". If it could be independent, it should be
built against master. If not, you can work on top of next (but shouldn't
have to most of the time). If needed, you may even work against one
topic merged into pu.

>          So I have to rebase my patches against master,

You shouldn't have to. If so, you forked your topic branch off of the
wrong branch at the creation time.

>                                                         so Nicolas can
> rebase them back to next before applying? I did get that piece right,
> didn't I?

I don't rebase topic branches. I apply topics against the good branch
(which should be master) and then _merge_ the topics to the other
branches.

-- 
Nicolas Sebrecht




More information about the OfflineIMAP-project mailing list