devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reza Naghibi <re...@apache.org>
Subject Re: Leaving DeviceMap
Date Mon, 20 Apr 2015 17:30:21 GMT
Bertrand, PMC members, et al,

So I had a few out of thread conversations with people and it turns out a
these people are very committed to DeviceMap and by leaving this project I
would be kind of letting them down. This was never my intention and so Im
willing to take Bertrands offer and apply some kind of code partition
policy.

So here is what I would be willing to work with. I will explain the
standard SVN layout with an addition to accommodate the ODDR branch:

https://svn.apache.org/viewvc/devicemap/

*tags* - this folder is for Apache DeviceMap released snapshots and is
obviously used for archiving and branch sourcing purposes. Any software
that is unreleased under Apache rules will be cleared out.

*branch* - this folder is open to anyone to work on new releases or
experimental features. Just make sure to put your code in a proper sub
directory.

*trunk* - this folder is only for development of currently released
software. If said software is unreleased, then it needs to go into branch
or the ODDR folder. *This will require significant cleanup since we have
the marriage of 1.x and ODDR in here. I repeat, unreleased code and their
dependencies, specifically ODDR will be moved into
their appropriate folders.* When we release a major version, the release
branch and move to trunk and the prior major version will switch to branch
(and tags will be made). This way we can support old and new but trunk will
always be our release head.

*oddr* - we need a separate repo to house ODDR artifacts. Adding a folder
to our SVN root should be enough to accommodate ODDR dev.

The other request I have is agreement on an ODDR name space and version. *Had
I anticipated this situation, our 1.x release would be 2.x, the proposed
2.x would be 3.x, and ODDR could hold the 1.x version. This was a mistake
and that ship has sailed.* My concern is that I dont want currently
released software to be up-revved in repositories and cause package
confusion since we are all sharing the DeviceMap name space. So we need to
properly name and version ODDR so if it does get released and maintained,
it can be done without causing confusion with regard to the 1.x, 2.x, 3.x
release path we seem to be going down. I would be willing to give ODDR the
0.x version space since thats a pretty standard practice. Im open to ideas
here.

Since we dont really have the ability for grainular folder access, I think
we have to ask that if you did not create or work on a particular code
base, ask permission before committing otherwise you can expect your code
to be reverted by the maintainers.

Finally, any sort of marketing or presentations must clearly state the
product (codebase) and version as to not cause product and version
confusion.

If we can all come to agreement here and then implement the SVN changes,
then I would feel very comfortable that we can move this project forward in
a more partitioned fashion.


On Mon, Apr 20, 2015 at 12:51 PM, Werner Keil <werner.keil@gmail.com> wrote:

> It is frustrating to see Reza's personal attacks or lies constantly are
> taken for granted, and simple facts, e.g. stating nothing but facts (I
> don't have the time to dig up all the threads from the archive, but you all
> know about his attempt to destroy pieces of code from the repository and
> also the reasons, so no need to repeat it once again)
> called attacks.
>
> So much for this thread.
>
> It's just off-topic now, too;-)
>
> On Mon, Apr 20, 2015 at 6:44 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org
> > wrote:
>
> > On Mon, Apr 20, 2015 at 6:16 PM, Werner Keil <werner.keil@gmail.com>
> > wrote:
> > > ...Sorry but you know the one who insists to "kill" and wipe out
> > everything he
> > > does not like is Reza....
> >
> > I have already asked you to stop the personal attacks, in a different
> > thread.
> >
> > I consider the above your second violation of this rule today.
> >
> > -Bertrand
> >
>

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