devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: Leaving DeviceMap
Date Mon, 20 Apr 2015 18:54:23 GMT
Reza/all,

Sounds reasonable. As Bertrand offered to help with PMC chair duties as
suggested it'll take some administrative burden of you and leave room for
actual development.

I assume "branch" means /branches/
<https://svn.apache.org/viewvc/devicemap/branches/> there is an initial
draft under "2.0" already.
Where you refer to "oddr", where's the "data" in this equation?
Do you mean a combination of data(1.x)+W3C implementation+matching examples?
Everything that currently runs aside from BrowserMap relies on 1.x data.

"browsermap" does in fact show, how a separate folder (even with some
iterative structure, due how it was synced with GitHub) can work. And as
long as dependencies are not corrupted that should not be a problem to
separate the W3C compliant parts from others. OpenDDR stopped the API at
1.0.0.27, hence the first official release here is meant to be  1.1.0, to
show it evolved from a 1.0.x of OpenDDR Java client. So a 0.x "sanctuary"
does not sound appropriate. The major versions of data and clients should
also match. After all data is the "crown jewel" of the project.

Maven separates packages so you already have something like
"org.apache.devicemap:devicemap-client" or
"org.apache.devicemap:devicemap-simpleddr".
Note, the "-client" had releases up to 1.1 so far, on the other hand
browsermap is at 1.4 already, and I guess you don't see any reason to
"grant browsermap the 0.4 version" now all of a sudden?;-)

Except browsermap the major version number should suggest which version of
the data it is  meant for. So a client/classifier that evolves or fixes
some bugs under the 1.0 branch ideally should not step to 2.x but  stick to
a version range of 1.2 or above.

There are no strong feelings anywhere above the OpenDDR "freeze" but to
allow it (should it publish maintenance releases) I prefer a 1.1.x version
space (we don''t normally use 4 digits, so strictly speaking it offers
room, as long as it's a 1.x release since 1.x is also the matching data
version)

If we separated the codebase as suggested, it probably makes more sense to
keep "examples" together with subsequent modules.
See "browsermap" a side-effect could be that some of these could get a Git
mirror like Browsermap, too.

I'm not too biased about some tags, at least those under /tags/data do
however document how things were synced up from ODDR earlier. Neither a
strict /branches or /tags on a top level is practiced e.g. by Tomcat:
http://tomcat.apache.org/svn.html It also does not use an extra
/tags/releases level btw. nor do many other projects e.g. Ivy (just another
example: https://svn.apache.org/viewvc/ant/ivy/core/tags/) Even "-RC" tags
are usually kept, so I don't see a particular harm in any tags we got so
far. They're a snapshot and frozen.

There's no real difference between what Tomcat calls "archive" and our
"contrib" section. This is the only real "attic" as of now, the name is not
too important, but IMHO we should leave things there like other projects do.

Cheers,

Werner

On Mon, Apr 20, 2015 at 7:30 PM, Reza Naghibi <rezan@apache.org> wrote:

> 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