I have walked through all of the issues and sorted what I think should be done. ## Plan of action Within these 3 weeks, we will do: * 4.1.2 (bug fixes) -> code freeze Friday 27th * 4.2 Alpha1 -> code freeze Friday 27th * 4.2 Alpha2 or Beta we will see -> code freeze Friday 6th * 4.2 Beta or CR we will see -> code freeze Wed 11th The rookie team + me will work on the 4.1.2 tagged issues. This work will continue even past the release of 4.1.2 but will be likely incorporated into the 4.2 branch. Davide and Gunnar will work on the 4.2 tagged issues. It might make sense to have a single one focus on the numerous query improvements and the other on the rest. See below. Take the top issue of the list ordered by decreasing priority or one with the same level of priority. Kill it. Move to the next. ## Priorities For 4.1.2, I have sorted issues by decreasing importance with one little twist. All issues created after a direct user feedback is marked blocker. This is to speed our feedback loop time. https://hibernate.atlassian.net/browse/OGM-740?jql=project%20%3D%20OGM%20... For 4.2, it is also sorted by decreasing importance but I also gave the release a theme. The main focus is significantly improving JP-QL queries. Secondary and must have target is the error report API. Tertiary is everything else. That includes some improvements in ORM itself to unlock us. There are too many tasks to address them all but let's first focus on making a dent up to the major priority level. Remarks? Emmanuel _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Hey, Some pointers for those who haven't worked on the OGM code base in a while: * Contribution guide: http://hibernate.org/ogm/contribute/ * Build instructions: in the readme.md in the root dir; * You need to install CouchDB separately and configure the COUCHDB_HOSTNAME env variable if you want to test that backend; By default only the code of this module is compiled * When running the CLI build, MongoDB is started and stopped automatically via Maven. For running a test against MongoDB from within you IDE, MongoDB needs to be installed and started separately. * There are two types of tests in core: a) unit tests for stuff in core itself and b) the "backendtck" which are high-level (i.e. Session/EM-level) tests and which are executed for all backends. To run a specific test against a specific store in your IDE, simplest is to copy it into that project and run it from there. * Packages are organized with the SPI/impl split at the lowest level (I was talked into that ;). SPI is geared towards grid dialect implementors. The split is not complete yet, at some parts "our" dialects refer to "impl" classes from core. Anything not "spi" or "impl" is public API. Naturally, that's not very much though as OGM's main user API is JPA/Hibernate ORM. The main thing is the configuration API. Let me know in case there is anything I can help with to get you started. --Gunnar 2015-02-23 9:15 GMT+01:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: > Hi, > > Thanks for grooming the backlog and preparing these releases! > > I'm curious how the weekly release scheme is going to work out. In the > last two sprints we created none (although I thought we wanted to release > HS?) and one (HV, as planned) release. Planning for four releases now may > be over-stretching it a bit, esp. when splitting up powers as we do in the > first week. I would have planned for 4.1.2 and a 4.2 release. > > As you say, it's too many issues, we will not be able to do them all. > Personally, I like a realistic schedule more, IMO it gives you a better > sense of achievement if you actually managed to tackle what you had > planned. Now we'll more likely get the feeling that we failed to do half of > the things planned (as we know that's expected, still I find it > sub-optimal). > > The 4.1.2/4.2 release split make sense. It may be a good idea to either > pull you, Emmanuel, or Sanne (which I wouldn't count as a newbie in terms > of OGM) over to 4.2 issues at some stage, depending on the progress we make > with the respective backlogs. > > Nice to have the five of us working on OGM, looking forward to get new > functionality out there! > > --Gunnar > > > > > 2015-02-20 11:07 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > >> I have walked through all of the issues and sorted what I think should >> be done. >> >> ## Plan of action >> >> Within these 3 weeks, we will do: >> >> * 4.1.2 (bug fixes) -> code freeze Friday 27th >> * 4.2 Alpha1 -> code freeze Friday 27th >> * 4.2 Alpha2 or Beta we will see -> code freeze Friday 6th >> * 4.2 Beta or CR we will see -> code freeze Wed 11th >> >> The rookie team + me will work on the 4.1.2 tagged issues. >> This work will continue even past the release of 4.1.2 but will be >> likely incorporated into the 4.2 branch. >> >> Davide and Gunnar will work on the 4.2 tagged issues. >> It might make sense to have a single one focus on the numerous query >> improvements and the other on the rest. See below. >> >> Take the top issue of the list ordered by decreasing priority or one >> with the same level of priority. Kill it. Move to the next. >> >> ## Priorities >> >> For 4.1.2, I have sorted issues by decreasing importance with one little >> twist. All issues created after a direct user feedback is marked >> blocker. This is to speed our feedback loop time. >> >> >> https://hibernate.atlassian.net/browse/OGM-740?jql=project%20%3D%20OGM%20... >> >> For 4.2, it is also sorted by decreasing importance but I also gave the >> release a theme. >> The main focus is significantly improving JP-QL queries. >> Secondary and must have target is the error report API. >> Tertiary is everything else. That includes some improvements in ORM >> itself to unlock us. >> >> There are too many tasks to address them all but let's first focus on >> making a dent up to the major priority level. >> >> Remarks? >> >> Emmanuel >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >

Hi, Thanks for grooming the backlog and preparing these releases! I'm curious how the weekly release scheme is going to work out. In the last two sprints we created none (although I thought we wanted to release HS?) and one (HV, as planned) release. Planning for four releases now may be over-stretching it a bit, esp. when splitting up powers as we do in the first week. I would have planned for 4.1.2 and a 4.2 release.

As you say, it's too many issues, we will not be able to do them all. Personally, I like a realistic schedule more, IMO it gives you a better sense of achievement if you actually managed to tackle what you had planned. Now we'll more likely get the feeling that we failed to do half of the things planned (as we know that's expected, still I find it sub-optimal).

The 4.1.2/4.2 release split make sense. It may be a good idea to either pull you, Emmanuel, or Sanne (which I wouldn't count as a newbie in terms of OGM) over to 4.2 issues at some stage, depending on the progress we make with the respective backlogs.

* There are two types of tests in core: a) unit tests for stuff in core itself and b) the "backendtck" which are high-level (i.e. Session/EM-level) tests and which are executed for all backends.

To run a specific test against a specific store in your IDE, simplest is to copy it into that project and run it from there.

> Wouldn't it make sense to have these backendtck tests defined in a > dedicated > module? When you mentioned it, I was literally searching for the tests you > were > referring to. > Sorry, I guess I should have given you the package name. I kind of like the fact that one can execute the tests in core right away, i.e. without any copying, or custom runner etc. Would there be any strong advantage to having them in a separate module? If not I'd prefer to keep the number of modules low.

I like the idea of a separate module for shared tests, It makes sense for our usecase. I've never been a big fun of the OGM black magic.

Are there any reasons not to do it except that it will add a new module? I'm not really concerned about having modules in the project if their purpose is clear.

On Wed, Feb 25, 2015 at 10:30 AM, Hardy Ferentschik <hardy(a)hibernate.org&gt; wrote: > > > Wouldn't it make sense to have these backendtck tests defined in a > > > dedicated > > > module? When you mentioned it, I was literally searching for the tests > you > > > were > > > referring to. > > > > > > > Sorry, I guess I should have given you the package name. > > > > I kind of like the fact that one can execute the tests in core right > away, > > i.e. without any copying, or custom runner etc. Would there be any strong > > advantage to having them in a separate module? If not I'd prefer to keep > > the number of modules low. > > More transparency. If the module existed I could already just by name infer > what it is about. This might also be helpful for potential dialect > contributors > who look for high level tests. > > It is also in the spirit of one module one artifact. Unless I actually > check the > POM and find the second execution of the jar plugin, I don't know that two > artifacts > are generated. > > A dedicated module means less surprises and less understanding needed to > see how > things get together. > > Also, having a dedicated module allows for adding an additional README > which for > example described the purpose of these tests, how they are executed and > that they > are used by each dialect. > > --Hardy > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

My main concern still is whether that move would complicate running tests

My main concern still is whether that move would complicate running tests

To give some background, there is a dialect in core itself, HashmapDialect, which is used when running the TCK in core.

It makes sure changes or new features can be tested in core alone as far as possible. It would be good to keep the usability of this as nice as it is today.

> > A dedicated module means less surprises and less understanding needed to > > see how > > things get together. > > > > Hm, but test JARs have been an exception to that "rule" in Maven for a long > time. So no-one should really be surprised by using that concept. Hmm, not sure. > > Also, having a dedicated module allows for adding an additional README > > which for > > example described the purpose of these tests, how they are executed and > > that they > > are used by each dialect. > > > > Would it help if we add a note to the main readme.md, or maybe > package-info.java in the TCK package? Personally I prefer to have all > build-related info in one readme rather than scattered over several places. But that's partly my point. Your solutions require me to read something, whereas a dedicated module is almost self explaining. > It's not that I'm not against that move per se, I only have doubts whether > there is much benefit to it. IMO yes > My main concern still is whether that move would complicate running tests > in core itself? Today I can click and run the TCK tests in core in the IDE > without any further preparation. If that'd get more difficult, I'd vote > against that split. Well, with the helper I am suggesting it is still a single click :-) --Hardy

_______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev