Hi, LGTM. +1.
Cheers, Radu On Mon, 20 Apr 2015 at 21:06 Reza Naghibi <[email protected]> wrote: > Moving this to a clean thread. > > If we can reach agreement here, I will start a [VOTE] thread with all the > details listed out and upon a successful vote, we will implement said > details (and enforce them moving forward). > > Feel free to add any points you think are relevant. As always, refrain from > using names, just technology and practices. > > > On Mon, Apr 20, 2015 at 1: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. > > > > >
