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. > >
