Not a big issue. While Reza is on the subject, I thought we might want to give Git a push too. I had survived Subversion in the past, can do again.
On Mon, Apr 20, 2015 at 9:05 PM, Werner Keil <[email protected]> wrote: > Volkan, > > The recent vote though it just had the minimum of 3 PMC members passed, so > it is up to you if you want to accept it of course, but you're eligable of > a committer account (within the time it takes infra, but it shouldn't be 6 > months I assume;-) > > Especially if we have dedicated "modules" (looking at tomcat again, it too > has some very separate parts like "native") and/or some also allow syncing > up with Git, it seems more efficient if some who showed they are dedicated > via patches or JIRA posts for some time (like you did, the "commit" logs > since graduation show everything you posted) plus got the necessary > paperwork are able to commit. Otherwise somebody else always has to pick it > up and commit on their behalf. > Not only using Git there are methods for peer-review like Gerrit, which > even a fairly small team may use as long as there are at least 2-3 people > actively involved. So one can review changes of others. Of course there's > always the release ballot where everyone who votes gets a chance to do the > same. > > Werner > > On Mon, Apr 20, 2015 at 8:41 PM, Volkan Yazıcı <[email protected]> > wrote: > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > >
