devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: [DISCUSS] SVN, versioning, and namespace
Date Mon, 20 Apr 2015 20:52:04 GMT
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.
> > > >>
> > > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message