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 <[email protected]> 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 <[email protected]> > 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 < > > [email protected] > > > wrote: > > > > > On Mon, Apr 20, 2015 at 6:16 PM, Werner Keil <[email protected]> > > > 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 > > > > > >
