Conf Call before EDR

[Werner Keil]

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]

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]

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) 

https://doodle.com/poll/gvnu2sh7wzk4yp8t

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

Regards,

Werner

[Werner Keil]

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 

https://github.com/unitsofmeasurement/indriya/issues/17

or

https://github.com/unitsofmeasurement/unit-api/issues/95

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]

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]

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]

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]

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]

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]

Hello Werner,

How does it work for Hangout tonight?

Thanks 

Jean-Marie

[Werner Keil]

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.

https://github.com/orgs/unitsofmeasurement/projects/1 contains all issues for the EDR.

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]

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]

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]

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]

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]

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]

Ok, thanks. 

[Werner Keil]

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]

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]

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]

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 ?

Seshat: https://en.wikipedia.org/wiki/Seshat

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]

I like Seshat!!

[Martin Desruisseaux]

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]

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]

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.

Of the EDR 1 issues: https://github.com/orgs/unitsofmeasurement/projects/1 

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]

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]

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