Radu, Glad to see some activity also from your side. That is first and foremost my area of interest. OpenDDR created quite some positive momentum after several other Open Source projects either died or got locked away like WURFL in this Area.
Based on code assessment and mutual trust in a joint effort for the greater Good of the commnunity I donated code on behalf of OpenDDR. None of this is outdated or wrong since then, as the WURFL fraction or (oddly;-) Reza repeatedly said. It fully implements the W3C standard. The remaining more popular commercial competitors like DeviceAtlas or DetectRight do so, too. Some offer different APIs, so can WE. Those who don't want to understand it, mainly Reza created a hostile, heated series of flames seeming almost like he's been bribed by the WURFL folks to disrupt and destroy the project?;-O That POM change affects all downstream projects and he didn't bother to adjust them. Not to mention the attempt to "fork " the project, while many examples and "Wiki" like doc pages are still scattered across personal sites (not just his) where it is hard to find them instead of improving the Apache site. If that Git mirror must have a common folder, then naming it "/trunk/browsermap/git" or similar instead of /trunk../trunk would be enough. Ideally SVN tags could be under /tags/browsermap, too alongside other tags?;-) In fact I doubt, a roll-back of a rXxx of yours should destroy those tags I placed with others. There could be a second copy then. Werner Am 14.07.2014 23:43 schrieb "Radu Cotescu" <[email protected]>: > Hi Werner, > > While you're right about having two src folders inside browsermap at > r1543048 (which is totally my fault, as I've used git-svn instead of pure > svn), that alone doesn't justify moving stuff around without asking the > list about it, especially since browsermap was outside of your area of > interest. Even if we don't explicitly use the RTC [2] policy in our project > I do hope that we act accordingly and try to figure out *on_the_list* why > some bits and pieces may not look as we expect them to and collectively > decide on what needs to be changed. > > To solve the browsermap issue I'd would still like you to revert the > changes you had made that affected the browsermap folder, after which I can > clean up the empty folders and add a README file explaining why we have > that confusing folder structure. Part of it is because we're using SVN, but > that's a topic for another time and thread. > > If you're still pointing fingers at Reza (though I really don't understand > what you have against him), he publicly declared on the list multiple times > that he's working on implementing a different API than the proposed W3C DDR > Simple API which means that you should expect to see lots of code changes > for the Java client. Furthermore, the fact that he was preparing a release > didn't mean that we would necessarily release that artifact - that's why we > vote on releasing artifacts. Changing code / repo structure arbitrarily > just before the release doesn't allow us to move forward at all - it just > reflects how immature our project is. > > Regarding ASF's JIRA: create an account at [3] and then ask Bertrand to > add your account to the the DMAP project. > > I expect that a selected crowd like us can do more than flaming and > arguing; maybe release something?! Let's work together rather than against > each other. > > Cheers, > Radu > > [2] - http://www.apache.org/foundation/glossary.html#ReviewThenCommit > [3] - https://issues.apache.org/jira/secure/Dashboard.jspa > > > On Mon, Jul 14, 2014 at 9:23 PM, Werner Keil <[email protected]> > wrote: > >> When I last Saw the SVN structure there was /trunk/browsermap/SRC,... And >> /trunk/browsermap/trunk/SRC. Not sure if both with identical content, but >> they Were there, that alone confusing. >> >> I don't recall Reza asked the list or filed a task for completely >> refactoring the POMs from an OSGi like "org.Apache.DeviceMap.soandso" to a >> simple "soandso". A lot of things were done without a task or ticket, also >> because many of us still can't assign those Tickets properly😕 >> >> Hopefully WE can address that, then you'll find me first to create a >> ticket or similar online item for such changes. >> >> Werner >> Am 14.07.2014 17:56 schrieb "Radu Cotescu" <[email protected]>: >> >> Hi, >>> >>> There were no copies. The browsermap folder only contained what looked >>> like a SVN structure, with all the code in trunk. Nothing was confusing as >>> a README.md file in browsermap/trunk described what was there, albeit there >>> was no explanation for why we had that folder structure. >>> >>> However, that's not a good reason to start moving things around without >>> asking the list about this type of change before actually committing the >>> said changes. >>> >>> Cheers, >>> Radu >>> >>> P.S.: Still waiting for that revert. I don't think it's fair to ask >>> somebody else to repair what you (accidentally) broke >>> On Jul 14, 2014 6:32 PM, "Werner Keil" <[email protected]> wrote: >>> >>>> Even if Radu needed the old glitch to fix the configuration, please >>>> promise to fix that in a timely manner so the "perpetual trunk" can be >>>> permanently resolved. >>>> >>>> People on conferences or Twitter tell me a lot, they find DeviceMap >>>> hard to understand. And who can blame them, if there's a /trunk/browsermap >>>> and an exact copy of that in /trunk/browsermap/trunk, but only the latter >>>> is mirrored to Git?;-O >>>> >>>> Werner >>>> Am 14.07.2014 16:34 schrieb "Bertrand Delacretaz" < >>>> [email protected]>: >>>> >>>>> Hi, >>>>> >>>>> On Mon, Jul 14, 2014 at 4:05 PM, Werner Keil <[email protected]> >>>>> wrote: >>>>> > ...Will see what I can do. There was however a very mean and >>>>> redundant >>>>> > duplication of code kind of like /trunk/browsermap/trunk... >>>>> >>>>> For now, please just revert your commits as Radu asked for - reverting >>>>> shouldn't take more than a few minutes so that >>>>> https://github.com/apache/devicemap-browsermap/ comes back to life, >>>>> and we can always discuss changes later. >>>>> >>>>> -Bertrand >>>>> >>>> >
