Conf Call before EDR

21 views
Skip to first unread message

Werner Keil

unread,
Jun 5, 2018, 7:02:25 PM6/5/18
to Units Developers
Hi,

As we aim for an EDR before Summer (~6 months, although 9 months max are allowed, but we should go Final when the new SI reforms are effective next May) it would be good to have a conf call or hangout before publishing the EDR.

If any of you have a better option like BlueJeans (I see some Eclipse projects use it) or another service, please tell us. Hangouts are said to be available for up to 25 people with video option, even more without video, that should be fairly sufficient given EG members and contributors although we won't exclude interested members of the list if they want to join as well.

Preferences time-wise? It was suggested if we could do it later, maybe after 8pm CET, for those in America it may also be better, so please anybody who either can only join during office hours or lives much further East and wants to join share your preferences or concerns here.
I know World Cup games are also coming up in about 10 days, so maybe we can get a call done before the first games start? ;-)

Looking forward to hearing you soon,
Werner

Jean-Marie Dautelle

unread,
Jun 7, 2018, 10:24:56 AM6/7/18
to unit...@googlegroups.com
Hello Werner,

After 8pm CET is fine with me (regardless of the day).

Thanks,
Jean-Marie

--
You received this message because you are subscribed to the Google Groups "Units Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to units-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Werner Keil

unread,
Jun 17, 2018, 9:39:12 AM6/17/18
to Units Developers
Thanks, here is a doodle poll for the next 2 weeks (I excluded a Meetup I have presenting Physikal and 2 days of DWX where I may not be available) 

Please participate so we can have a call to discuss open items, especially "Compound" or "Arithmetics".

Regards,
Werner

Werner Keil

unread,
Jun 19, 2018, 10:57:23 AM6/19/18
to Units Developers
Please have a look at Open Items for EDR 1: https://github.com/orgs/unitsofmeasurement/projects/1
(you need a GitHub user for this project view, AFAIK everyone can see it, not only team members, otherwise check individual repositories like https://github.com/unitsofmeasurement/unit-api/issues

Larger discussion items like 
or
are not in that list because they are too complex and require more information, so they are not ready for an EDR 1.
There is no reason to postpone EDR 1 in times where other JSRs like the JDK itself pushes out a Final release every 6 months.
Also see https://jcp.org/aboutJava/communityprocess/ec-public/materials/2018-06-12/FutureJCPDiscussion_Public_EC_June12_2018.pdf, the JCP wants to improve the process with a "code first" approach, which all the (50) done items in https://github.com/orgs/unitsofmeasurement/projects/1 are a good example, so is "adoption" by Associate members in this JSR.

Please have a look at the list and the two "Big Tickets" if you're not familiar with them already.
the most likely date for a hangout is Thursday, June 21 based on the Doodle poll at the moment.

Speak soon,
Werner

Werner Keil

unread,
Jun 20, 2018, 8:25:47 AM6/20/18
to Units Developers
Thanks for everyone who took part in the Doodle https://doodle.com/poll/gvnu2sh7wzk4yp8t

As of now, tomorrow, June 21 seems the best option for everyone who stated their preferences.
As 8 and 9pm CET are equally welcome, could we start at 8, so there is up to 2h if some of the bigger items really require it?

Can those not using a GMail account (especially Martin and Filip) confirm, it worked for a Google Hangout before? I opened the "Create a conversation" dialog and your emails are offered to select, but I cannot say, if it works without problems in Hangouts. As it works online without a standalone client, Google Hangout seems best. I saw, Blue Jeans has a cheap (12€/month) SME subscription, but I would try to find out, if they offer Open Source communities a free one or discount. I know it works well even for guest users, but let's start with Hangout unless either of you working in a larger company had a system you could invite us to?

Speak soon,
Werner

Martin Desruisseaux

unread,
Jun 20, 2018, 8:33:19 AM6/20/18
to unit...@googlegroups.com
Le 20/06/2018 à 14:25, Werner Keil a écrit :

> As 8 and 9pm CET are equally welcome, could we start at 8, so there is
> up to 2h if some of the bigger items really require it?
>
Actually 21:00 would be more convenient for me, if it is okay for
everyone? I would prefer to avoid a 2 hours meeting - it seems to me
that decision on complex topics would not be taken on phone call, since
some issues need written demonstration for being better understood?

Hangout should work for me.

    Martin


Werner Keil

unread,
Jun 20, 2018, 9:11:48 AM6/20/18
to Units Developers
I think Filip also said, he prefers a later time when the kids are already asleep, so we can start at 9pm.

Jean-Marie Dautelle

unread,
Jun 20, 2018, 4:22:48 PM6/20/18
to unit...@googlegroups.com
Ok for me with hangout at 9pm.

--
You received this message because you are subscribed to the Google Groups "Units Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to units-dev+...@googlegroups.com.

Filip van Laenen

unread,
Jun 20, 2018, 4:35:56 PM6/20/18
to unit...@googlegroups.com
Hi,

Yes, 9PM (CET) is more convenient for me too.

Hangouts is fine, but make sure to invite me on vla...@online.no.

Filip

Op 20-06-18 om 22:22 schreef Jean-Marie Dautelle:

Jean-Marie Dautelle

unread,
Jun 21, 2018, 2:57:19 PM6/21/18
to unit...@googlegroups.com
Hello Werner,
How does it work for Hangout tonight?
Thanks 
Jean-Marie

Werner Keil

unread,
Jun 21, 2018, 4:45:16 PM6/21/18
to Units Developers
Glad the group hangout worked for everyone who was online and could join.

Thanks everyone for the constructive call.

There are no formal minutes, but instead as already done in some of the GitHub tickets, let us track further steps and action items there.

As spoken please consolidate or maybe close all tickets like https://github.com/unitsofmeasurement/unit-api/issues/98 or https://github.com/unitsofmeasurement/unit-api/issues/99. And create one concrete action item for JavaDoc and Spec (where applicable) to explain the case and what to watch out for. If this is doable within 4-6 weeks from now, include it in the EDR (project property in GitHub, Milestone is always 2.0)

I'll also create a follow-up ticket for https://github.com/unitsofmeasurement/indriya/issues/17 in Indriya.

There could be multiple implementations, but there can be only one RI and Indriya is the new RI. 
As long as it does not confuse people or cause too much effort to maintain, nothing prevents maintaining the uom-se implementation further, but it won't be the RI in 2.0 either.

Kind Regards,
Werner


On Thursday, June 21, 2018 at 8:57:19 PM UTC+2, Jean-Marie Dautelle wrote:
Hello Werner,
How does it work for Hangout tonight?
Thanks 
Jean-Marie

Werner Keil

unread,
Jun 21, 2018, 5:38:47 PM6/21/18
to Units Developers
Similar to e.g. the JSON-P JSR and its follow-up in Jakarta EE I created 3 labels in the API tracker for priorities.
prio:1 to prio:3. 

Werner

Martin Desruisseaux

unread,
Jun 28, 2018, 4:16:55 AM6/28/18
to werne...@gmail.com, unit...@googlegroups.com
Hello Werner

In the conference call, I think it was mentioned that
https://github.com/unitsofmeasurement can be home to other unit-related
projects. If I understood correctly, could it be home to a port of
Apache SIS JSR-363 implementation (with its dependency to
geospatial-specific stuff removed)? If yes, is there a policy on module
names and package names of projects in unitsofmeasurement?

On a related question, can we create a new repository for a
"straightforward" implementation (using BigDecimal and without
optimization) in https://github.com/unitsofmeasurement?

    Martin


Werner Keil

unread,
Jun 28, 2018, 6:39:31 AM6/28/18
to Units Developers
Hello Martin,

We already have 4 implementations at the moment, so no reason why there could not be a 5th one. Especially since one or two are likely to be archived and set read only soon (units-ri unless there is something significant to fix won't see any more changes, uom-se at least once Indriya is Final and approved by Eclipse etc. also should be considered "legacy")

So why not add a third "new" implementation if there are use cases for it.

We use the new "tech" package namespace, where everything that is not RI or TCK should use "tech.uom". 
Currently these sub-packages aside from the parent exist:
  • client
  • domain
  • impl
  • lib
  • tools
If you're fine to define it under "impl", all implementations are free to use what's available (only "uom-impl-enum" is taken). It does not have to start with "uom" either.

If you prefer the top level tech.uom, please tell us, what you have in mind. It is not strictly prevented, see "uom-se", but it is not too common either.

Werner

Werner Keil

unread,
Jun 29, 2018, 1:03:31 PM6/29/18
to Units Developers
Martin,

You may need help of an admin to create a whole new repository under uom, as mentioned, please tell me/us (the Spec Leads should all have admin rights) what you would like to use and we can create it.

If some or much was inspired and derived from SIS, I assume the license would be Apache 2, not BSD 3?
Which is not a problem. BSD 3/New BSD is the default license, kind of like EPL with Eclipse, but there are exceptions, e.g. certain demos based on Red Hat examples are also Apache 2.

Werner

Martin Desruisseaux

unread,
Jun 30, 2018, 5:11:37 AM6/30/18
to Werner Keil, unit...@googlegroups.com
Hello Werner

Le 29/06/2018 à 19:03, Werner Keil a écrit :

> You may need help of an admin to create a whole new repository under
> uom, as mentioned, please tell me/us (the Spec Leads should all have
> admin rights) what you would like to use and we can create it.
>
Thanks for your reply. I'm neutral on the package / module name. Just
curious, where "tec.uom" come from since it seems different than the
usual convention of using reverse domain name? Or is "uom.tec" a
reserved internet domain? Do you have the possibility to use that name
for deployment on Maven Central?

I would like to pickup whatever name is consistent with other
repositories you have on https://github.com/unitsofmeasurement/. If
"tec.uom.impl.sis" is the most consistent package name regarding the
subpackages you mentioned in your previous email, this is fine.


> If some or much was inspired and derived from SIS, I assume the
> license would be Apache 2, not BSD 3?
>
Yes, the implementation in "tec.uom.impl.sis" would be under Apache 2
license if this is okay.

For the second repository I was thinking (the straightforward
implementation without optimization, for comparison purposes), I propose
to revisit later, for doing one task at time.

    Thanks,

        Martin


Werner Keil

unread,
Jun 30, 2018, 10:44:51 AM6/30/18
to Martin Desruisseaux, unit...@googlegroups.com
Ok, thanks. 

Werner Keil

unread,
Jul 2, 2018, 11:52:32 AM7/2/18
to Units Developers
I trust an "uom-sis" project (hope, nobody confuses SIS and SI though) is meant to be the foundation of a future Apache SIS, not just a fork?

Do you expect other SIS committers to participate there as well? It would be good and since it is not part of the JSR they don't have to join the JSR as Expert or Contributor unless they want to. 

On Saturday, June 30, 2018 at 4:44:51 PM UTC+2, Werner Keil wrote:
Ok, thanks. 

Martin Desruisseaux

unread,
Jul 2, 2018, 2:04:27 PM7/2/18
to unit...@googlegroups.com, werne...@gmail.com
Le 02/07/2018 à 17:52, Werner Keil a écrit :

> I trust an "uom-sis" project (hope, nobody confuses SIS and SI though)
> is meant to be the foundation of a future Apache SIS, not just a fork?
>
No, I think the current Apache SIS architecture is solid (even if there
is bugs to fix, including the arithmetic issue); I do not foresee a need
for new foundation. It is built on top of 15 years of experience in
Coordinate Reference Systems (not just Units of Measurement)
conversions. The intent is to provide a more lightweight version free of
the dependencies required by the rest of SIS library, for peoples who
are not interested in geospatial stuffs. My current plan is to continue
development in the main Apache SIS project, and port the changes to that
fork when there is any (I don't think it will happen often). If
https://github.com/unitsofmeasurement/ is not the right place for that,
I have no problem in looking for alternatives.


> Do you expect other SIS committers to participate there as well? It
> would be good and since it is not part of the JSR they don't have to
> join the JSR as Expert or Contributor unless they want to. 
>
I don't know; I'm not aware of such intention. As said above, the intent
is to make a SIS side-product more convenient rather than shifting the
development in a new place. I though that a common home for unit
libraries may be helpful for users, but I have no problem if this is not
the right location.

    Martin


Werner Keil

unread,
Jul 2, 2018, 2:21:24 PM7/2/18
to Units Developers
Martin,

Thanks for the clarification. Could you think of another name than "sis" then if it is "derived" and heavily inspired but not intended to replace the current SIS implementation of JSR 363?

To avoid people are not confusing it with "SI" which after the SI reforms should also play a more prominent role than right now.
And more importantly SIS itself, if two implementations (the more the merrier, we have no problem with that) 

Werner

Werner Keil

unread,
Jul 2, 2018, 2:35:19 PM7/2/18
to Units Developers
What do you think about using the second most popular name choice from https://groups.google.com/forum/?hl=en#!topic/units-dev/AxuXj_TMw7w ?

Godess of mathematics, and surveying. Among other things.
Although it only got one vote compared to Indriya, it sounds equally appropriate.

WDYT?

Otávio Gonçalves de Santana

unread,
Jul 3, 2018, 9:30:01 AM7/3/18
to Units Developers
I like Seshat!!

Martin Desruisseaux

unread,
Jul 3, 2018, 9:44:11 AM7/3/18
to unit...@googlegroups.com

Hello Otávio and Werner

I'm fine with Seshat, thanks for the proposal!

    Martin


Le 03/07/2018 à 15:30, Otávio Gonçalves de Santana a écrit :

Werner Keil

unread,
Jul 3, 2018, 11:52:08 AM7/3/18
to Units Developers
Hello,

Great, I created a new repository: https://github.com/unitsofmeasurement/seshat

As it is not a core JSR deliverable, both Experts and Contributors may write/push to it. 
I started with initial Maven gitignore a blank README and Apache 2 license. 
If it is no problem from a license point, please consider using https://github.com/unitsofmeasurement/uom-parent, otherwise maybe use the Sonatype OSS Parent which is also Apache 2.

The groupId should be either "tech.uom" or "tech.uom.impl", I leave it up to you which level you prefer.
The artifactId best "seshat" like the repository.

For the version number, I trust your judgement, if close to the SIS pattern, either 1.0-SNAPSHOT or something below that.

Let me know, if you have any problems importing the code.

Werner

Werner Keil

unread,
Jul 16, 2018, 12:02:07 PM7/16/18
to Units Developers
All,

As mentioned in the Hangout, we should publish an EDR 1 very soon, either in the course of July or first thing in August.

only Quantity.negate() is a prio 1 ticket. Everything else was either solved or could wait until a later stage.

We do have the general discussion item https://github.com/unitsofmeasurement/unit-api/issues/95 open, but all follow-up tickets are closed now.
Most of it has been described in the Wiki, would someone like to update the specification before the EDR or leave that for a later stage?

Regards,
Werner

Martin Desruisseaux

unread,
Jul 16, 2018, 12:53:23 PM7/16/18
to unit...@googlegroups.com
Le 16/07/2018 à 18:02, Werner Keil a écrit :

> We do have the general discussion
> item https://github.com/unitsofmeasurement/unit-api/issues/95 open,
> but all follow-up tickets are closed now. Most of it has been
> described in the Wiki, would someone like to update the specification
> before the EDR or leave that for a later stage?
>
I would like to update the specification, but I'm in a rush at work
lately. I will do my best for submitting pull requests as soon as I can,
but can not promise.

    Martin


Werner Keil

unread,
Jul 16, 2018, 7:05:25 PM7/16/18
to Units Developers
No worries, I know the situation with work (and two video courses on Java I also do right now ;-)

Are the PRs related to the arithmetic subject? Anything that is stable can go into the EDR, but we are not forced to get everything done by then.
All EG Members should have write access to the Spec. 

I think it is safe to wait till around the end of the month, but given it will take a few more weeks for PMO to publish I would not want to wait much longer. As we should aim for Public Review around the end of the year. And go Final no later than the SI Reform next May.

Werner
Reply all
Reply to author
Forward
0 new messages