Hrm... I really think this is the right time to put the knife, but I suppose you are more concerned about getting a 2.x ready within the next 6 months, which sounds logical. Anyway, as long as development continues and DM advances, I am even ok with sharing .patch files via mail.
On Mon, Apr 20, 2015 at 8:35 PM, Reza Naghibi <[email protected]> wrote: > 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. > > > > > > > > > > > > > >
