[nanomsg] Re: First nanocat release
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: Martin Sustrik <sustrik@xxxxxxxxxx>
- Date: Sat, 31 Aug 2013 14:14:34 +0300
Hi Martin,
On Sat, Aug 31, 2013 at 8:09 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> On 30/08/13 21:21, Paul Colomiets wrote:
>
>> I really think that it must be included to the nanomsg codebase for
>> the following reasons:
>
>
> The rationale you wrote down makes perfect sense.
>
> The reason I am reluctant to bundle additional projects with nanomsg core
> library is that we've actually done that back in days of ZeroMQ 0.x and 1.x.
>
> Back then, all the subprojects, bindings etc. were placed in a single repo.
> It turned out that it wasn't that good idea -- more for procedural, not
> technical reasons.
>
> First, with all projects bundled together, a single bug in whatever
> subproject compromises (psychologically speaking) whole project. It makes
> quality assurance much harder.
>
> Take the example of ZeroMQ bindings. Once I've removed them from the core
> project, the maintenance became much more easy. There are something like 40
> bindings and some of them are broken at any single time. So what? I don't
> care. If they were inside a single repo I would have to ensure that all of
> them are working.
>
> Separating the projects also makes it easier for the maintainers of
> individual sub-projects. They have full commit access, they decide on their
> own development process and finally, they get more credit for being real
> owners of the project.
>
> In institutional terms, having a single project is like having a single
> corporation with many departments, with all the heavy process and
> in-fighting that results in. Having many separate projects is like having
> many small and lean independent companies.
>
Your description is reasonable too. There are few other projects that
had the same mistake. But it's not all vs nothing decision. Sure, all
tools should be kept out of nanomsg repository, except this one.
I doubt it's would be a pain to maintain. It's only 400 lines of
application code (and 900 lines of command-line handling code) using
public API and nn_sleep and nn_clock from compatibility layer. And
this is a first tool that should support any new pattern that would be
added to nanomsg. And I volunteer to do the work anyway.
--
Paul
Other related posts:
