4 Replies Latest reply on Nov 27, 2009 4:22 AM by Sebastian Schneider

    History related issues - API etc.

    Sebastian Schneider Master

      Good evening,

      I'm surprised that these issues got postponed:

      https://jira.jboss.org/jira/browse/JBPM-2398

      https://jira.jboss.org/jira/browse/JBPM-2568

      I thought there was consensus in the developer team that history-related issues would be addressed in the 4.3-release. I judge these issues to be really important for real-world use. Of course I know there are just limited capacities but could anybody from the dev's shed some light on this since history API issue is already in the state of "coding in progress"?

      Thanks and have a nice evening

      Sebastian

        • 1. Re: History related issues - API etc.
          Joram Barrez Master

          Sebastian,

          You're thinking is correct: it's a matter of resourcing. The thing is, our job isn't 100% development ... often there are consultancies, conferences and huge internal discussions to be done. And I'm only touching the tip of the iceberg here, unfortunately.

          We expect +- 1 week work to get the history in a 'finished' state. Since the code freeze for 4.3 is extremely close, this time isn't available anywhere (without actually doing something else). We do hope to get the history done quickly, hopefully somewhere around christmas (but by then the 4.3 brach will already be made - which means changes can't be ported from trunk).

          Hope this gives you some insight in our 'process'

          • 2. Re: History related issues - API etc.
            Sebastian Schneider Master

            Thanks for shedding some light on this, Joram. I got one question on my mind: Can you get support for the 4.x branch from JBoss already or is this just available for the 3.x branch because this branch is currently part of the SOA-Stack (SOA-P)?

            • 3. Re: History related issues - API etc.
              Ronald van Kuijk Master

              I know resources are limited, one of the few certainties in life. But...

              Just like with a release cycle people can rely upon, the should be able to rely on what will be in that release. In many projects I worked on, knowing 6 weeks before a release that certain functionality that was scheduled to be in that release will not be in it is not something I can work with.

              I know consultancy jobs can come unexpected, that is not the problem, just like huge internal discussions. But things like Javaworld, JBoss World, Devoxx and other converences/talks could, no *should* be taken into account when planning.

              Looking at the past releases, each time issues were slipping to the next release, it did not happen often that there was a plethora of time. So I'd like to propose two things.
              - Try to define (as good as possible, taking the above into account) plan at the beginning of e.g. release 4.3 the issues for 4.4, not plan them at the beginning (or half way as happened now) of 4.4
              - Take a little more time, so plan less 'issues'

              This would make for an even more reliable release schedule (less irritation) and might get others to step in if they think it is to long of for it to be fixed.

              Ofcourse another solution would be to get more resources ;-)

              • 4. Re: History related issues - API etc.
                Sebastian Schneider Master

                 

                "Ronald" wrote:

                Just like with a release cycle people can rely upon, the should be able to rely on what will be in that release. In many projects I worked on, knowing 6 weeks before a release that certain functionality that was scheduled to be in that release will not be in it is not something I can work with.


                Agreed. The release cycle was introduced exactly for this, to make releases more predictable (as stated by Tom in the wiki) and thus to allow end-users to plan, too.

                "Ronald" wrote:

                Looking at the past releases, each time issues were slipping to the next release, it did not happen often that there was a plethora of time. So I'd like to propose two things.
                - Try to define (as good as possible, taking the above into account) plan at the beginning of e.g. release 4.3 the issues for 4.4, not plan them at the beginning (or half way as happened now) of 4.4
                - Take a little more time, so plan less 'issues'


                Agreed. When you take a look at the great number of issues originally scheduled for a release it's alsmost clear that not all of them can be taken into account. But the decision which of them are needs to be made earlier (spoken from an enduser's point of view). This would help a lot.

                The second thing which comes to my mind are priorities. I think bug fixes and basic features should have priority over completely new features. New features are great but from my point of view they don't have a great value for real world use unless basic process engine things were taken care of, especially a complete history and a fully functional variable logging.

                Just my 2 cents. Have a nice day. :)

                Sebastian