Mailing-List: contact dev-help@devicemap.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@devicemap.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAAGawe0HY2tfMxdQ64g+6v+iEJkpY0OJaZQf804kjzUrmTSu8g@mail.gmail.com>
References: 
 <CAKuYhJuOh3f3KHT9ELaurwDcS2FZWSZju=6Zuoi9jTh8LVZQqQ@mail.gmail.com>
	<CAKuYhJsgDHwMH_8pC-Csq_wzLvOZMiSuLyLvxx-OGthvFVAQgg@mail.gmail.com>
	<CAAGawe3O+pLJxJH1M5PKRSns=2nQNCr77VUmcwmxn_0OOa9wkQ@mail.gmail.com>
	<CAKuYhJuSn3_-96C=3xyYeB0+JQod1ZMpJUcZN39oPCWv0z76EQ@mail.gmail.com>
	<CAAGawe0HY2tfMxdQ64g+6v+iEJkpY0OJaZQf804kjzUrmTSu8g@mail.gmail.com>
Date: Mon, 20 Apr 2015 18:00:40 -0400
Message-ID: 
 <CAKuYhJvqvZ3A4cq3DT=sDrkzY04=qRph+ck02f9EwY2QuzDqgw@mail.gmail.com>
Subject: Re: [DISCUSS] SVN, versioning, and namespace
From: Reza Naghibi <rezan@apache.org>
To: DeviceMap Dev <dev@devicemap.apache.org>
Content-Type: multipart/alternative; boundary=047d7ba97a709046fb05142f0f95

--047d7ba97a709046fb05142f0f95
Content-Type: text/plain; charset=UTF-8

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 <werner.keil@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 <rezan@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 <werner.keil@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 <rezan@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 <rezan@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.
> > > > >>
> > > > >>
> > > >
> > >
> >
>

--047d7ba97a709046fb05142f0f95--