[nanomsg] Re: First nanocat release
- From: luca barbato <luca.barbato@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 31 Aug 2013 18:49:07 +0200
On Aug 31, 2013 1:15 PM, "Paul Colomiets" <paul@xxxxxxxxxxxxxx> wrote:
>
> 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.
I prefer having it in tree and I can provide help as usual.
>
> --
> Paul
>
Other related posts:
