I agree that git should be a part of this project (I cant imaging managing a codebase without it), but im going to go ahead and express my opinion that we should punt the git transition to another time. Pretty much everything we have done up to this point infrastructure wise has been SVN based, so transitioning to git would require significant changes to our processes and I think we would be more successful if we treat it as its own isolated enhancement. I would like to focus on this effort on the task at hand, which is sorting out our codebase and products.
So lets put git on ice and bring it up again in 6 months? On Mon, Apr 20, 2015 at 2:28 PM, Volkan Yazıcı <[email protected]> wrote: > Hello Reza, > > That is a really good plan. I think this will also enable each "party" to > evolve individually. One thing that I really would like to see in this list > is to move to Git, please. > > Best. > > On Mon, Apr 20, 2015 at 8:06 PM, 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. > > > > > > > > >
