Re: "wireguard" implementation improperly merged and needs revert

["Jason A. Donenfeld" <Jason%zx2c4.com@localhost>]

Hi Taylor,

On Mon, Aug 24, 2020 at 7:28 PM Taylor R Campbell <riastradh%netbsd.org@localhost> wrote:
>
> > Date: Mon, 24 Aug 2020 16:37:36 +0200
> > From: Maxime Villard <max%m00nbsd.net@localhost>
> >
> > Our main tree is cvs, but we are migrating to hg (anonhg.netbsd.org), and
> > also mirror our tree on github. So three options exist, but Taylor will
> > probably know better than me what's the best option.
> >
> > As Manuel said, generally, for subsystems that are small and self-contained,
> > CVS-HEAD is the preferred development branch, which is why wg went there in
> > the first place.
> >
> > But I don't think there is difficulty in moving the code to a separate
> > branch if you like it better there. What do Taylor/Ryota think?
>
> Ozaki-san's wg(4) code was in a git branch for two years.  As the
> NetBSD network stack evolved, the wg(4) git branch was getting stale.
> Having it in HEAD -- but not in any GENERIC kernels -- ensures it at
> least stays tested and visible to anyone working on the network stack,
> but users still have to go out of their way to use it.  This makes it
> less likely to accrue NetBSD-specific bugs, without endorsing it as
> ready for serious deployment.  And reverting and replaying would be a
> big pain for me (not just a matter of `git revert' equivalent, for
> certain technical reasons).
>
> So, it is easy to read your (Jason's) request that we revert the
> commits as the message -- whether you intended it this way or not --
> that you want to parachute in to micromanage how we do development,
> without actually engaging with how we do development first.
>
> That's why you're getting some rather surprised pushback, and multiple
> questions about the technical basis for your objection -- normally if
> there's a dispute requesting a revert, it's over technical grounds
> (and typically only if it affects users who are not going out of their
> way to try experimental features), presented on a public mailing list.
> If the parties don't come to an agreement then they can ask the core
> team for a decision.  But that decision often takes a couple of weeks.
> (Disclosure: I'm on the core team, but I recuse myself from any
> decisions about disputes involving me.)
>
> So it strikes us as weird -- and, perhaps, rude -- that you're asking
> us to urgently revert something that's been kicking around for two
> years,

For the record, the right thing to do would be to have sought input
from the WireGuard project during those two years, which we would have
enthusiastically provided, and maybe NetBSD would have this ready to
go years ago. It strikes the project as rude that you'd write some
halfbaked code and try to pass it off as "wireguard", ruining what to
date has been a uniform experience for users in using WireGuard across
platforms. The fact is, you jumped the gun and didn't reach out beyond
your community.

> I'm still happy to have that discussion!  I am definitely curious to
> hear what whole components are missing from the implementation and, as
> far as I can tell, from your protocol documentation.  But until then,
> I don't think this thread is going anywhere, so I think it would be
> better for us to all just wait until next week to discuss further when
> you have time to go into technical details.  NetBSD 10 is not going to
> be released before then, let alone with wg(4) enabled.

So it sounds like you're unwilling to revert this or move it to a
development branch, for reasons I don't quite understand -- presumably
because of CVS limitations, but I guess it doesn't really matter. So
that means you've lit the so-called fire under my butt to do
everything I can to get this up to snuff before NetBSD 10 ships. I'll
do my best, then. How much time do we have? On the order of 2 or 3
months? A year?

Another question is -- since you're unwilling to revert, will you
still be okay with the situation if we wind up making _big_ changes to
what's there? Or even if we wind up replacing the implementation all
together?

Again, while I'm not happy with this situation and the inflexibility
here, my end goal is probably pretty similar to yours -- to have an
excellent WireGuard implementation on NetBSD. So I'll very willingly
follow your lead on the development processes to make that happen,
whatever they are. "Micromanag[ing]", as you charged, certainly isn't
something I'd like to inadvertently sign up for here.

Jason