devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radu Cotescu <r...@apache.org>
Subject Re: Leaving DeviceMap
Date Mon, 20 Apr 2015 11:23:29 GMT
Hi,

Although I haven't had the chance to be more productive / involved in the
project due to other areas of interest, I'm in favour of finding a
compromise solution that would allow both Reza and Werner to continue
working on this project.

IIRC the main problem stems from supporting the W3C DDR Simple API (through
the legacy OpenDDR client) or implementing a new API, more suitable for the
current times. At the same time DeviceMap never claimed to support the DDR
Simple API - instead the goal was to create a data repository and
eventually an API to consume said data. Therefore I *really* don't
understand why we constantly need to argue about this.

Cheers,
Radu

On Mon, 20 Apr 2015 at 13:39 Bertrand Delacretaz <bdelacretaz@apache.org>
wrote:

> On Sun, Apr 19, 2015 at 5:42 PM, Reza Naghibi <rezan@apache.org> wrote:
> > ...Instead of focusing on writing
> > and releasing software, all my time and energy is spent on how to manage
> > Werner....
>
> I think we now have abundant evidence that you and Werner cannot work
> together - evaluating who's right and who's wrong does not help much,
> but maybe we can find a creative solution that would cause you to
> reconsider, at least temporarily.
>
> How about defining a "perimeter" in our code and specs that Werner is
> not allowed to touch or discuss? It can be as simple as a subtree in
> our source code tree, and a wiki subtree.
>
> Combined with a ban (amicable or formal) of email arguments between
> you guys, this might be a workable solution, that we can try for say 3
> months to see if things improve.
>
> That's unusual in an Apache project, and if this team was larger
> things would probably self-regulate, but with such a small team it's
> hard to find a balance without resorting to such artificial barriers.
>
> What do people think?
>
> -Bertrand
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message