[DISCUSS] SVN, versioning, and namespace

[Reza Naghibi <re...@apache.org>]

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 <re...@apache.org> 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.
>
>

Re: [DISCUSS] SVN, versioning, and namespace

[Radu Cotescu <ra...@apache.org>]

Hi,

LGTM. +1.

Cheers,
Radu

On Mon, 20 Apr 2015 at 21:06 Reza Naghibi <re...@apache.org> 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 <re...@apache.org> 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.
> >
> >
>

Re: [DISCUSS] SVN, versioning, and namespace

[Werner Keil <we...@gmail.com>]

Actually though we did not make an effort to release the examples, if
you're really serious about W3C DDR support rather than viewing it as a
threat or competition, it just should not matter if you take implementation
A, B or C.

The test is totally implementation neutral, it imports nothing other than
the 2 DDR packages.
Thus with practically no major change a line like

 initializationProperties.load(context.getResourceAsStream("WEB-INF/classes/oddr.properties"));
        identificationService =
ServiceFactory.newService("org.apache.devicemap.simpleddr.DDRService",
initializationProperties.getProperty(DDRService.ODDR_VOCABULARY_IRI),

from one of the 2 DDR examples can be parameterized so that necessary
arguments are configured via say web.xml. And any truly compliant
implementation will work.
So does migration from vendors like DeviceAtlas, etc. if either the vendor
no longer supports their products, shuts it away (like WURFL) or went
bankrupt. It all happens, and there are plenty of vendors out there. They
don't care, whether "Reza wrote this", Werner, Bertrand or anybody else.

If it's W3C compliant it'll work and they could replace their existing DDR
with little or no code changes, see the 2-3 lines above.

Werner

On Tue, Apr 21, 2015 at 12:37 AM, Werner Keil <we...@gmail.com> wrote:

> There is or at least should be an "exploded" data too btw.
> Unfortunately right now, the http://devicemap-vm.apache.org/data/
> contains 2 identical copies of the 1.0.1 data, while the 1.0.2 folder is
> empty and therefore would just result in errors if a client tried to use it.
>
> Whether you don't care about even the .NET client (which now uses this
> /latest) or others out there, you cannot force everyone to switch to
> something that as of now doesn't even exist. It's an empty structure, so
> without a proper migration tool it is not going to be of any value.
>
> Thus it makes sense to have at least a 1.x and (whenever that is ready)
> 2.x in such folder. The "download" section will always provide existing
> versions of data and so far published software artifacts.
>
> The wording like "my data" or "your branch" is pretty self-unveiling, it
> sounds like Golum in LOTY "My precious" where a proper attitude for an open
> source effort should be "our team". Data that's released is out there.
> After "your rogue changes" to 1.0.0 data broke it, both 1.0.1 and 1.0.2
> data are OK and so far the complete W3C DDR Simple implementation does not
> rely on an external URL or JAR, so if I was just interested in "My client"
> or "My data" that's set, but I also care about different environments and
> platforms that work so people have a choice (somewhere close to what
> commercial closed source vendors offer, or as good as the limited resources
> allow it here)
>
> I doubt the 1.0 "bridge" is really compatible with W3C DDR Simple, as it's
> not just about implementing an interface or two in that JAR.
> The official TCK for the W3C DDR Simple API is here:
> http://www.w3.org/2005/MWI/DDWG/drafts/api/simple/java/src/test/.
> There's a copy of the test here, too:
> https://svn.apache.org/viewvc/devicemap/trunk/devicemap/java/simpleddr/src/test/java/
> It's not a JUnit or similar test though, check out the source and How the
> test bed calls it there. In theory the result of getReport() which is the
> essense of the tests could be put inside a JUnit tests running assertions
> against that result. The test itself is as provided by W3C, it must not be
> tweaked or "improved", that's how they tested several other implementations
> like DeviceAtlas, MaDDR and others before. If you get this test to pass
> then you may call the bridge around Classifier W3C compliant. It has
> nothing to do with "me accepting it", the test has to.
>
> Werner
>
> On Tue, Apr 21, 2015 at 12:00 AM, Reza Naghibi <re...@apache.org> wrote:
>
>> So I will try and response to this as best as possible:
>>
>> -Browsermap has nothing to do with this.
>>
>> -There are 2 full W3C DDR solutions, ODDR and 1.x. If you dont accept the
>> 1.x W3C solution, so be it. Just another reason we need to split the repo
>> and releases since we are seeing this world differently.
>>
>>
>> https://svn.apache.org/viewvc/devicemap/trunk/devicemap/java/classifier_w3c_simple/
>>
>> -Your right about the namespace, everything does start with
>> org.apache.devicemap (for clients that support namespaces). My point is
>> that anything based on ODDR needs to have an ODDR tag in the namespace,
>> name, release name, release repo, whatever. It just needs to be named with
>> something unique to the client so it doesnt get confused with the 1.x Java
>> client.
>>
>> -Sorry, but just because im doing the data releases doesnt force me to
>> support your work or any number of clients. Anyone is free to maintain and
>> release their own data. I do it because no one else is doing it. I have 1
>> more 1.x data release planned and if it works with ODDR, great. It
>> probably
>> will. But once 2.x gets released, im not planning on releasing anymore XML
>> based ODDR data. You are more than welcome to backport the 2.x data to
>> ODDR
>> format and release however you wish. *Blocking my data work to support
>> your
>> branch is a non starter.*
>>
>> So im still not seeing whats the point of this argument. You are not
>> bringing any solutions to the table, just once again opposing me for the
>> sake of arguing. The proposal is that we partition our work into different
>> repos/releases/codebases. This was proposed by Bertrand, Radu is already
>> on
>> board. I am on board. Once I hear from Eberhard, thats pretty much enough
>> to move forward with something votable.
>>
>>
>> On Mon, Apr 20, 2015 at 4:52 PM, Werner Keil <we...@gmail.com>
>> wrote:
>>
>> > Well I can only tell what works for BrowserMap and there is no reason to
>> > handle this differently here.
>> > there is no "2 products" and there is just one full W3C DDR
>> implementation
>> > (leaving the partial "classifier_w3c_simple" test balloon aside that I
>> > don't know whether you'll do anyting with this or not)
>> >
>> > Everything in the Devicemap project is supposed to start with
>> > "org.apache.devicemap" if you like to work outside that, Bertrand
>> outlined
>> > that before. Being responsible for the major portion of the data and a
>> > proper committer to proper artifacts, there is no reason to do any
>> > ridiculous "sandboxing" or defranchising of the W3C compliant artifacts
>> > just because some (or just one) in the team hate or don't undertand
>> them.
>> > It is as simple as every other project, be it Logging, Tomcat, all of
>> these
>> > have multiple streams of development that e.g. between Tomcat 6, 7 or 8
>> are
>> > totally isolated against each other.
>> >
>> > The CI servers grant proper stability. And just look at the current
>> single
>> > instance, the results show what's stable.
>> > Everyone, including yourself voted +1 of a strategy for W3C DDR, API you
>> > remember.
>> > This wasn't just for fun or to waste our times, it was meant to help any
>> > W3C DDR implementation. Doing so in a more isolated module sounds OK,
>> but
>> > that's about it.
>> > Who can help and fix say the bugs of the .NET client does so. It may
>> not be
>> > so widely used, but fixing the problem of the wrong data URL (directly
>> from
>> > SVN which at the time must have been the only place, so Eberhard isn't
>> > really to blame;-) helped to make the .NET consoles work. Maybe not
>> > everyone would have spotted it, not everyone also uses Visual Studio,
>> but
>> > what counts is working software that allows users to detect their
>> devices
>> > properly.
>> >
>> > That's how it looks and based on how Browsermap does this we could make
>> it
>> > work, but not some non-Apache pseudo world, if you understood it that
>> way,
>> > please check again.
>> >
>> > Cheers,
>> >
>> > Werner
>> >
>> > On Mon, Apr 20, 2015 at 10:17 PM, Reza Naghibi <re...@apache.org>
>> wrote:
>> >
>> > > Werner,
>> > >
>> > > I believe your understanding of this is different that mine. Im saying
>> > this
>> > > as politely as possible, but my understanding is that you and me share
>> > > nothing moving forward. This includes code and releases.
>> > >
>> > > Since your focus is on ODDR, we move all ODDR artifacts to a separate
>> SVN
>> > > and you do whatever you want there. You do not touch or commit code to
>> > any
>> > > 1.x or 2.x SVN repo. This includes tags and branch. Even when you
>> > release,
>> > > you maintain that release in your ODDR repo. Its important that client
>> > > maintainers get isolation from rogue commits.
>> > >
>> > > So ODDR will have branched data and any future release of device data
>> > will
>> > > be done with no concern for ODDR. This is very important. 1.x now
>> > functions
>> > > independently of ODDR. Obviously 2.x will be completely different
>> > product.
>> > >
>> > > You can work on new code in /branches, but said code needs a vote for
>> > > anything to happen.
>> > >
>> > > The stipulation here is that you work under a different name space and
>> > > version. ODDR is an acceptable namespace string. We need to agree on
>> > > version.
>> > >
>> > > So, if we reach agreement and vote on this measure passes, from that
>> > point
>> > > forward, we should have zero interaction other than Apache required
>> > voting.
>> > >
>> > > Also, FYI, since 1.x and ODDR support W3C Simple DDR, you need to be
>> more
>> > > specific when you mention W3C since you are potentially talking about
>> 2
>> > > products.
>> > >
>> > > On Mon, Apr 20, 2015 at 3:19 PM, Werner Keil <we...@gmail.com>
>> > > wrote:
>> > >
>> > > > Yes,
>> > > >
>> > > > Though they were not released there are nevertheless a number of
>> > > examples.
>> > > > All currently under the "org.apache.devicemap.examples" namespace
>> > (which
>> > > is
>> > > > what many projects do, Sling or DeltaSpike included)
>> > > > At leasts the 2 instances running on URLs like
>> > > > http://devicemap-vm.apache.org/dmap-spring/ match 2 of these exampe
>> > > > projects.
>> > > >
>> > > > Whether  or not there was a different structure, since they were not
>> > > > officially released yet, we seem free. I don't see great harm in the
>> > > > /tags/examples tag as mentioned. It marks a stable RC1 snapshot of
>> what
>> > > > could become a joint "examples-1.0.0" release. Unless we prefer to
>> > > further
>> > > > disect them, but that does not make a 1.0-RC1 worthless. It matches
>> > what
>> > > > runs on the VM for example;-)
>> > > >
>> > > > With few exceptions btw, the 0.x version space was for incubating
>> > > projects.
>> > > > Hence and since others like Browsermap (or the W3C impl) had a
>> longer
>> > > > history some version numbers were already higher before graduation.
>> > > >
>> > > > Generally the idea of a "sandbox" similar to DeltaSpike, Tomcat or
>> > Tamaya
>> > > > sounds worth exploring.
>> > > > This would be an area for 0.x kind of artifacts. And "playground".
>> I am
>> > > not
>> > > > sure, if it was a good idea to have an entire branch for that, but
>> open
>> > > to
>> > > > ideas.
>> > > > Earlier efforts like the Sling demo Radu worked on some while ago
>> could
>> > > be
>> > > > good in such "sandbox" (at JavaMoney we called it "shelter"
>> inspired by
>> > > the
>> > > > "Adopt-a-JSR" program and there's been some great progress in such a
>> > > > sandbox, e.g. Groovy support, Digital Currencies, etc.)
>> > > >
>> > > > Werner
>> > > >
>> > > > On Mon, Apr 20, 2015 at 8:15 PM, Reza Naghibi <re...@apache.org>
>> > wrote:
>> > > >
>> > > > > Also, as far as I am aware, we only have 4 officially released
>> > > artifacts:
>> > > > >
>> > > > > -data
>> > > > > -java client
>> > > > > -.NET client (its not on the website but im certain we did a VOTE)
>> > > > > -browsermap (javascript) client
>> > > > >
>> > > > > All artifacts are all versioned in 1.x.
>> > > > >
>> > > > > On Mon, Apr 20, 2015 at 2:06 PM, Reza Naghibi <re...@apache.org>
>> > > 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 <rezan@apache.org
>> >
>> > > > 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.
>> > > > > >>
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: [DISCUSS] SVN, versioning, and namespace

[Werner Keil <we...@gmail.com>]

There is or at least should be an "exploded" data too btw.
Unfortunately right now, the http://devicemap-vm.apache.org/data/ contains
2 identical copies of the 1.0.1 data, while the 1.0.2 folder is empty and
therefore would just result in errors if a client tried to use it.

Whether you don't care about even the .NET client (which now uses this
/latest) or others out there, you cannot force everyone to switch to
something that as of now doesn't even exist. It's an empty structure, so
without a proper migration tool it is not going to be of any value.

Thus it makes sense to have at least a 1.x and (whenever that is ready) 2.x
in such folder. The "download" section will always provide existing
versions of data and so far published software artifacts.

The wording like "my data" or "your branch" is pretty self-unveiling, it
sounds like Golum in LOTY "My precious" where a proper attitude for an open
source effort should be "our team". Data that's released is out there.
After "your rogue changes" to 1.0.0 data broke it, both 1.0.1 and 1.0.2
data are OK and so far the complete W3C DDR Simple implementation does not
rely on an external URL or JAR, so if I was just interested in "My client"
or "My data" that's set, but I also care about different environments and
platforms that work so people have a choice (somewhere close to what
commercial closed source vendors offer, or as good as the limited resources
allow it here)

I doubt the 1.0 "bridge" is really compatible with W3C DDR Simple, as it's
not just about implementing an interface or two in that JAR.
The official TCK for the W3C DDR Simple API is here:
http://www.w3.org/2005/MWI/DDWG/drafts/api/simple/java/src/test/.
There's a copy of the test here, too:
https://svn.apache.org/viewvc/devicemap/trunk/devicemap/java/simpleddr/src/test/java/
It's not a JUnit or similar test though, check out the source and How the
test bed calls it there. In theory the result of getReport() which is the
essense of the tests could be put inside a JUnit tests running assertions
against that result. The test itself is as provided by W3C, it must not be
tweaked or "improved", that's how they tested several other implementations
like DeviceAtlas, MaDDR and others before. If you get this test to pass
then you may call the bridge around Classifier W3C compliant. It has
nothing to do with "me accepting it", the test has to.

Werner

On Tue, Apr 21, 2015 at 12:00 AM, Reza Naghibi <re...@apache.org> wrote:

> So I will try and response to this as best as possible:
>
> -Browsermap has nothing to do with this.
>
> -There are 2 full W3C DDR solutions, ODDR and 1.x. If you dont accept the
> 1.x W3C solution, so be it. Just another reason we need to split the repo
> and releases since we are seeing this world differently.
>
>
> https://svn.apache.org/viewvc/devicemap/trunk/devicemap/java/classifier_w3c_simple/
>
> -Your right about the namespace, everything does start with
> org.apache.devicemap (for clients that support namespaces). My point is
> that anything based on ODDR needs to have an ODDR tag in the namespace,
> name, release name, release repo, whatever. It just needs to be named with
> something unique to the client so it doesnt get confused with the 1.x Java
> client.
>
> -Sorry, but just because im doing the data releases doesnt force me to
> support your work or any number of clients. Anyone is free to maintain and
> release their own data. I do it because no one else is doing it. I have 1
> more 1.x data release planned and if it works with ODDR, great. It probably
> will. But once 2.x gets released, im not planning on releasing anymore XML
> based ODDR data. You are more than welcome to backport the 2.x data to ODDR
> format and release however you wish. *Blocking my data work to support your
> branch is a non starter.*
>
> So im still not seeing whats the point of this argument. You are not
> bringing any solutions to the table, just once again opposing me for the
> sake of arguing. The proposal is that we partition our work into different
> repos/releases/codebases. This was proposed by Bertrand, Radu is already on
> board. I am on board. Once I hear from Eberhard, thats pretty much enough
> to move forward with something votable.
>
>
> On Mon, Apr 20, 2015 at 4:52 PM, Werner Keil <we...@gmail.com>
> wrote:
>
> > Well I can only tell what works for BrowserMap and there is no reason to
> > handle this differently here.
> > there is no "2 products" and there is just one full W3C DDR
> implementation
> > (leaving the partial "classifier_w3c_simple" test balloon aside that I
> > don't know whether you'll do anyting with this or not)
> >
> > Everything in the Devicemap project is supposed to start with
> > "org.apache.devicemap" if you like to work outside that, Bertrand
> outlined
> > that before. Being responsible for the major portion of the data and a
> > proper committer to proper artifacts, there is no reason to do any
> > ridiculous "sandboxing" or defranchising of the W3C compliant artifacts
> > just because some (or just one) in the team hate or don't undertand them.
> > It is as simple as every other project, be it Logging, Tomcat, all of
> these
> > have multiple streams of development that e.g. between Tomcat 6, 7 or 8
> are
> > totally isolated against each other.
> >
> > The CI servers grant proper stability. And just look at the current
> single
> > instance, the results show what's stable.
> > Everyone, including yourself voted +1 of a strategy for W3C DDR, API you
> > remember.
> > This wasn't just for fun or to waste our times, it was meant to help any
> > W3C DDR implementation. Doing so in a more isolated module sounds OK, but
> > that's about it.
> > Who can help and fix say the bugs of the .NET client does so. It may not
> be
> > so widely used, but fixing the problem of the wrong data URL (directly
> from
> > SVN which at the time must have been the only place, so Eberhard isn't
> > really to blame;-) helped to make the .NET consoles work. Maybe not
> > everyone would have spotted it, not everyone also uses Visual Studio, but
> > what counts is working software that allows users to detect their devices
> > properly.
> >
> > That's how it looks and based on how Browsermap does this we could make
> it
> > work, but not some non-Apache pseudo world, if you understood it that
> way,
> > please check again.
> >
> > Cheers,
> >
> > Werner
> >
> > On Mon, Apr 20, 2015 at 10:17 PM, Reza Naghibi <re...@apache.org> wrote:
> >
> > > Werner,
> > >
> > > I believe your understanding of this is different that mine. Im saying
> > this
> > > as politely as possible, but my understanding is that you and me share
> > > nothing moving forward. This includes code and releases.
> > >
> > > Since your focus is on ODDR, we move all ODDR artifacts to a separate
> SVN
> > > and you do whatever you want there. You do not touch or commit code to
> > any
> > > 1.x or 2.x SVN repo. This includes tags and branch. Even when you
> > release,
> > > you maintain that release in your ODDR repo. Its important that client
> > > maintainers get isolation from rogue commits.
> > >
> > > So ODDR will have branched data and any future release of device data
> > will
> > > be done with no concern for ODDR. This is very important. 1.x now
> > functions
> > > independently of ODDR. Obviously 2.x will be completely different
> > product.
> > >
> > > You can work on new code in /branches, but said code needs a vote for
> > > anything to happen.
> > >
> > > The stipulation here is that you work under a different name space and
> > > version. ODDR is an acceptable namespace string. We need to agree on
> > > version.
> > >
> > > So, if we reach agreement and vote on this measure passes, from that
> > point
> > > forward, we should have zero interaction other than Apache required
> > voting.
> > >
> > > Also, FYI, since 1.x and ODDR support W3C Simple DDR, you need to be
> more
> > > specific when you mention W3C since you are potentially talking about 2
> > > products.
> > >
> > > On Mon, Apr 20, 2015 at 3:19 PM, Werner Keil <we...@gmail.com>
> > > wrote:
> > >
> > > > Yes,
> > > >
> > > > Though they were not released there are nevertheless a number of
> > > examples.
> > > > All currently under the "org.apache.devicemap.examples" namespace
> > (which
> > > is
> > > > what many projects do, Sling or DeltaSpike included)
> > > > At leasts the 2 instances running on URLs like
> > > > http://devicemap-vm.apache.org/dmap-spring/ match 2 of these exampe
> > > > projects.
> > > >
> > > > Whether  or not there was a different structure, since they were not
> > > > officially released yet, we seem free. I don't see great harm in the
> > > > /tags/examples tag as mentioned. It marks a stable RC1 snapshot of
> what
> > > > could become a joint "examples-1.0.0" release. Unless we prefer to
> > > further
> > > > disect them, but that does not make a 1.0-RC1 worthless. It matches
> > what
> > > > runs on the VM for example;-)
> > > >
> > > > With few exceptions btw, the 0.x version space was for incubating
> > > projects.
> > > > Hence and since others like Browsermap (or the W3C impl) had a longer
> > > > history some version numbers were already higher before graduation.
> > > >
> > > > Generally the idea of a "sandbox" similar to DeltaSpike, Tomcat or
> > Tamaya
> > > > sounds worth exploring.
> > > > This would be an area for 0.x kind of artifacts. And "playground". I
> am
> > > not
> > > > sure, if it was a good idea to have an entire branch for that, but
> open
> > > to
> > > > ideas.
> > > > Earlier efforts like the Sling demo Radu worked on some while ago
> could
> > > be
> > > > good in such "sandbox" (at JavaMoney we called it "shelter" inspired
> by
> > > the
> > > > "Adopt-a-JSR" program and there's been some great progress in such a
> > > > sandbox, e.g. Groovy support, Digital Currencies, etc.)
> > > >
> > > > Werner
> > > >
> > > > On Mon, Apr 20, 2015 at 8:15 PM, Reza Naghibi <re...@apache.org>
> > wrote:
> > > >
> > > > > Also, as far as I am aware, we only have 4 officially released
> > > artifacts:
> > > > >
> > > > > -data
> > > > > -java client
> > > > > -.NET client (its not on the website but im certain we did a VOTE)
> > > > > -browsermap (javascript) client
> > > > >
> > > > > All artifacts are all versioned in 1.x.
> > > > >
> > > > > On Mon, Apr 20, 2015 at 2:06 PM, Reza Naghibi <re...@apache.org>
> > > 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 <re...@apache.org>
> > > > 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.
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] SVN, versioning, and namespace

[Reza Naghibi <re...@apache.org>]

So I will try and response to this as best as possible:

-Browsermap has nothing to do with this.

-There are 2 full W3C DDR solutions, ODDR and 1.x. If you dont accept the
1.x W3C solution, so be it. Just another reason we need to split the repo
and releases since we are seeing this world differently.

https://svn.apache.org/viewvc/devicemap/trunk/devicemap/java/classifier_w3c_simple/

-Your right about the namespace, everything does start with
org.apache.devicemap (for clients that support namespaces). My point is
that anything based on ODDR needs to have an ODDR tag in the namespace,
name, release name, release repo, whatever. It just needs to be named with
something unique to the client so it doesnt get confused with the 1.x Java
client.

-Sorry, but just because im doing the data releases doesnt force me to
support your work or any number of clients. Anyone is free to maintain and
release their own data. I do it because no one else is doing it. I have 1
more 1.x data release planned and if it works with ODDR, great. It probably
will. But once 2.x gets released, im not planning on releasing anymore XML
based ODDR data. You are more than welcome to backport the 2.x data to ODDR
format and release however you wish. *Blocking my data work to support your
branch is a non starter.*

So im still not seeing whats the point of this argument. You are not
bringing any solutions to the table, just once again opposing me for the
sake of arguing. The proposal is that we partition our work into different
repos/releases/codebases. This was proposed by Bertrand, Radu is already on
board. I am on board. Once I hear from Eberhard, thats pretty much enough
to move forward with something votable.


On Mon, Apr 20, 2015 at 4:52 PM, Werner Keil <we...@gmail.com> wrote:

> Well I can only tell what works for BrowserMap and there is no reason to
> handle this differently here.
> there is no "2 products" and there is just one full W3C DDR implementation
> (leaving the partial "classifier_w3c_simple" test balloon aside that I
> don't know whether you'll do anyting with this or not)
>
> Everything in the Devicemap project is supposed to start with
> "org.apache.devicemap" if you like to work outside that, Bertrand outlined
> that before. Being responsible for the major portion of the data and a
> proper committer to proper artifacts, there is no reason to do any
> ridiculous "sandboxing" or defranchising of the W3C compliant artifacts
> just because some (or just one) in the team hate or don't undertand them.
> It is as simple as every other project, be it Logging, Tomcat, all of these
> have multiple streams of development that e.g. between Tomcat 6, 7 or 8 are
> totally isolated against each other.
>
> The CI servers grant proper stability. And just look at the current single
> instance, the results show what's stable.
> Everyone, including yourself voted +1 of a strategy for W3C DDR, API you
> remember.
> This wasn't just for fun or to waste our times, it was meant to help any
> W3C DDR implementation. Doing so in a more isolated module sounds OK, but
> that's about it.
> Who can help and fix say the bugs of the .NET client does so. It may not be
> so widely used, but fixing the problem of the wrong data URL (directly from
> SVN which at the time must have been the only place, so Eberhard isn't
> really to blame;-) helped to make the .NET consoles work. Maybe not
> everyone would have spotted it, not everyone also uses Visual Studio, but
> what counts is working software that allows users to detect their devices
> properly.
>
> That's how it looks and based on how Browsermap does this we could make it
> work, but not some non-Apache pseudo world, if you understood it that way,
> please check again.
>
> Cheers,
>
> Werner
>
> On Mon, Apr 20, 2015 at 10:17 PM, Reza Naghibi <re...@apache.org> wrote:
>
> > Werner,
> >
> > I believe your understanding of this is different that mine. Im saying
> this
> > as politely as possible, but my understanding is that you and me share
> > nothing moving forward. This includes code and releases.
> >
> > Since your focus is on ODDR, we move all ODDR artifacts to a separate SVN
> > and you do whatever you want there. You do not touch or commit code to
> any
> > 1.x or 2.x SVN repo. This includes tags and branch. Even when you
> release,
> > you maintain that release in your ODDR repo. Its important that client
> > maintainers get isolation from rogue commits.
> >
> > So ODDR will have branched data and any future release of device data
> will
> > be done with no concern for ODDR. This is very important. 1.x now
> functions
> > independently of ODDR. Obviously 2.x will be completely different
> product.
> >
> > You can work on new code in /branches, but said code needs a vote for
> > anything to happen.
> >
> > The stipulation here is that you work under a different name space and
> > version. ODDR is an acceptable namespace string. We need to agree on
> > version.
> >
> > So, if we reach agreement and vote on this measure passes, from that
> point
> > forward, we should have zero interaction other than Apache required
> voting.
> >
> > Also, FYI, since 1.x and ODDR support W3C Simple DDR, you need to be more
> > specific when you mention W3C since you are potentially talking about 2
> > products.
> >
> > On Mon, Apr 20, 2015 at 3:19 PM, Werner Keil <we...@gmail.com>
> > wrote:
> >
> > > Yes,
> > >
> > > Though they were not released there are nevertheless a number of
> > examples.
> > > All currently under the "org.apache.devicemap.examples" namespace
> (which
> > is
> > > what many projects do, Sling or DeltaSpike included)
> > > At leasts the 2 instances running on URLs like
> > > http://devicemap-vm.apache.org/dmap-spring/ match 2 of these exampe
> > > projects.
> > >
> > > Whether  or not there was a different structure, since they were not
> > > officially released yet, we seem free. I don't see great harm in the
> > > /tags/examples tag as mentioned. It marks a stable RC1 snapshot of what
> > > could become a joint "examples-1.0.0" release. Unless we prefer to
> > further
> > > disect them, but that does not make a 1.0-RC1 worthless. It matches
> what
> > > runs on the VM for example;-)
> > >
> > > With few exceptions btw, the 0.x version space was for incubating
> > projects.
> > > Hence and since others like Browsermap (or the W3C impl) had a longer
> > > history some version numbers were already higher before graduation.
> > >
> > > Generally the idea of a "sandbox" similar to DeltaSpike, Tomcat or
> Tamaya
> > > sounds worth exploring.
> > > This would be an area for 0.x kind of artifacts. And "playground". I am
> > not
> > > sure, if it was a good idea to have an entire branch for that, but open
> > to
> > > ideas.
> > > Earlier efforts like the Sling demo Radu worked on some while ago could
> > be
> > > good in such "sandbox" (at JavaMoney we called it "shelter" inspired by
> > the
> > > "Adopt-a-JSR" program and there's been some great progress in such a
> > > sandbox, e.g. Groovy support, Digital Currencies, etc.)
> > >
> > > Werner
> > >
> > > On Mon, Apr 20, 2015 at 8:15 PM, Reza Naghibi <re...@apache.org>
> wrote:
> > >
> > > > Also, as far as I am aware, we only have 4 officially released
> > artifacts:
> > > >
> > > > -data
> > > > -java client
> > > > -.NET client (its not on the website but im certain we did a VOTE)
> > > > -browsermap (javascript) client
> > > >
> > > > All artifacts are all versioned in 1.x.
> > > >
> > > > On Mon, Apr 20, 2015 at 2:06 PM, Reza Naghibi <re...@apache.org>
> > 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 <re...@apache.org>
> > > 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.
> > > > >>
> > > > >>
> > > >
> > >
> >
>

Re: [DISCUSS] SVN, versioning, and namespace

[Werner Keil <we...@gmail.com>]

Well I can only tell what works for BrowserMap and there is no reason to
handle this differently here.
there is no "2 products" and there is just one full W3C DDR implementation
(leaving the partial "classifier_w3c_simple" test balloon aside that I
don't know whether you'll do anyting with this or not)

Everything in the Devicemap project is supposed to start with
"org.apache.devicemap" if you like to work outside that, Bertrand outlined
that before. Being responsible for the major portion of the data and a
proper committer to proper artifacts, there is no reason to do any
ridiculous "sandboxing" or defranchising of the W3C compliant artifacts
just because some (or just one) in the team hate or don't undertand them.
It is as simple as every other project, be it Logging, Tomcat, all of these
have multiple streams of development that e.g. between Tomcat 6, 7 or 8 are
totally isolated against each other.

The CI servers grant proper stability. And just look at the current single
instance, the results show what's stable.
Everyone, including yourself voted +1 of a strategy for W3C DDR, API you
remember.
This wasn't just for fun or to waste our times, it was meant to help any
W3C DDR implementation. Doing so in a more isolated module sounds OK, but
that's about it.
Who can help and fix say the bugs of the .NET client does so. It may not be
so widely used, but fixing the problem of the wrong data URL (directly from
SVN which at the time must have been the only place, so Eberhard isn't
really to blame;-) helped to make the .NET consoles work. Maybe not
everyone would have spotted it, not everyone also uses Visual Studio, but
what counts is working software that allows users to detect their devices
properly.

That's how it looks and based on how Browsermap does this we could make it
work, but not some non-Apache pseudo world, if you understood it that way,
please check again.

Cheers,

Werner

On Mon, Apr 20, 2015 at 10:17 PM, Reza Naghibi <re...@apache.org> wrote:

> Werner,
>
> I believe your understanding of this is different that mine. Im saying this
> as politely as possible, but my understanding is that you and me share
> nothing moving forward. This includes code and releases.
>
> Since your focus is on ODDR, we move all ODDR artifacts to a separate SVN
> and you do whatever you want there. You do not touch or commit code to any
> 1.x or 2.x SVN repo. This includes tags and branch. Even when you release,
> you maintain that release in your ODDR repo. Its important that client
> maintainers get isolation from rogue commits.
>
> So ODDR will have branched data and any future release of device data will
> be done with no concern for ODDR. This is very important. 1.x now functions
> independently of ODDR. Obviously 2.x will be completely different product.
>
> You can work on new code in /branches, but said code needs a vote for
> anything to happen.
>
> The stipulation here is that you work under a different name space and
> version. ODDR is an acceptable namespace string. We need to agree on
> version.
>
> So, if we reach agreement and vote on this measure passes, from that point
> forward, we should have zero interaction other than Apache required voting.
>
> Also, FYI, since 1.x and ODDR support W3C Simple DDR, you need to be more
> specific when you mention W3C since you are potentially talking about 2
> products.
>
> On Mon, Apr 20, 2015 at 3:19 PM, Werner Keil <we...@gmail.com>
> wrote:
>
> > Yes,
> >
> > Though they were not released there are nevertheless a number of
> examples.
> > All currently under the "org.apache.devicemap.examples" namespace (which
> is
> > what many projects do, Sling or DeltaSpike included)
> > At leasts the 2 instances running on URLs like
> > http://devicemap-vm.apache.org/dmap-spring/ match 2 of these exampe
> > projects.
> >
> > Whether  or not there was a different structure, since they were not
> > officially released yet, we seem free. I don't see great harm in the
> > /tags/examples tag as mentioned. It marks a stable RC1 snapshot of what
> > could become a joint "examples-1.0.0" release. Unless we prefer to
> further
> > disect them, but that does not make a 1.0-RC1 worthless. It matches what
> > runs on the VM for example;-)
> >
> > With few exceptions btw, the 0.x version space was for incubating
> projects.
> > Hence and since others like Browsermap (or the W3C impl) had a longer
> > history some version numbers were already higher before graduation.
> >
> > Generally the idea of a "sandbox" similar to DeltaSpike, Tomcat or Tamaya
> > sounds worth exploring.
> > This would be an area for 0.x kind of artifacts. And "playground". I am
> not
> > sure, if it was a good idea to have an entire branch for that, but open
> to
> > ideas.
> > Earlier efforts like the Sling demo Radu worked on some while ago could
> be
> > good in such "sandbox" (at JavaMoney we called it "shelter" inspired by
> the
> > "Adopt-a-JSR" program and there's been some great progress in such a
> > sandbox, e.g. Groovy support, Digital Currencies, etc.)
> >
> > Werner
> >
> > On Mon, Apr 20, 2015 at 8:15 PM, Reza Naghibi <re...@apache.org> wrote:
> >
> > > Also, as far as I am aware, we only have 4 officially released
> artifacts:
> > >
> > > -data
> > > -java client
> > > -.NET client (its not on the website but im certain we did a VOTE)
> > > -browsermap (javascript) client
> > >
> > > All artifacts are all versioned in 1.x.
> > >
> > > On Mon, Apr 20, 2015 at 2:06 PM, Reza Naghibi <re...@apache.org>
> 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 <re...@apache.org>
> > 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.
> > > >>
> > > >>
> > >
> >
>

Re: [DISCUSS] SVN, versioning, and namespace

[Reza Naghibi <re...@apache.org>]

Werner,

I believe your understanding of this is different that mine. Im saying this
as politely as possible, but my understanding is that you and me share
nothing moving forward. This includes code and releases.

Since your focus is on ODDR, we move all ODDR artifacts to a separate SVN
and you do whatever you want there. You do not touch or commit code to any
1.x or 2.x SVN repo. This includes tags and branch. Even when you release,
you maintain that release in your ODDR repo. Its important that client
maintainers get isolation from rogue commits.

So ODDR will have branched data and any future release of device data will
be done with no concern for ODDR. This is very important. 1.x now functions
independently of ODDR. Obviously 2.x will be completely different product.

You can work on new code in /branches, but said code needs a vote for
anything to happen.

The stipulation here is that you work under a different name space and
version. ODDR is an acceptable namespace string. We need to agree on
version.

So, if we reach agreement and vote on this measure passes, from that point
forward, we should have zero interaction other than Apache required voting.

Also, FYI, since 1.x and ODDR support W3C Simple DDR, you need to be more
specific when you mention W3C since you are potentially talking about 2
products.

On Mon, Apr 20, 2015 at 3:19 PM, Werner Keil <we...@gmail.com> wrote:

> Yes,
>
> Though they were not released there are nevertheless a number of examples.
> All currently under the "org.apache.devicemap.examples" namespace (which is
> what many projects do, Sling or DeltaSpike included)
> At leasts the 2 instances running on URLs like
> http://devicemap-vm.apache.org/dmap-spring/ match 2 of these exampe
> projects.
>
> Whether  or not there was a different structure, since they were not
> officially released yet, we seem free. I don't see great harm in the
> /tags/examples tag as mentioned. It marks a stable RC1 snapshot of what
> could become a joint "examples-1.0.0" release. Unless we prefer to further
> disect them, but that does not make a 1.0-RC1 worthless. It matches what
> runs on the VM for example;-)
>
> With few exceptions btw, the 0.x version space was for incubating projects.
> Hence and since others like Browsermap (or the W3C impl) had a longer
> history some version numbers were already higher before graduation.
>
> Generally the idea of a "sandbox" similar to DeltaSpike, Tomcat or Tamaya
> sounds worth exploring.
> This would be an area for 0.x kind of artifacts. And "playground". I am not
> sure, if it was a good idea to have an entire branch for that, but open to
> ideas.
> Earlier efforts like the Sling demo Radu worked on some while ago could be
> good in such "sandbox" (at JavaMoney we called it "shelter" inspired by the
> "Adopt-a-JSR" program and there's been some great progress in such a
> sandbox, e.g. Groovy support, Digital Currencies, etc.)
>
> Werner
>
> On Mon, Apr 20, 2015 at 8:15 PM, Reza Naghibi <re...@apache.org> wrote:
>
> > Also, as far as I am aware, we only have 4 officially released artifacts:
> >
> > -data
> > -java client
> > -.NET client (its not on the website but im certain we did a VOTE)
> > -browsermap (javascript) client
> >
> > All artifacts are all versioned in 1.x.
> >
> > On Mon, Apr 20, 2015 at 2:06 PM, Reza Naghibi <re...@apache.org> 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 <re...@apache.org>
> 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.
> > >>
> > >>
> >
>

Re: [DISCUSS] SVN, versioning, and namespace

[Werner Keil <we...@gmail.com>]

Yes,

Though they were not released there are nevertheless a number of examples.
All currently under the "org.apache.devicemap.examples" namespace (which is
what many projects do, Sling or DeltaSpike included)
At leasts the 2 instances running on URLs like
http://devicemap-vm.apache.org/dmap-spring/ match 2 of these exampe
projects.

Whether  or not there was a different structure, since they were not
officially released yet, we seem free. I don't see great harm in the
/tags/examples tag as mentioned. It marks a stable RC1 snapshot of what
could become a joint "examples-1.0.0" release. Unless we prefer to further
disect them, but that does not make a 1.0-RC1 worthless. It matches what
runs on the VM for example;-)

With few exceptions btw, the 0.x version space was for incubating projects.
Hence and since others like Browsermap (or the W3C impl) had a longer
history some version numbers were already higher before graduation.

Generally the idea of a "sandbox" similar to DeltaSpike, Tomcat or Tamaya
sounds worth exploring.
This would be an area for 0.x kind of artifacts. And "playground". I am not
sure, if it was a good idea to have an entire branch for that, but open to
ideas.
Earlier efforts like the Sling demo Radu worked on some while ago could be
good in such "sandbox" (at JavaMoney we called it "shelter" inspired by the
"Adopt-a-JSR" program and there's been some great progress in such a
sandbox, e.g. Groovy support, Digital Currencies, etc.)

Werner

On Mon, Apr 20, 2015 at 8:15 PM, Reza Naghibi <re...@apache.org> wrote:

> Also, as far as I am aware, we only have 4 officially released artifacts:
>
> -data
> -java client
> -.NET client (its not on the website but im certain we did a VOTE)
> -browsermap (javascript) client
>
> All artifacts are all versioned in 1.x.
>
> On Mon, Apr 20, 2015 at 2:06 PM, Reza Naghibi <re...@apache.org> 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 <re...@apache.org> 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.
> >>
> >>
>

Re: [DISCUSS] SVN, versioning, and namespace

[Reza Naghibi <re...@apache.org>]

Also, as far as I am aware, we only have 4 officially released artifacts:

-data
-java client
-.NET client (its not on the website but im certain we did a VOTE)
-browsermap (javascript) client

All artifacts are all versioned in 1.x.

On Mon, Apr 20, 2015 at 2:06 PM, Reza Naghibi <re...@apache.org> 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 <re...@apache.org> 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.
>>
>>

Re: [DISCUSS] SVN, versioning, and namespace

[Volkan Yazıcı <vo...@gmail.com>]

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 <we...@gmail.com> 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ı <vo...@gmail.com>
> 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 <re...@apache.org> 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ı <
> volkan.yazici@gmail.com>
> > > 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 <re...@apache.org>
> > 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 <re...@apache.org>
> > > 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.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] SVN, versioning, and namespace

[Werner Keil <we...@gmail.com>]

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ı <vo...@gmail.com>
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 <re...@apache.org> 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ı <vo...@gmail.com>
> > 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 <re...@apache.org>
> 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 <re...@apache.org>
> > 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.
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] SVN, versioning, and namespace

[Volkan Yazıcı <vo...@gmail.com>]

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 <re...@apache.org> 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ı <vo...@gmail.com>
> 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 <re...@apache.org> 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 <re...@apache.org>
> 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.
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] SVN, versioning, and namespace

[Reza Naghibi <re...@apache.org>]

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ı <vo...@gmail.com>
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 <re...@apache.org> 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 <re...@apache.org> 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.
> > >
> > >
> >
>

Re: [DISCUSS] SVN, versioning, and namespace

[Volkan Yazıcı <vo...@gmail.com>]

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 <re...@apache.org> 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 <re...@apache.org> 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.
> >
> >
>