-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If we go with this compromise, I think this proposal is preferable.

esjr

On 2015-04-21 10:49, Bertrand Delacretaz wrote:
> Hi,
> 
> Here's a proposal based on Reza's ideas, but slightly different in 
> that it keeps all the code under /trunk while providing good
> isolation between the devicemap and w3c-ddr clients.
> 
> I suggest keeping the existing top-level folders under 
> https://svn.apache.org/repos/asf/devicemap/ , we can clarify their 
> usage once we agree on the basic structure.
> 
> Then, put all software under 
> https://svn.apache.org/repos/asf/devicemap/trunk, under the
> following top folders:
> 
> *** svn trunk structure proposal *** browsermap: that module, as is
> today
> 
> data: the device data, probably with 1.0 and 2.0 subfolders to
> keep both formats easily accessible during the transition, 1.0
> being retired later
> 
> clients/devicemap: the main Java client, what's currently under 
> devicemap/java/classifier
> 
> clients/csharp, clients/vbnet: the clients in those languages,
> moved from their current locations
> 
> clients/w3c-ddr: the W3C DDR client that's currently under 
> devicemap/java/simpleddr
> 
> contrib: unsupported or archived modules that the project only 
> maintains on a best effort basis
> 
> docs: various technical docs
> 
> examples: various examples that do not belong in their respective 
> modules folders
> 
> The clients/devicemap and clients/w3c-ddr java modules do *not*
> share a common pom, so they are completely isolated. *** svn trunk
> structure proposal ***
> 
> I think this provides good separation without the additional 
> complexity of multiple svn top-level folders.
> 
> Maybe work in Review-Then-Commit mode [1] on the data folder if
> people want strict control of what goes in there.
> 
> We can discuss artifact names and version numbers later, IMO the
> first thing is to agree on this layout.
> 
> WDYT? -Bertrand
> 
> [1] https://www.apache.org/foundation/glossary.html - search for
> "RTC"
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJVNgMiAAoJEOxywXcFLKYcJWUH/2lz0/T8YE3wQQQ+KMDvy8FB
K+L2+nBl8TzGQeuKaugBb+jfG613ZsoZmWrXzYrSO7wFAdRk7e/kp6KXY/zv792q
ujnGn8fNMLJC55VCVDiKg7W1rihz8bayLPDg6TzZXZccFJqzWBIxpNTU42wkCCa+
fFGGBdwrsWsqZQgByShWLuy8r8gvA+/2d5V2yotLjkAmhsZ7et9d8L73NnVqozEs
w2+1ujKjS6yCM0fCXjIzQOBhUvwoBmadd/8iUKItt96ZO13CrPLK0RCwe10TO3NC
R7WuZxEXQmdo6jx2BDtRhCQioPjbwtLYh1r4Fj9NnYIai//fz4E+mPoGicOZDHc=
=XvaW
-----END PGP SIGNATURE-----

Reply via email to