You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by "eberhard speer jr." <se...@ducis.net> on 2014/07/09 23:56:39 UTC
release
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ooops, lost me there "tagged" ?
esjr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC
DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe
a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB
X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0
c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR
F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I=
=e42w
-----END PGP SIGNATURE-----
Re: release
Posted by Kevan Miller <ke...@gmail.com>.
The site I pointed you to has the documentation that exists for the
available systems. Read that. If you have questions (which is likely) or
problems -- ask on builds@apache.org or file a jira ticket.
On Thu, Jul 10, 2014 at 1:00 AM, Werner Keil <we...@gmail.com> wrote:
> Sounds Good, could you please either via mailing list or directly let
> Eberhard know how he could use them for the .NET artifacts?
>
> Werner
> Am 10.07.2014 05:16 schrieb "Kevan Miller" <ke...@gmail.com>:
>
> > On Wed, Jul 9, 2014 at 6:49 PM, Werner Keil <we...@gmail.com>
> wrote:
> >
> > > The only exceptions are those projects based on .NET.
> > >
> > > @Bertrand, is there a CI system at Apache allowing those to be built
> > > continuously?
> > >
> >
> > http://ci.apache.org/ There are several windows platforms available
> there.
> >
> > --kevan
> >
>
Re: release
Posted by Werner Keil <we...@gmail.com>.
Sounds Good, could you please either via mailing list or directly let
Eberhard know how he could use them for the .NET artifacts?
Werner
Am 10.07.2014 05:16 schrieb "Kevan Miller" <ke...@gmail.com>:
> On Wed, Jul 9, 2014 at 6:49 PM, Werner Keil <we...@gmail.com> wrote:
>
> > The only exceptions are those projects based on .NET.
> >
> > @Bertrand, is there a CI system at Apache allowing those to be built
> > continuously?
> >
>
> http://ci.apache.org/ There are several windows platforms available there.
>
> --kevan
>
Re: release
Posted by Kevan Miller <ke...@gmail.com>.
On Wed, Jul 9, 2014 at 6:49 PM, Werner Keil <we...@gmail.com> wrote:
> The only exceptions are those projects based on .NET.
>
> @Bertrand, is there a CI system at Apache allowing those to be built
> continuously?
>
http://ci.apache.org/ There are several windows platforms available there.
--kevan
Re: release
Posted by Werner Keil <we...@gmail.com>.
The only exceptions are those projects based on .NET.
@Bertrand, is there a CI system at Apache allowing those to be built
continuously?
We have Jenkins instances in our office where teams writing mobile native
apps for WP8 are also built on dedicated (Windows) nodes. Not sure, if the
Apache infrastructure does that, though for mobile projects like our
"distant cousin" Cordova we propbably do.
Werner
On Thu, Jul 10, 2014 at 3:45 AM, Werner Keil <we...@gmail.com> wrote:
> Please cut the crap.
>
> The "official" release was broken, i.E. the version of the XML was wrong
> not matching what the tag was intended to be, etc.
> As mentioned, I am the person eligable to do this with the contribution
> from OpenDDR.
> So please Bertrand, if there is a way to restrict certain users from SVN,
> do this accordingly so that wrongful commits to this tree by Reza or others
> cannot happen any more[?]
>
> Also note, the parent hierarchy of the POMs is inconsistent. "classifier"
> not only differs from the POM artifactId (bad but if you don't want to
> change it, keep it for now, just don't change the artifactId any more after
> a release) it is an "orphan" without a proper parent[?]
>
>
> Go look at all the other Maven built projects, e.g. Jackrabbit (as this is
> an RI for a JSR I'm also on I know a bit about it)
> All modules including
> https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-data/pom.xml
>
> contain a proper
> <!--
> ====================================================================== -->
> <!-- P R O J E C T D E S C R I P T I O N -->
> <!--
> ====================================================================== -->
> <parent>
> <groupId>org.apache.jackrabbit</groupId>
> <artifactId>jackrabbit-parent</artifactId>
> <version>3.0-SNAPSHOT</version>
> <relativePath>../jackrabbit-parent/pom.xml</relativePath>
> </parent>
> <artifactId>jackrabbit-data</artifactId>
> <name>Jackrabbit Data</name>
> <description>Jackrabbit DataStore Implentations</description>
> <packaging>bundle</packaging>
>
> You defrauded the "classifier"/"client" module from this sanity, and
> deleted a proper parent which never caused a build to break, so if you want
> to have a proper Maven project here, could you please fix this before
> tagging[?]
>
> The parent pom in Jackrabbit's case uses this
> <!-- ===================================================================
> -->
> <!-- P R O J E C T D E S C R I P T I O N
> -->
> <!-- ===================================================================
> -->
>
> <parent>
> <groupId>org.apache</groupId>
> <artifactId>apache</artifactId>
> <version>10</version>
> <relativePath />
> </parent>
>
> Our parent poms (there should ideally be only one in the devicemap root,
> but given there's a .NET module with no great use for Maven having one for
> /trunk/data/device-data or /trunk/data and another for
> /trunk/devicemap/java seems acceptable) have been adjusted to the latest
> Apache Master POM version 14.
>
> This much like all the projects at JBoss, java.net or Eclipse controls
> global dependencies and makes sure you have the right set of plugins for a
> particular project.
>
> E.g. the "classifier" deviating from that practice makes it use a
> different compiler version than the rest. 3.1 is the recent one for
> Apache 14, you use 3.0 and like with the other POMs don't even know what's
> there it seems. That's why this is centrally maintained in larger projects
> [?]
>
> Can you please use either the correct java-parent or at least
> <parent>
> <groupId>org.apache</groupId>
> <artifactId>apache</artifactId>
> <version>14</version>
> <relativePath />
> </parent>
>
> Cheers,
> Werner
>
> On Thu, Jul 10, 2014 at 3:15 AM, Reza <re...@yahoo.com.invalid>
> wrote:
>
>> Just an FYI, what you tagged does not match what I was planning on
>> releasing. You made 2 commits after my release:
>>
>>
>> http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data/pom.xml?view=log
>>
>>
>> You have made numerous commits after my release which pretty much amount
>> to nothing except changing around files, changing fields in the pom,
>> breaking the build, and breaking the release. I have yet to see a single
>> line of code contributed. If you aren't contributing code, then don't play
>> around in the codebase.
>>
>> Bertrand, is it possible to have commits go into a feature branch and
>> have the release manager merge commits into trunk, release, and make the
>> tag? Ie: can we restrict svn access for certain users?
>>
>>
>> ________________________________
>> From: Werner Keil <we...@gmail.com>
>> To: "devicemap-dev@incubator.apache.org" <
>> devicemap-dev@incubator.apache.org>
>> Sent: Wednesday, July 9, 2014 8:37 PM
>> Subject: Re: release
>>
>>
>> Hi,
>>
>> I tagged the devicemap-data content after getting version and other
>> meta-data corrected:
>> https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
>>
>> The structure underneath is like the latest "openddr" tags, so in theory
>> we
>> may add "test-data" to it if it still applies, otherwise to another
>> release.
>> Have a look at how you want to tag the
>> https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
>> subtree.
>>
>> Either using the "java" and other folders or putting all of them under a
>> common "1.0.0" release. Or adding a prefix like "java-", "vb-", etc.
>> before
>> the 1.0.0.
>>
>> Werner
>>
>>
>> On Thu, Jul 10, 2014 at 12:47 AM, Werner Keil <we...@gmail.com>
>> wrote:
>>
>> > SVN tags here
>> > https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
>> >
>> > The name space is up to how we want to do this underneath each
>> "component"
>> > (hence the suggestion someone who can do this in JIRA might add actual
>> > components for "Java", ".NET" or VB/CSharp and "Data", so far only
>> Bertrand
>> > and for some credentials like change assigneee Reza are in the right
>> > group/role)
>> >
>> > "data" had a snapshot for each OpenDDR update I synced. Reza missed
>> 1.27,
>> > but as we plan to draft a 1.0.0 milestone release, that can be done via
>> the
>> > release tag anyway.
>> > So I'd do this for
>> > https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
>> >
>> > Ideally all other tags should be similar. The naming convention is
>> totally
>> > different for every single Apache project.
>> >
>> > For a "flat" structure using only the top-level "tags" folder, many
>> > projects chose something like /tags/devicemap-data-1.0.0.
>> >
>> > If you prefer, let's do that for ALL artifacts like that, otherwise just
>> > "1.0.0" or "v1.0.0" are the other patterns. See "CouchDB" using a simple
>> > "1.0.0", etc. "DeltaCloud" put a "release-" in front of every tag, so
>> there
>> > is no mandatory pattern by Apache Foundation, only a common agreement
>> > inside each team it seems...
>> >
>> > If we use the
>> > /tags/data
>> > /tags/devicemap
>> >
>> > structure, then either
>> > /tags/devicemap/java-1.0.0
>> > /tags/devicemap/csharp-1.0.0
>> > ...
>> > would work or
>> > /tags/devicemap/java/1.0.0
>> > /tags/devicemap/csharp/1.0.0
>> >
>> > I'll leave the decision in the .NET and Java corner to what we like
>> best.
>> >
>> > I used "v1.x" under /data/openddr to match the exact same tag OpenDDR
>> used
>> > in Git.
>> > No distinct preference here, but for /tags/data will do a simple 1.0.0
>> for
>> > now.
>> > As of now, "test-data" did not seem in the archive, and you did not
>> sound
>> > too eager to include it with a 1.0.0 release right now, is that correct?
>> >
>> > Werner
>> >
>> > On Wed, Jul 9, 2014 at 11:56 PM, eberhard speer jr. <se...@ducis.net>
>> > wrote:
>> >
>> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> Hash: SHA1
>> >>
>> >> Ooops, lost me there "tagged" ?
>> >>
>> >> esjr
>> >> -----BEGIN PGP SIGNATURE-----
>> >> Version: GnuPG v1.4.8 (MingW32)
>> >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>> >>
>> >> iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC
>> >> DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe
>> >> a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB
>> >> X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0
>> >> c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR
>> >> F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I=
>> >> =e42w
>> >> -----END PGP SIGNATURE-----
>> >>
>> >
>> >
>>
>
>
Re: release
Posted by Werner Keil <we...@gmail.com>.
For initial contributions yes, but a merge with an independently maintained
OpenDDR project (until DeviceMap leaves the incubator that seems fair,
leaving aside some misunderstanding or misinterpreting the usefulness and
priority of a truly W3C compliant API) occasionally merged back into this
SVN, this is a recurring process from what I see (which is why Bertrand
asked me or others who can act on behalf of OpenDDR LLC to do this)
We are not using W3C "source" here now (it was probing the best way to use
it, maybe find a chance to get it to MavenCentral somehow, but the WG
dissolved at least by 2010, so I don't see how they would do that now), a
working and automated way was found to include a JAR into the build
process, so that should be solved.
Werner
On Thu, Jul 10, 2014 at 6:51 PM, Kevan Miller <ke...@gmail.com>
wrote:
> On Thu, Jul 10, 2014 at 1:30 AM, Werner Keil <we...@gmail.com>
> wrote:
>
> > To make the OpenDDR artifacts, especially resource files available to
> > DeviceMap they have to be re-licensed.
>
>
> Showing my ignorance -- wasn't this done when the DeviceMap project was
> started? If not, why not?
>
>
> > I trust e.g. Mark Struberg whom I had a great discussion about issues
> > DeltaSpike faces in Vienna can tell you in greater Detail, but based on
> > especially the question of using Material licensed under W3C license as
> > Source in the ASF repo as opposed to using a binary lib (which is fine
> and
> > done by dozens of projects;-) you may see why only initial committers
> from
> > the OpenDDR Team (myself and one or two others, see the project page, I
> > don't know who else technically became a Committer by now, so I could be
> > the only one) are eligable to relicense that IP from OpenDDR license to
> > Apache. Once it is here do and improve as you like without violating any
> > other legitimate claims but without acting on behalf of OpenDDR or other
> > licensors neither Reza nor others must "Copy&Paste" or merge from the
> > OpenDDR repo or a similar third Party;-)
>
>
> Please bring explicit licensing questions onto this list. I don't recall
> any previous discussions about the suitability of the W3C license for
> bringing into ASF svn. W3C licensed source *can* be used within the ASF.
>
> --kevan
>
Re: release
Posted by Kevan Miller <ke...@gmail.com>.
On Thu, Jul 10, 2014 at 1:30 AM, Werner Keil <we...@gmail.com> wrote:
> To make the OpenDDR artifacts, especially resource files available to
> DeviceMap they have to be re-licensed.
Showing my ignorance -- wasn't this done when the DeviceMap project was
started? If not, why not?
> I trust e.g. Mark Struberg whom I had a great discussion about issues
> DeltaSpike faces in Vienna can tell you in greater Detail, but based on
> especially the question of using Material licensed under W3C license as
> Source in the ASF repo as opposed to using a binary lib (which is fine and
> done by dozens of projects;-) you may see why only initial committers from
> the OpenDDR Team (myself and one or two others, see the project page, I
> don't know who else technically became a Committer by now, so I could be
> the only one) are eligable to relicense that IP from OpenDDR license to
> Apache. Once it is here do and improve as you like without violating any
> other legitimate claims but without acting on behalf of OpenDDR or other
> licensors neither Reza nor others must "Copy&Paste" or merge from the
> OpenDDR repo or a similar third Party;-)
Please bring explicit licensing questions onto this list. I don't recall
any previous discussions about the suitability of the W3C license for
bringing into ASF svn. W3C licensed source *can* be used within the ASF.
--kevan
Re: release
Posted by Werner Keil <we...@gmail.com>.
OK, will have a look. Especially steps no longer necessary, e.g. manually
importing the W3C JARs (that's now done by Maven) should be corrected.
For an actual download section the build chain would have to deploy either
to a Snapshot Maven repo or download section. While properly building, the
"deploy this" action in Jenkins currently fails. Likely because not all
projects use the right parent POM, so some are missing that information, or
the relevant POMs (either for "data", "java" or other parts) still need
other configuration.
Wave is a good comparison because the (theoretical) team size is not so
different, also in the "Dozens" (maybe more of them are active and
experienced enough with workflows to be constructive there?[?]) but not
Hundreds like e.g. the PhoneGap/Cordova team, OpenOffice or others. Wave
started just a few months before DeviceMap in late 2011 and is still
incubating. Its release is considered "0.4" so should "1.0" be the
graduation candidate, then it may still have a bit to go[?]
For DeviceMap "data" and based on its "mature", "well hung" state the W3C
implementations are certainly ripe for graduation. OpenDDR had a release
cycle ever since the beginning of 2012 and its 1.27 version is now pretty
much in sync. The "Simple DDR" Java client was "1.0.0" there for the past
2-3 years and after refactoring and succesful resolution of a more
convenient Maven build for the external dependency what we have in the
Apache SVN is equally mature or beyond if you want. So no reason to call
that "0.x", the POM version "1.0.0-SNAPSHOT" says what it is, a release
candidate.
The Java and .NET clients are a bit of a moving target, but if the result
of these test services was consistently working (
http://devicemap-vm.apache.org/javaservice.html once again shows "Bad
Gateway" and unless Reza decides to participate again, where is this VM
instance or the Tomcat on it controlled?) and the "javaservice" project
and/or examples currently not in Apache SVN at all existed, then the "Java
Client" could be "1.0.0" ready, too. As of today "1.0.0-SNAPSHOT" seems
more like it[?]
Werner
On Thu, Jul 10, 2014 at 1:12 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Thu, Jul 10, 2014 at 1:08 PM, Werner Keil <we...@gmail.com>
> wrote:
> > ...Like in JIRA I don't think I can, if it's part of the "SVN/site"
> structure maybe I could, then please let's decide who can do that ASAP....
>
> If by "I can" you mean editing http://incubator.apache.org/devicemap/
> yes you can - the site content is at
>
> http://svn.apache.org/repos/asf/incubator/devicemap/site/trunk/
>
> And the WEBSITE-HOWTO.txt there explains how that works. Committers
> should have full access to that, if that's not the case please
> describe exactly what doesn't work.
>
> Constructive changes to that website are very welcome of course.
>
> -Bertrand
>
Re: release
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Jul 10, 2014 at 1:08 PM, Werner Keil <we...@gmail.com> wrote:
> ...Like in JIRA I don't think I can, if it's part of the "SVN/site" structure maybe I could, then please let's decide who can do that ASAP....
If by "I can" you mean editing http://incubator.apache.org/devicemap/
yes you can - the site content is at
http://svn.apache.org/repos/asf/incubator/devicemap/site/trunk/
And the WEBSITE-HOWTO.txt there explains how that works. Committers
should have full access to that, if that's not the case please
describe exactly what doesn't work.
Constructive changes to that website are very welcome of course.
-Bertrand
Re: release
Posted by Werner Keil <we...@gmail.com>.
Hi,
Looking at Wave, also incubating, there are a few things we're missing
here, part of the reason why DeviceMap got stalled and deliverables are
scattered across the web in different personal homepages (e.g. Eberhard's
or Reza's) instead of a well maintained project page like this:
http://incubator.apache.org/wave/downloads.html
Did I mention the Apache master POMs contain valuable plugins for goals
like deploy to the Apache Snapshot Repo or as Wave does it automatically
JAR or ZIP up nightly builds?[?]
Those are the things, a project specific how-to guide like
http://incubator.apache.org/wave/get-involved.html explains, but the
general Apache top level pages don't. E.g. I didn't even see anything about
the Review Board at https://reviews.apache.org/dashboard/ there either.
Wave uses it, and it looks like this can and should be used even (or
ESPECIALLY[?]) while a project is still in the incubator.
Wave has 400+ JIRA tickets it seems, opposed to merely 40 we used. Needless
to say, the JIRA concept of "components" is used well. And even if there's
just one person (like the project lead) who can manually assign or
re-assign a task, if you define a number of components each should have a
default assignee, then that person gets tasks for his/her component. E.g.
"Data", ".NET" or "Java" as minimum proposal, I suggested that several
times but those who could maintain it either refused or have no time and at
least committers like Stefano, Eberhard or myself can't create a new
component, release or other elements in JIRA, just report stuff. and fix or
close (our reported) tickets.
Needless to say our project home page is a shamble, given everyone else has
"their own DeviceMap or DDR page" no wonder, nobody did this in the past 2
years[?]
Like in JIRA I don't think I can, if it's part of the "SVN/site" structure
maybe I could, then please let's decide who can do that ASAP.
Cheers,
Werner
Re: release
Posted by Werner Keil <we...@gmail.com>.
To make the OpenDDR artifacts, especially resource files available to
DeviceMap they have to be re-licensed. I trust e.g. Mark Struberg whom I
had a great discussion about issues DeltaSpike faces in Vienna can tell you
in greater Detail, but based on especially the question of using Material
licensed under W3C license as Source in the ASF repo as opposed to using a
binary lib (which is fine and done by dozens of projects;-) you may see why
only initial committers from the OpenDDR Team (myself and one or two
others, see the project page, I don't know who else technically became a
Committer by now, so I could be the only one) are eligable to relicense
that IP from OpenDDR license to Apache. Once it is here do and improve as
you like without violating any other legitimate claims but without acting
on behalf of OpenDDR or other licensors neither Reza nor others must
"Copy&Paste" or merge from the OpenDDR repo or a similar third Party;-)
I agree with you on all other Points, Thus leave them for those you hope
understand them to read and try act upon...
A few administrative items don't seem to work as transparently, e.g.
Eberhard and I still miss some roles in JIRA that Bertrand must have set up
ages ago (1y or more) but has since not Bern able to adjust. We can still
work on tasks, but they may not be assigned to the right Person or that
Person currently busy, on vacation, etc.
Same with the VM instance. It seems to be available to all committers, but
only two used it so far. If say a .NET equivalent existed, Eberhard should
be able to deploy, etc.
Even those with such access, especially Reza put multiple artifacts saying
"org.apache.devicemap" on their own private SVN repos or Servers. I trust
even incubating projects could provide a 'snapshot' or 'RC' download on
Apache.org, but nobody who has credentials did, or nobody except Bertrand
can at the Moment.
Cheers,
Werner
Am 10.07.2014 05:13 schrieb "Kevan Miller" <ke...@gmail.com>:
> I'd encourage everyone to get discussions moving on a positive note. We're
> seeing movement towards a release from the DeviceMap community. This is a
> good (and welcome) step forward for the community. Working through problems
> and disagreements in a positive manner, would be an extremely positive step.
>
> On Wed, Jul 9, 2014 at 6:45 PM, Werner Keil <we...@gmail.com> wrote
> :
>
>> The "official" release was broken, i.E. the version of the XML was wrong
>> not matching what the tag was intended to be, etc.
>>
>
> OK. So, discuss these problems with Reza and the rest of the community and
> see that they are fixed.
>
>
>> As mentioned, I am the person eligable to do this with the contribution
>> from OpenDDR.
>>
>
> Can you explain this? You are the person eligible to do what?
>
>
>> So please Bertrand, if there is a way to restrict certain users from SVN,
>> do this accordingly so that wrongful commits to this tree by Reza or others
>> cannot happen any more[?]
>>
>
> If you (or anyone else) feel that there are wrongful commits, please
> discuss the problems directly within the community. If differences cannot
> be resolved, there are mechanisms to address this.
>
> If you think community members are going to be restricted from SVN access,
> you are mistaken. It might be a good time to review how the ASF works --
> http://www.apache.org/foundation/how-it-works.html
>
>
>> Also note, the parent hierarchy of the POMs is inconsistent. "classifier"
>> not only differs from the POM artifactId (bad but if you don't want to
>> change it, keep it for now, just don't change the artifactId any more after
>> a release) it is an "orphan" without a proper parent[?]
>>
>
> Again, if there are problems or mistakes. Please identify them and work
> them out with the community.
>
> --kevan
>
Re: release
Posted by Kevan Miller <ke...@gmail.com>.
I'd encourage everyone to get discussions moving on a positive note. We're
seeing movement towards a release from the DeviceMap community. This is a
good (and welcome) step forward for the community. Working through problems
and disagreements in a positive manner, would be an extremely positive step.
On Wed, Jul 9, 2014 at 6:45 PM, Werner Keil <we...@gmail.com> wrote
:
> The "official" release was broken, i.E. the version of the XML was wrong
> not matching what the tag was intended to be, etc.
>
OK. So, discuss these problems with Reza and the rest of the community and
see that they are fixed.
> As mentioned, I am the person eligable to do this with the contribution
> from OpenDDR.
>
Can you explain this? You are the person eligible to do what?
> So please Bertrand, if there is a way to restrict certain users from SVN,
> do this accordingly so that wrongful commits to this tree by Reza or others
> cannot happen any more[?]
>
If you (or anyone else) feel that there are wrongful commits, please
discuss the problems directly within the community. If differences cannot
be resolved, there are mechanisms to address this.
If you think community members are going to be restricted from SVN access,
you are mistaken. It might be a good time to review how the ASF works --
http://www.apache.org/foundation/how-it-works.html
> Also note, the parent hierarchy of the POMs is inconsistent. "classifier"
> not only differs from the POM artifactId (bad but if you don't want to
> change it, keep it for now, just don't change the artifactId any more after
> a release) it is an "orphan" without a proper parent[?]
>
Again, if there are problems or mistakes. Please identify them and work
them out with the community.
--kevan
Re: release
Posted by Werner Keil <we...@gmail.com>.
Well if you think this is just bureaucracy
<http://dict.leo.org/ende/index_de.html#/search=bureaucracy&searchLoc=0&resultOrder=basic&multiwordShowSingle=on>
ask https://github.com/gpetracek or the other 15 contributors to
DeltaSpike:
https://github.com/apache/deltaspike/tree/master/deltaspike
Gerhard works at IRIAN, a JSF company also involved in a couple of other
projects like MyFaces. IRIAN hosted the stage where I presented DeviceMap
on JavaLand, and I just had a chat with former DeltaSpike lead Mark
Struberg in Vienna about DeltaSpike, CDI and some licensing issues.
If you want to know why DeltaSpike not only has a "master" POM but a
dedicated "parent" pom (both derived from subsequent Apache parent POMs)
ask them how they do it and avoid solo stuff like you tend to play here.
DeltaSpike also has "examples" something notably missing from the Apache
SVN repo.
Now I am responsible and taking care of modules initially contributed by
OpenDDR, and a proper integration into the Apache and DeviceMap ecosystem
like using the right parent POM, etc. was done initially by Bertrand and I
picked that up where he didn't have time over the months. This exists since
early 2013, mainly adjusted and tweaked by Bertrand in case of the
"classifier" module.
That had a proper
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>9</version>
<relativePath/>
</parent>
And contrary to a recent commit comment that never broke a build, nor using
the "java-parent" pom as a mid layer instead.
Bertrand also proposed a more "OSGi" like naming, which did not bother, you
completely reversed that without asking or creating a JIRA ticket (or where
is that?)
Now that is a naming detail I personally don't worry that much about.
Eclipse uses OSGi bundles, but most other project, even OSGi enabled Apache
projects like DeltaSpike are fine with an artifactId like "deltaspike-core"
or similar.
Even being used to develop in a single office or at home on your own most
of the time, doesn't mean throwing somthing into a larger ecosystem that
breaks everything else put up by the mentors or project leads before is how
you should work here. Or in any other Open Source community. DeltaSpike
also has an "examples" module like the one still empty here. Instead there
is something on GitHub or elsewhere it seems, you develop there on your
own, but under "org.apache.devicemap".
This is something you need to contribute, but if there isn't a "1.0.0"
example demonstrating how the "1.0.0" client works, then it seems
incomplete or fragmented[?]
Werner
On Thu, Jul 10, 2014 at 3:51 AM, Reza <re...@yahoo.com.invalid>
wrote:
> Fine, make the changes, you are obviously the expert here. This is your
> release and project now. How you completely asserted control of this
> project in the last 2 days is simply amazing.
>
>
>
> ------------------------------
> *From:* Werner Keil <we...@gmail.com>
> *To:* "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> *Sent:* Wednesday, July 9, 2014 9:45 PM
> *Subject:* Re: release
>
> Please cut the crap.
>
> The "official" release was broken, i.E. the version of the XML was wrong
> not matching what the tag was intended to be, etc.
> As mentioned, I am the person eligable to do this with the contribution
> from OpenDDR.
> So please Bertrand, if there is a way to restrict certain users from SVN,
> do this accordingly so that wrongful commits to this tree by Reza or others
> cannot happen any more
>
> Also note, the parent hierarchy of the POMs is inconsistent. "classifier"
> not only differs from the POM artifactId (bad but if you don't want to
> change it, keep it for now, just don't change the artifactId any more after
> a release) it is an "orphan" without a proper parent
>
>
> Go look at all the other Maven built projects, e.g. Jackrabbit (as this is
> an RI for a JSR I'm also on I know a bit about it)
> All modules including
> https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-data/pom.xml
>
> contain a proper
> <!--
> ====================================================================== -->
> <!-- P R O J E C T D E S C R I P T I O N -->
> <!--
> ====================================================================== -->
> <parent>
> <groupId>org.apache.jackrabbit</groupId>
> <artifactId>jackrabbit-parent</artifactId>
> <version>3.0-SNAPSHOT</version>
> <relativePath>../jackrabbit-parent/pom.xml</relativePath>
> </parent>
> <artifactId>jackrabbit-data</artifactId>
> <name>Jackrabbit Data</name>
> <description>Jackrabbit DataStore Implentations</description>
> <packaging>bundle</packaging>
>
> You defrauded the "classifier"/"client" module from this sanity, and
> deleted a proper parent which never caused a build to break, so if you want
> to have a proper Maven project here, could you please fix this before
> tagging
>
> The parent pom in Jackrabbit's case uses this
> <!-- ===================================================================
> -->
> <!-- P R O J E C T D E S C R I P T I O N
> -->
> <!-- ===================================================================
> -->
>
> <parent>
> <groupId>org.apache</groupId>
> <artifactId>apache</artifactId>
> <version>10</version>
> <relativePath />
> </parent>
>
> Our parent poms (there should ideally be only one in the devicemap root,
> but given there's a .NET module with no great use for Maven having one for
> /trunk/data/device-data or /trunk/data and another for
> /trunk/devicemap/java seems acceptable) have been adjusted to the latest
> Apache Master POM version 14.
>
> This much like all the projects at JBoss, java.net or Eclipse controls
> global dependencies and makes sure you have the right set of plugins for a
> particular project.
>
> E.g. the "classifier" deviating from that practice makes it use a
> different compiler version than the rest. 3.1 is the recent one for
> Apache 14, you use 3.0 and like with the other POMs don't even know what's
> there it seems. That's why this is centrally maintained in larger projects
>
> Can you please use either the correct java-parent or at least
> <parent>
> <groupId>org.apache</groupId>
> <artifactId>apache</artifactId>
> <version>14</version>
> <relativePath />
> </parent>
>
> Cheers,
> Werner
>
> On Thu, Jul 10, 2014 at 3:15 AM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> Just an FYI, what you tagged does not match what I was planning on
> releasing. You made 2 commits after my release:
>
>
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data/pom.xml?view=log
>
>
> You have made numerous commits after my release which pretty much amount
> to nothing except changing around files, changing fields in the pom,
> breaking the build, and breaking the release. I have yet to see a single
> line of code contributed. If you aren't contributing code, then don't play
> around in the codebase.
>
> Bertrand, is it possible to have commits go into a feature branch and have
> the release manager merge commits into trunk, release, and make the tag?
> Ie: can we restrict svn access for certain users?
>
>
> ________________________________
> From: Werner Keil <we...@gmail.com>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>
> Sent: Wednesday, July 9, 2014 8:37 PM
> Subject: Re: release
>
>
> Hi,
>
> I tagged the devicemap-data content after getting version and other
> meta-data corrected:
> https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
>
> The structure underneath is like the latest "openddr" tags, so in theory we
> may add "test-data" to it if it still applies, otherwise to another
> release.
> Have a look at how you want to tag the
> https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
> subtree.
>
> Either using the "java" and other folders or putting all of them under a
> common "1.0.0" release. Or adding a prefix like "java-", "vb-", etc. before
> the 1.0.0.
>
> Werner
>
>
> On Thu, Jul 10, 2014 at 12:47 AM, Werner Keil <we...@gmail.com>
> wrote:
>
> > SVN tags here
> > https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
> >
> > The name space is up to how we want to do this underneath each
> "component"
> > (hence the suggestion someone who can do this in JIRA might add actual
> > components for "Java", ".NET" or VB/CSharp and "Data", so far only
> Bertrand
> > and for some credentials like change assigneee Reza are in the right
> > group/role)
> >
> > "data" had a snapshot for each OpenDDR update I synced. Reza missed 1.27,
> > but as we plan to draft a 1.0.0 milestone release, that can be done via
> the
> > release tag anyway.
> > So I'd do this for
> > https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
> >
> > Ideally all other tags should be similar. The naming convention is
> totally
> > different for every single Apache project.
> >
> > For a "flat" structure using only the top-level "tags" folder, many
> > projects chose something like /tags/devicemap-data-1.0.0.
> >
> > If you prefer, let's do that for ALL artifacts like that, otherwise just
> > "1.0.0" or "v1.0.0" are the other patterns. See "CouchDB" using a simple
> > "1.0.0", etc. "DeltaCloud" put a "release-" in front of every tag, so
> there
> > is no mandatory pattern by Apache Foundation, only a common agreement
> > inside each team it seems...
> >
> > If we use the
> > /tags/data
> > /tags/devicemap
> >
> > structure, then either
> > /tags/devicemap/java-1.0.0
> > /tags/devicemap/csharp-1.0.0
> > ...
> > would work or
> > /tags/devicemap/java/1.0.0
> > /tags/devicemap/csharp/1.0.0
> >
> > I'll leave the decision in the .NET and Java corner to what we like best.
> >
> > I used "v1.x" under /data/openddr to match the exact same tag OpenDDR
> used
> > in Git.
> > No distinct preference here, but for /tags/data will do a simple 1.0.0
> for
> > now.
> > As of now, "test-data" did not seem in the archive, and you did not sound
> > too eager to include it with a 1.0.0 release right now, is that correct?
> >
> > Werner
> >
> > On Wed, Jul 9, 2014 at 11:56 PM, eberhard speer jr. <se...@ducis.net>
> > wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Ooops, lost me there "tagged" ?
> >>
> >> esjr
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.8 (MingW32)
> >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>
> >> iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC
> >> DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe
> >> a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB
> >> X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0
> >> c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR
> >> F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I=
> >> =e42w
> >> -----END PGP SIGNATURE-----
> >>
> >
> >
>
>
>
>
>
Re: release
Posted by Reza <re...@yahoo.com.INVALID>.
Fine, make the changes, you are obviously the expert here. This is your release and project now. How you completely asserted control of this project in the last 2 days is simply amazing.
________________________________
From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com>
Sent: Wednesday, July 9, 2014 9:45 PM
Subject: Re: release
Please cut the crap.
The "official" release was broken, i.E. the version of the XML was wrong not matching what the tag was intended to be, etc.
As mentioned, I am the person eligable to do this with the contribution from OpenDDR.
So please Bertrand, if there is a way to restrict certain users from SVN, do this accordingly so that wrongful commits to this tree by Reza or others cannot happen any more
Also note, the parent hierarchy of the POMs is inconsistent. "classifier" not only differs from the POM artifactId (bad but if you don't want to change it, keep it for now, just don't change the artifactId any more after a release) it is an "orphan" without a proper parent
Go look at all the other Maven built projects, e.g. Jackrabbit (as this is an RI for a JSR I'm also on I know a bit about it)
All modules including https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-data/pom.xml
contain a proper
<!-- ====================================================================== -->
<!-- P R O J E C T D E S C R I P T I O N -->
<!-- ====================================================================== -->
<parent>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>jackrabbit-parent</artifactId>
<version>3.0-SNAPSHOT</version>
<relativePath>../jackrabbit-parent/pom.xml</relativePath>
</parent>
<artifactId>jackrabbit-data</artifactId>
<name>Jackrabbit Data</name>
<description>Jackrabbit DataStore Implentations</description>
<packaging>bundle</packaging>
You defrauded the "classifier"/"client" module from this sanity, and deleted a proper parent which never caused a build to break, so if you want to have a proper Maven project here, could you please fix this before tagging
The parent pom in Jackrabbit's case uses this
<!-- =================================================================== -->
<!-- P R O J E C T D E S C R I P T I O N -->
<!-- =================================================================== -->
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>10</version>
<relativePath />
</parent>
Our parent poms (there should ideally be only one in the devicemap root, but given there's a .NET module with no great use for Maven having one for /trunk/data/device-data or /trunk/data and another for /trunk/devicemap/java seems acceptable) have been adjusted to the latest Apache Master POM version 14.
This much like all the projects at JBoss, java.net or Eclipse controls global dependencies and makes sure you have the right set of plugins for a particular project.
E.g. the "classifier" deviating from that practice makes it use a different compiler version than the rest. 3.1 is the recent one for Apache 14, you use 3.0 and like with the other POMs don't even know what's there it seems. That's why this is centrally maintained in larger projects
Can you please use either the correct java-parent or at least
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>14</version>
<relativePath />
</parent>
Cheers,
Werner
On Thu, Jul 10, 2014 at 3:15 AM, Reza <re...@yahoo.com.invalid> wrote:
Just an FYI, what you tagged does not match what I was planning on releasing. You made 2 commits after my release:
>
>http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data/pom.xml?view=log
>
>
>You have made numerous commits after my release which pretty much amount to nothing except changing around files, changing fields in the pom, breaking the build, and breaking the release. I have yet to see a single line of code contributed. If you aren't contributing code, then don't play around in the codebase.
>
>Bertrand, is it possible to have commits go into a feature branch and have the release manager merge commits into trunk, release, and make the tag? Ie: can we restrict svn access for certain users?
>
>
>________________________________
> From: Werner Keil <we...@gmail.com>
>To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
>Sent: Wednesday, July 9, 2014 8:37 PM
>Subject: Re: release
>
>
>
>Hi,
>
>I tagged the devicemap-data content after getting version and other
>meta-data corrected:
>https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
>
>The structure underneath is like the latest "openddr" tags, so in theory we
>may add "test-data" to it if it still applies, otherwise to another release.
>Have a look at how you want to tag the
>https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap subtree.
>
>Either using the "java" and other folders or putting all of them under a
>common "1.0.0" release. Or adding a prefix like "java-", "vb-", etc. before
>the 1.0.0.
>
>Werner
>
>
>On Thu, Jul 10, 2014 at 12:47 AM, Werner Keil <we...@gmail.com> wrote:
>
>> SVN tags here
>> https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
>>
>> The name space is up to how we want to do this underneath each "component"
>> (hence the suggestion someone who can do this in JIRA might add actual
>> components for "Java", ".NET" or VB/CSharp and "Data", so far only Bertrand
>> and for some credentials like change assigneee Reza are in the right
>> group/role)
>>
>> "data" had a snapshot for each OpenDDR update I synced. Reza missed 1.27,
>> but as we plan to draft a 1.0.0 milestone release, that can be done via the
>> release tag anyway.
>> So I'd do this for
>> https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
>>
>> Ideally all other tags should be similar. The naming convention is totally
>> different for every single Apache project.
>>
>> For a "flat" structure using only the top-level "tags" folder, many
>> projects chose something like /tags/devicemap-data-1.0.0.
>>
>> If you prefer, let's do that for ALL artifacts like that, otherwise just
>> "1.0.0" or "v1.0.0" are the other patterns. See "CouchDB" using a simple
>> "1.0.0", etc. "DeltaCloud" put a "release-" in front of every tag, so there
>> is no mandatory pattern by Apache Foundation, only a common agreement
>> inside each team it seems...
>>
>> If we use the
>> /tags/data
>> /tags/devicemap
>>
>> structure, then either
>> /tags/devicemap/java-1.0.0
>> /tags/devicemap/csharp-1.0.0
>> ...
>> would work or
>> /tags/devicemap/java/1.0.0
>> /tags/devicemap/csharp/1.0.0
>>
>> I'll leave the decision in the .NET and Java corner to what we like best.
>>
>> I used "v1.x" under /data/openddr to match the exact same tag OpenDDR used
>> in Git.
>> No distinct preference here, but for /tags/data will do a simple 1.0.0 for
>> now.
>> As of now, "test-data" did not seem in the archive, and you did not sound
>> too eager to include it with a 1.0.0 release right now, is that correct?
>>
>> Werner
>>
>> On Wed, Jul 9, 2014 at 11:56 PM, eberhard speer jr. <se...@ducis.net>
>> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Ooops, lost me there "tagged" ?
>>>
>>> esjr
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.8 (MingW32)
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>> iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC
>>> DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe
>>> a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB
>>> X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0
>>> c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR
>>> F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I=
>>> =e42w
>>> -----END PGP SIGNATURE-----
>>>
>>
>>
Re: release
Posted by Werner Keil <we...@gmail.com>.
Please cut the crap.
The "official" release was broken, i.E. the version of the XML was wrong
not matching what the tag was intended to be, etc.
As mentioned, I am the person eligable to do this with the contribution
from OpenDDR.
So please Bertrand, if there is a way to restrict certain users from SVN,
do this accordingly so that wrongful commits to this tree by Reza or others
cannot happen any more[?]
Also note, the parent hierarchy of the POMs is inconsistent. "classifier"
not only differs from the POM artifactId (bad but if you don't want to
change it, keep it for now, just don't change the artifactId any more after
a release) it is an "orphan" without a proper parent[?]
Go look at all the other Maven built projects, e.g. Jackrabbit (as this is
an RI for a JSR I'm also on I know a bit about it)
All modules including
https://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-data/pom.xml
contain a proper
<!-- ======================================================================
-->
<!-- P R O J E C T D E S C R I P T I O N -->
<!-- ======================================================================
-->
<parent>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>jackrabbit-parent</artifactId>
<version>3.0-SNAPSHOT</version>
<relativePath>../jackrabbit-parent/pom.xml</relativePath>
</parent>
<artifactId>jackrabbit-data</artifactId>
<name>Jackrabbit Data</name>
<description>Jackrabbit DataStore Implentations</description>
<packaging>bundle</packaging>
You defrauded the "classifier"/"client" module from this sanity, and
deleted a proper parent which never caused a build to break, so if you want
to have a proper Maven project here, could you please fix this before
tagging[?]
The parent pom in Jackrabbit's case uses this
<!-- ===================================================================
-->
<!-- P R O J E C T D E S C R I P T I O N
-->
<!-- ===================================================================
-->
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>10</version>
<relativePath />
</parent>
Our parent poms (there should ideally be only one in the devicemap root,
but given there's a .NET module with no great use for Maven having one for
/trunk/data/device-data or /trunk/data and another for
/trunk/devicemap/java seems acceptable) have been adjusted to the latest
Apache Master POM version 14.
This much like all the projects at JBoss, java.net or Eclipse controls
global dependencies and makes sure you have the right set of plugins for a
particular project.
E.g. the "classifier" deviating from that practice makes it use a
different compiler version than the rest. 3.1 is the recent one for
Apache 14, you use 3.0 and like with the other POMs don't even know what's
there it seems. That's why this is centrally maintained in larger projects[?]
Can you please use either the correct java-parent or at least
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>14</version>
<relativePath />
</parent>
Cheers,
Werner
On Thu, Jul 10, 2014 at 3:15 AM, Reza <re...@yahoo.com.invalid>
wrote:
> Just an FYI, what you tagged does not match what I was planning on
> releasing. You made 2 commits after my release:
>
>
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data/pom.xml?view=log
>
>
> You have made numerous commits after my release which pretty much amount
> to nothing except changing around files, changing fields in the pom,
> breaking the build, and breaking the release. I have yet to see a single
> line of code contributed. If you aren't contributing code, then don't play
> around in the codebase.
>
> Bertrand, is it possible to have commits go into a feature branch and have
> the release manager merge commits into trunk, release, and make the tag?
> Ie: can we restrict svn access for certain users?
>
>
> ________________________________
> From: Werner Keil <we...@gmail.com>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>
> Sent: Wednesday, July 9, 2014 8:37 PM
> Subject: Re: release
>
>
> Hi,
>
> I tagged the devicemap-data content after getting version and other
> meta-data corrected:
> https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
>
> The structure underneath is like the latest "openddr" tags, so in theory we
> may add "test-data" to it if it still applies, otherwise to another
> release.
> Have a look at how you want to tag the
> https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
> subtree.
>
> Either using the "java" and other folders or putting all of them under a
> common "1.0.0" release. Or adding a prefix like "java-", "vb-", etc. before
> the 1.0.0.
>
> Werner
>
>
> On Thu, Jul 10, 2014 at 12:47 AM, Werner Keil <we...@gmail.com>
> wrote:
>
> > SVN tags here
> > https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
> >
> > The name space is up to how we want to do this underneath each
> "component"
> > (hence the suggestion someone who can do this in JIRA might add actual
> > components for "Java", ".NET" or VB/CSharp and "Data", so far only
> Bertrand
> > and for some credentials like change assigneee Reza are in the right
> > group/role)
> >
> > "data" had a snapshot for each OpenDDR update I synced. Reza missed 1.27,
> > but as we plan to draft a 1.0.0 milestone release, that can be done via
> the
> > release tag anyway.
> > So I'd do this for
> > https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
> >
> > Ideally all other tags should be similar. The naming convention is
> totally
> > different for every single Apache project.
> >
> > For a "flat" structure using only the top-level "tags" folder, many
> > projects chose something like /tags/devicemap-data-1.0.0.
> >
> > If you prefer, let's do that for ALL artifacts like that, otherwise just
> > "1.0.0" or "v1.0.0" are the other patterns. See "CouchDB" using a simple
> > "1.0.0", etc. "DeltaCloud" put a "release-" in front of every tag, so
> there
> > is no mandatory pattern by Apache Foundation, only a common agreement
> > inside each team it seems...
> >
> > If we use the
> > /tags/data
> > /tags/devicemap
> >
> > structure, then either
> > /tags/devicemap/java-1.0.0
> > /tags/devicemap/csharp-1.0.0
> > ...
> > would work or
> > /tags/devicemap/java/1.0.0
> > /tags/devicemap/csharp/1.0.0
> >
> > I'll leave the decision in the .NET and Java corner to what we like best.
> >
> > I used "v1.x" under /data/openddr to match the exact same tag OpenDDR
> used
> > in Git.
> > No distinct preference here, but for /tags/data will do a simple 1.0.0
> for
> > now.
> > As of now, "test-data" did not seem in the archive, and you did not sound
> > too eager to include it with a 1.0.0 release right now, is that correct?
> >
> > Werner
> >
> > On Wed, Jul 9, 2014 at 11:56 PM, eberhard speer jr. <se...@ducis.net>
> > wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Ooops, lost me there "tagged" ?
> >>
> >> esjr
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.8 (MingW32)
> >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >>
> >> iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC
> >> DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe
> >> a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB
> >> X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0
> >> c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR
> >> F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I=
> >> =e42w
> >> -----END PGP SIGNATURE-----
> >>
> >
> >
>
Re: release
Posted by Reza <re...@yahoo.com.INVALID>.
Just an FYI, what you tagged does not match what I was planning on releasing. You made 2 commits after my release:
http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data/pom.xml?view=log
You have made numerous commits after my release which pretty much amount to nothing except changing around files, changing fields in the pom, breaking the build, and breaking the release. I have yet to see a single line of code contributed. If you aren't contributing code, then don't play around in the codebase.
Bertrand, is it possible to have commits go into a feature branch and have the release manager merge commits into trunk, release, and make the tag? Ie: can we restrict svn access for certain users?
________________________________
From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
Sent: Wednesday, July 9, 2014 8:37 PM
Subject: Re: release
Hi,
I tagged the devicemap-data content after getting version and other
meta-data corrected:
https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
The structure underneath is like the latest "openddr" tags, so in theory we
may add "test-data" to it if it still applies, otherwise to another release.
Have a look at how you want to tag the
https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap subtree.
Either using the "java" and other folders or putting all of them under a
common "1.0.0" release. Or adding a prefix like "java-", "vb-", etc. before
the 1.0.0.
Werner
On Thu, Jul 10, 2014 at 12:47 AM, Werner Keil <we...@gmail.com> wrote:
> SVN tags here
> https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
>
> The name space is up to how we want to do this underneath each "component"
> (hence the suggestion someone who can do this in JIRA might add actual
> components for "Java", ".NET" or VB/CSharp and "Data", so far only Bertrand
> and for some credentials like change assigneee Reza are in the right
> group/role)
>
> "data" had a snapshot for each OpenDDR update I synced. Reza missed 1.27,
> but as we plan to draft a 1.0.0 milestone release, that can be done via the
> release tag anyway.
> So I'd do this for
> https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
>
> Ideally all other tags should be similar. The naming convention is totally
> different for every single Apache project.
>
> For a "flat" structure using only the top-level "tags" folder, many
> projects chose something like /tags/devicemap-data-1.0.0.
>
> If you prefer, let's do that for ALL artifacts like that, otherwise just
> "1.0.0" or "v1.0.0" are the other patterns. See "CouchDB" using a simple
> "1.0.0", etc. "DeltaCloud" put a "release-" in front of every tag, so there
> is no mandatory pattern by Apache Foundation, only a common agreement
> inside each team it seems...
>
> If we use the
> /tags/data
> /tags/devicemap
>
> structure, then either
> /tags/devicemap/java-1.0.0
> /tags/devicemap/csharp-1.0.0
> ...
> would work or
> /tags/devicemap/java/1.0.0
> /tags/devicemap/csharp/1.0.0
>
> I'll leave the decision in the .NET and Java corner to what we like best.
>
> I used "v1.x" under /data/openddr to match the exact same tag OpenDDR used
> in Git.
> No distinct preference here, but for /tags/data will do a simple 1.0.0 for
> now.
> As of now, "test-data" did not seem in the archive, and you did not sound
> too eager to include it with a 1.0.0 release right now, is that correct?
>
> Werner
>
> On Wed, Jul 9, 2014 at 11:56 PM, eberhard speer jr. <se...@ducis.net>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ooops, lost me there "tagged" ?
>>
>> esjr
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.8 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC
>> DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe
>> a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB
>> X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0
>> c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR
>> F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I=
>> =e42w
>> -----END PGP SIGNATURE-----
>>
>
>
Re: release
Posted by Werner Keil <we...@gmail.com>.
Btw. the Wave project. als incubating pretty much followed a similar
pattern. It started with some "wave-0.x-rcy" tags, but the latest tag
simply goes "0.4-rc4".
At least for further development it would be good to have more tags, also
on the .NET artifacts. Thus, if anything may not go into 1.0.0 right now,
please consider another tag on a regular basis for significant changes.
Wave has a very nice website, probably something to keep an eye on, as most
of ours still says "Now in 2012"[?]
As of now I tagged a matching combination of 0.1 "web" and "java"
artifacts, so the relative structure would be nice to persist if you tag
all of "java" or "csharp".
Otherwise it is worth considering a prefix like "client-1.0.0" under the
/devicemap tags, or the pattern only for the client artifacts like
"devicemap-client-java-1.0.0"
we already see in Reza's site.
Squashing all artifacts into a single /tags/1.0.0/ folder would totally
break the structure they have under /trunk. We have a very sophisticated
SVN system over here at my client,, and the SVN admin is keen to keep it
merge-able, as he's the one who has to do that if the need arises.
Werner
On Thu, Jul 10, 2014 at 2:37 AM, Werner Keil <we...@gmail.com> wrote:
> Hi,
>
> I tagged the devicemap-data content after getting version and other
> meta-data corrected:
> https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
>
> The structure underneath is like the latest "openddr" tags, so in theory
> we may add "test-data" to it if it still applies, otherwise to another
> release.
> Have a look at how you want to tag the
> https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
> subtree.
>
> Either using the "java" and other folders or putting all of them under a
> common "1.0.0" release. Or adding a prefix like "java-", "vb-", etc. before
> the 1.0.0.
>
> Werner
>
> On Thu, Jul 10, 2014 at 12:47 AM, Werner Keil <we...@gmail.com>
> wrote:
>
>> SVN tags here
>> https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
>>
>> The name space is up to how we want to do this underneath each
>> "component" (hence the suggestion someone who can do this in JIRA might add
>> actual components for "Java", ".NET" or VB/CSharp and "Data", so far only
>> Bertrand and for some credentials like change assigneee Reza are in the
>> right group/role)
>>
>> "data" had a snapshot for each OpenDDR update I synced. Reza missed 1.27,
>> but as we plan to draft a 1.0.0 milestone release, that can be done via the
>> release tag anyway.
>> So I'd do this for
>> https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
>>
>> Ideally all other tags should be similar. The naming convention is
>> totally different for every single Apache project.
>>
>> For a "flat" structure using only the top-level "tags" folder, many
>> projects chose something like /tags/devicemap-data-1.0.0.
>>
>> If you prefer, let's do that for ALL artifacts like that, otherwise just
>> "1.0.0" or "v1.0.0" are the other patterns. See "CouchDB" using a simple
>> "1.0.0", etc. "DeltaCloud" put a "release-" in front of every tag, so there
>> is no mandatory pattern by Apache Foundation, only a common agreement
>> inside each team it seems...
>>
>> If we use the
>> /tags/data
>> /tags/devicemap
>>
>> structure, then either
>> /tags/devicemap/java-1.0.0
>> /tags/devicemap/csharp-1.0.0
>> ...
>> would work or
>> /tags/devicemap/java/1.0.0
>> /tags/devicemap/csharp/1.0.0
>>
>> I'll leave the decision in the .NET and Java corner to what we like best.
>>
>> I used "v1.x" under /data/openddr to match the exact same tag OpenDDR
>> used in Git.
>> No distinct preference here, but for /tags/data will do a simple 1.0.0
>> for now.
>> As of now, "test-data" did not seem in the archive, and you did not sound
>> too eager to include it with a 1.0.0 release right now, is that correct?
>>
>> Werner
>>
>> On Wed, Jul 9, 2014 at 11:56 PM, eberhard speer jr. <se...@ducis.net>
>> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Ooops, lost me there "tagged" ?
>>>
>>> esjr
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.8 (MingW32)
>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>>
>>> iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC
>>> DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe
>>> a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB
>>> X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0
>>> c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR
>>> F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I=
>>> =e42w
>>> -----END PGP SIGNATURE-----
>>>
>>
>>
>
Re: release
Posted by Werner Keil <we...@gmail.com>.
Hi,
I tagged the devicemap-data content after getting version and other
meta-data corrected:
https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
The structure underneath is like the latest "openddr" tags, so in theory we
may add "test-data" to it if it still applies, otherwise to another release.
Have a look at how you want to tag the
https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap subtree.
Either using the "java" and other folders or putting all of them under a
common "1.0.0" release. Or adding a prefix like "java-", "vb-", etc. before
the 1.0.0.
Werner
On Thu, Jul 10, 2014 at 12:47 AM, Werner Keil <we...@gmail.com> wrote:
> SVN tags here
> https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
>
> The name space is up to how we want to do this underneath each "component"
> (hence the suggestion someone who can do this in JIRA might add actual
> components for "Java", ".NET" or VB/CSharp and "Data", so far only Bertrand
> and for some credentials like change assigneee Reza are in the right
> group/role)
>
> "data" had a snapshot for each OpenDDR update I synced. Reza missed 1.27,
> but as we plan to draft a 1.0.0 milestone release, that can be done via the
> release tag anyway.
> So I'd do this for
> https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
>
> Ideally all other tags should be similar. The naming convention is totally
> different for every single Apache project.
>
> For a "flat" structure using only the top-level "tags" folder, many
> projects chose something like /tags/devicemap-data-1.0.0.
>
> If you prefer, let's do that for ALL artifacts like that, otherwise just
> "1.0.0" or "v1.0.0" are the other patterns. See "CouchDB" using a simple
> "1.0.0", etc. "DeltaCloud" put a "release-" in front of every tag, so there
> is no mandatory pattern by Apache Foundation, only a common agreement
> inside each team it seems...
>
> If we use the
> /tags/data
> /tags/devicemap
>
> structure, then either
> /tags/devicemap/java-1.0.0
> /tags/devicemap/csharp-1.0.0
> ...
> would work or
> /tags/devicemap/java/1.0.0
> /tags/devicemap/csharp/1.0.0
>
> I'll leave the decision in the .NET and Java corner to what we like best.
>
> I used "v1.x" under /data/openddr to match the exact same tag OpenDDR used
> in Git.
> No distinct preference here, but for /tags/data will do a simple 1.0.0 for
> now.
> As of now, "test-data" did not seem in the archive, and you did not sound
> too eager to include it with a 1.0.0 release right now, is that correct?
>
> Werner
>
> On Wed, Jul 9, 2014 at 11:56 PM, eberhard speer jr. <se...@ducis.net>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ooops, lost me there "tagged" ?
>>
>> esjr
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.8 (MingW32)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC
>> DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe
>> a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB
>> X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0
>> c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR
>> F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I=
>> =e42w
>> -----END PGP SIGNATURE-----
>>
>
>
Re: release
Posted by Werner Keil <we...@gmail.com>.
SVN tags here
https://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap
The name space is up to how we want to do this underneath each "component"
(hence the suggestion someone who can do this in JIRA might add actual
components for "Java", ".NET" or VB/CSharp and "Data", so far only Bertrand
and for some credentials like change assigneee Reza are in the right
group/role)
"data" had a snapshot for each OpenDDR update I synced. Reza missed 1.27,
but as we plan to draft a 1.0.0 milestone release, that can be done via the
release tag anyway.
So I'd do this for
https://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0
Ideally all other tags should be similar. The naming convention is totally
different for every single Apache project.
For a "flat" structure using only the top-level "tags" folder, many
projects chose something like /tags/devicemap-data-1.0.0.
If you prefer, let's do that for ALL artifacts like that, otherwise just
"1.0.0" or "v1.0.0" are the other patterns. See "CouchDB" using a simple
"1.0.0", etc. "DeltaCloud" put a "release-" in front of every tag, so there
is no mandatory pattern by Apache Foundation, only a common agreement
inside each team it seems...
If we use the
/tags/data
/tags/devicemap
structure, then either
/tags/devicemap/java-1.0.0
/tags/devicemap/csharp-1.0.0
...
would work or
/tags/devicemap/java/1.0.0
/tags/devicemap/csharp/1.0.0
I'll leave the decision in the .NET and Java corner to what we like best.
I used "v1.x" under /data/openddr to match the exact same tag OpenDDR used
in Git.
No distinct preference here, but for /tags/data will do a simple 1.0.0 for
now.
As of now, "test-data" did not seem in the archive, and you did not sound
too eager to include it with a 1.0.0 release right now, is that correct?
Werner
On Wed, Jul 9, 2014 at 11:56 PM, eberhard speer jr. <se...@ducis.net>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ooops, lost me there "tagged" ?
>
> esjr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTvbqXAAoJEOxywXcFLKYctb4H/RJwOLzIjoFKcvRQIkN04uZC
> DjJGSayj8youkYwAMLY9AsM67osZfJkn0gCiXf+5Phpk5K9/PUJ5Qz8x3x5iizGe
> a/CQUXuVNyt/zRHXwc85lzuN+6FfC5uGsMGtbDFnf6Wm0ijBfEy3FZBAhHmdZFqB
> X774m9mI3URQWgqysoiip6UwZ64QKWdLth4KK0Ivyu02iMCwpQey5fWNgCIUvlp0
> c8SlkfvLy+n7xMEAQCjfgbh6E778tng7S2Ukurtowyfz83c/tyi/L/n+abEBEjMR
> F1OkW/SmJZZ3H9Skocq8G78PoCelWzd3JeAlJlmwTS10agF18kEAtJ9oEq67k3I=
> =e42w
> -----END PGP SIGNATURE-----
>