Re: [ovirt-devel] commons-collections v4.0

2014-05-08 Thread Alon Bar-Lev


- Original Message -
 From: Mike Kolesnik mkole...@redhat.com
 To: Alon Bar-Lev alo...@redhat.com
 Cc: yzaspits yzasp...@redhat.com, devel@ovirt.org
 Sent: Thursday, May 8, 2014 7:18:51 AM
 Subject: Re: [ovirt-devel] commons-collections v4.0
 
 - Original Message -
  
  
  - Original Message -
   From: Yevgeny Zaspitsky yzasp...@redhat.com
   To: Alon Bar-Lev alo...@redhat.com, Mike Kolesnik
   mkole...@redhat.com
   Cc: devel@ovirt.org
   Sent: Thursday, May 8, 2014 1:11:41 AM
   Subject: Re: [ovirt-devel] commons-collections v4.0
   
   On the other hand, changing a jar in the runtime environment without
   compiling and running test with the new jar could lead an application to
   stop functioning in a customer environment.
   Also not every bug found in a dependency jar would cause a problem in the
   application. (An application might not use the problematic part of the
   dependency.)
   I'd better trust the test suite (automatic and manual) that we run on the
   compiled application with all the dependencies that the developers choose
   at
   the development time and then deliver that (with its dependencies as a
   single package) to the customers.
   Every bug in a dependency should be evaluated within the given
   application
   scope and only if proven as the given application problem only then the
   application should be released.
  
  So what you basically claim is that java developers and technology is not
  mature enough to keep backward compatibility, so each java developer should
  freeze a snapshot in time for his application to work.
  
  I truly hope this is not the case.
 
 There can always be regressions as you're well aware, and I don't know but
 usually people who develop the libraries are not Einstein so yes, they do
 break
 backwards compatibility on occasions, sometimes even on purpose
 (deprecation).
 
  
  And for addressing your claim explicitly, what you can test at single point
  in time, does not mean that it is definite as well, at customer site bugs
  may be found also in the packages that you do test.
 
 Well, when you test on site by dev  qa you make sure you send something to
 the
 customer - X. When the dependencies are updated out of band, the customer
 actually is using X'.
 I can see at least 2 things wrong here:
 1. You're putting the customer in a position of a tester for the X'
 application.
 2. If customer finds a bug he actually found it on X', whereas the developer
 who
 would be assigned to the bug could be using X'' by now.
 
 If you're so keen on packaging a jar outside WAR file, we need to specify
 explicit version and not =.

Explicit version is at if you pack it within your application, there is no 
point in that.

Think of how RHEL is provided, think of Fedora, in all cases there are 
components working together and each can be updated independently, and 
amazingly - it works. You can think of Windows with all of its libraries and 
interfaces (Microsoft or 3rd party), that application use, and it does work 
without every [sane] application pulls the entire dependencies.

For some reason only people with Java background (including the J2EE designers) 
assume that Java developers cannot be trusted for not breaking backward 
compatibility in minor versions. This is not technical assumption but human 
assumption, as there is no technical reason for Java library to break backward 
compatibility within minor releases, so what does it tells us about what Java 
developers thinks of them-selves?

Java will be ready for enterprise only when this is resolved. I hope all the 
dependencies we are using are at the quality level that enables us to to trust 
their developers.

 
  
   
   
   Sent from Samsung Mobile
   
    Original message 
   From: Alon Bar-Lev alo...@redhat.com
   Date: 07/05/2014  21:41  (GMT+02:00)
   To: Mike Kolesnik mkole...@redhat.com
   Cc: Yevgeny Zaspitsky yzasp...@redhat.com,devel@ovirt.org
   Subject: Re: [ovirt-devel] commons-collections v4.0

   
   
   - Original Message -
From: Mike Kolesnik mkole...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Yevgeny Zaspitsky yzasp...@redhat.com, devel@ovirt.org
Sent: Wednesday, May 7, 2014 9:34:03 PM
Subject: Re: [ovirt-devel] commons-collections v4.0

- Original Message -
 
 
 - Original Message -
  From: Yevgeny Zaspitsky yzasp...@redhat.com
  To: Alon Bar-Lev alo...@redhat.com
  Cc: devel@ovirt.org
  Sent: Tuesday, April 22, 2014 11:39:11 AM
  Subject: Re: [ovirt-devel] commons-collections v4.0
  
  That means that we manage 2 separate environments:
  1. Development - relies on pom files. E.g. unit tests run with
  commons-collections v3.1 (and when I add v4.0) and succeed.
 
 devenv will use runtime option.
 you are right about the unit tests, these relays on the poms.

I use devenv and it always uses the dev option

Re: [ovirt-devel] commons-collections v4.0

2014-05-08 Thread Sven Kieske


Am 07.05.2014 20:41, schrieb Alon Bar-Lev:
 Well, take the recent example of openssl issue that was found.
 Now, imagine that all products that use openssl should have been re-released.
 I think this is enough to understand how wrong this is.

Exactly,

if you want to take this serious, you must provide someone who monitors
any upstream project you might include and especially backport security
patches, maybe on your own, when talking about
enterprise grade software.

So any included hard dependency that will be shipped by ovirt
must also be maintainable by ovirt.

So it's always a good choice to have as little deps as possible
but of course you always have _some_ .

Where to draw the line is a very difficult task and should be
very well reviewed.

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] commons-collections v4.0

2014-05-07 Thread Mike Kolesnik
- Original Message -
 
 
 - Original Message -
  From: Yevgeny Zaspitsky yzasp...@redhat.com
  To: Alon Bar-Lev alo...@redhat.com
  Cc: devel@ovirt.org
  Sent: Tuesday, April 22, 2014 11:39:11 AM
  Subject: Re: [ovirt-devel] commons-collections v4.0
  
  That means that we manage 2 separate environments:
  1. Development - relies on pom files. E.g. unit tests run with
  commons-collections v3.1 (and when I add v4.0) and succeed.
 
 devenv will use runtime option.
 you are right about the unit tests, these relays on the poms.

I use devenv and it always uses the dev option not the runtime.
So basically developers are using the pom specified versions and not what
used in runtime.

Even more so, in runtime it highly depends on what OS you're using, so someone
developing on F19 might not be using same versions as a developer on F20 and
both are probably very different versions than on RHEL/CentOS.
I won't even mention other OS`s.

 
  2. Run-time - relies on JBoss own dependencies that bring
  commons-collection
  v3.2.1-redhat-2.
 
 in rhel case, yes.
 
  This kind of discrepancies might be found in other libraries as we do not
  synchronize our pom files with the JBoss current version dependencies.
  IMHO that could lead to some very difficult bugs that we won't be able to
  simulate in our unit tests.
 
 correct, but the java way to pull dependencies at will without being able to
 fix z-stream using central package management tools is more severe than unit
 tests not working/not working.
 
 for example, your application uses x.jar and actually delivers x.jar... so
 from release to eternity it is your responsibility to track x.jar for severe
 stability bugs and security bugs, and release your entire application each
 time found, now multiple it with the # of components application is using
 and see how much effort you have just to maintain stability and security if
 you embed 3rd party components without your application.

Yes, if you use package X then you're using that specific version with it's
behaviour and API, this is why dependencies aren't updated light headedly but
with testing to see that nothing broke (since stuff does break, even in minor
version, as we leave in a not so perfect world).

 
  Why do we avoid to maintain our own packaging? IMHO Ovirt own
  dependencies
  could be packed in the war, can't they?
 
 yes they could, but this is not suitable for enterprise grade
 implementations, mainly per what I described above.

Sorry but AFAIK enterprise grade software release fixes for their software
on a timely basis and have processes in place to manage upgrades of
functionality.

What currently is done is relying on courtesy of other people to release a
fix that already exists a long time.
And of course, as I mentioned, the application needs to be tested with the
updated library.
IMO neglecting this and leaving this out of band for enterprise grade
software is much worse than actually testing to see that it is working and
just leaving it all to chance.

 
 Regards,
 Alon
 
  Best regards,
  
  Yevgeny Zaspitsky
  Senior Software Engineer
  Red Hat Israel
  
  
  - Original Message -
  From: Alon Bar-Lev alo...@redhat.com
  To: Yevgeny Zaspitsky yzasp...@redhat.com
  Cc: devel@ovirt.org
  Sent: Sunday, April 13, 2014 7:22:18 PM
  Subject: Re: [ovirt-devel] commons-collections v4.0
  
  
  
  - Original Message -
   From: Yevgeny Zaspitsky yzasp...@redhat.com
   To: devel@ovirt.org
   Sent: Sunday, April 13, 2014 7:13:10 PM
   Subject: [ovirt-devel] commons-collections v4.0
   
   Hi All,
   
   I'd like to add the new version (4.0) of Apache commons-collections
   library
   to the dependencies of the project (we use 3.1 currently).
   The new version uses the generics features of Java 5 so that make the
   code
   more type safe. You can find the full list of changes on
   https://commons.apache.org/proper/commons-collections/release_4_0.html.
   The new API is based on the original but it isn't fully compatible with
   it.
   So in order to make the migration to the new API easier, the package has
   been changed to org.apache.commons.collections4. That allows having both
   version of the library in the classpath at the starting point and move
   (refactor) towards the new version gradually.
   
   I have couple of questions regarding the new dependency:
   1. Is there anything that could prevent adding the new dependency?
  
  We try to avoid introducing our own dependencies, in this case we use
  whatever jboss provides which is very comfortable as we do not need to
  maintain our own packaging.
  
  Currently the jbeap does not provide 4.0, it does support 3.2.1-redhat-2,
  so
  better to avoid this until we switch to more recent version of jboss.
  
  Alternatively we could enjoy standalone rpm within rhel/centos if
  available,
  however non exist.
  
   2. I did the change (http://gerrit.ovirt.org/26745).
  The unit tests that use

Re: [ovirt-devel] commons-collections v4.0

2014-05-07 Thread Alon Bar-Lev


- Original Message -
 From: Mike Kolesnik mkole...@redhat.com
 To: Alon Bar-Lev alo...@redhat.com
 Cc: Yevgeny Zaspitsky yzasp...@redhat.com, devel@ovirt.org
 Sent: Wednesday, May 7, 2014 9:34:03 PM
 Subject: Re: [ovirt-devel] commons-collections v4.0
 
 - Original Message -
  
  
  - Original Message -
   From: Yevgeny Zaspitsky yzasp...@redhat.com
   To: Alon Bar-Lev alo...@redhat.com
   Cc: devel@ovirt.org
   Sent: Tuesday, April 22, 2014 11:39:11 AM
   Subject: Re: [ovirt-devel] commons-collections v4.0
   
   That means that we manage 2 separate environments:
   1. Development - relies on pom files. E.g. unit tests run with
   commons-collections v3.1 (and when I add v4.0) and succeed.
  
  devenv will use runtime option.
  you are right about the unit tests, these relays on the poms.
 
 I use devenv and it always uses the dev option not the runtime.
 So basically developers are using the pom specified versions and not what
 used in runtime.
 
 Even more so, in runtime it highly depends on what OS you're using, so
 someone
 developing on F19 might not be using same versions as a developer on F20 and
 both are probably very different versions than on RHEL/CentOS.
 I won't even mention other OS`s.
 
  
   2. Run-time - relies on JBoss own dependencies that bring
   commons-collection
   v3.2.1-redhat-2.
  
  in rhel case, yes.
  
   This kind of discrepancies might be found in other libraries as we do not
   synchronize our pom files with the JBoss current version dependencies.
   IMHO that could lead to some very difficult bugs that we won't be able to
   simulate in our unit tests.
  
  correct, but the java way to pull dependencies at will without being able
  to
  fix z-stream using central package management tools is more severe than
  unit
  tests not working/not working.
  
  for example, your application uses x.jar and actually delivers x.jar... so
  from release to eternity it is your responsibility to track x.jar for
  severe
  stability bugs and security bugs, and release your entire application each
  time found, now multiple it with the # of components application is using
  and see how much effort you have just to maintain stability and security if
  you embed 3rd party components without your application.
 
 Yes, if you use package X then you're using that specific version with it's
 behaviour and API, this is why dependencies aren't updated light headedly but
 with testing to see that nothing broke (since stuff does break, even in minor
 version, as we leave in a not so perfect world).
 
  
   Why do we avoid to maintain our own packaging? IMHO Ovirt own
   dependencies
   could be packed in the war, can't they?
  
  yes they could, but this is not suitable for enterprise grade
  implementations, mainly per what I described above.
 
 Sorry but AFAIK enterprise grade software release fixes for their software
 on a timely basis and have processes in place to manage upgrades of
 functionality.
 
 What currently is done is relying on courtesy of other people to release a
 fix that already exists a long time.
 And of course, as I mentioned, the application needs to be tested with the
 updated library.
 IMO neglecting this and leaving this out of band for enterprise grade
 software is much worse than actually testing to see that it is working and
 just leaving it all to chance.

‎Well, take the recent example of openssl issue that was found.
Now, imagine that all products that use openssl should have been re-released.
I think this is enough to understand how wrong this is.

 
  
  Regards,
  Alon
  
   Best regards,
   
   Yevgeny Zaspitsky
   Senior Software Engineer
   Red Hat Israel
   
   
   - Original Message -
   From: Alon Bar-Lev alo...@redhat.com
   To: Yevgeny Zaspitsky yzasp...@redhat.com
   Cc: devel@ovirt.org
   Sent: Sunday, April 13, 2014 7:22:18 PM
   Subject: Re: [ovirt-devel] commons-collections v4.0
   
   
   
   - Original Message -
From: Yevgeny Zaspitsky yzasp...@redhat.com
To: devel@ovirt.org
Sent: Sunday, April 13, 2014 7:13:10 PM
Subject: [ovirt-devel] commons-collections v4.0

Hi All,

I'd like to add the new version (4.0) of Apache commons-collections
library
to the dependencies of the project (we use 3.1 currently).
The new version uses the generics features of Java 5 so that make the
code
more type safe. You can find the full list of changes on
https://commons.apache.org/proper/commons-collections/release_4_0.html.
The new API is based on the original but it isn't fully compatible with
it.
So in order to make the migration to the new API easier, the package
has
been changed to org.apache.commons.collections4. That allows having
both
version of the library in the classpath at the starting point and move
(refactor) towards the new version gradually.

I have couple of questions regarding the new dependency

Re: [ovirt-devel] commons-collections v4.0

2014-05-07 Thread Alon Bar-Lev


- Original Message -
 From: Yevgeny Zaspitsky yzasp...@redhat.com
 To: Alon Bar-Lev alo...@redhat.com, Mike Kolesnik mkole...@redhat.com
 Cc: devel@ovirt.org
 Sent: Thursday, May 8, 2014 1:11:41 AM
 Subject: Re: [ovirt-devel] commons-collections v4.0
 
 On the other hand, changing a jar in the runtime environment without
 compiling and running test with the new jar could lead an application to
 stop functioning in a customer environment.
 Also not every bug found in a dependency jar would cause a problem in the
 application. (An application might not use the problematic part of the
 dependency.)
 I'd better trust the test suite (automatic and manual) that we run on the
 compiled application with all the dependencies that the developers choose at
 the development time and then deliver that (with its dependencies as a
 single package) to the customers.
 Every bug in a dependency should be evaluated within the given application
 scope and only if proven as the given application problem only then the
 application should be released.

So what you basically claim is that java developers and technology is not 
mature enough to keep backward compatibility, so each java developer should 
freeze a snapshot in time for his application to work.

I truly hope this is not the case.

And for addressing your claim explicitly, what you can test at single point in 
time, does not mean that it is definite as well, at customer site bugs may be 
found also in the packages that you do test.

 
 
 Sent from Samsung Mobile
 
  Original message 
 From: Alon Bar-Lev alo...@redhat.com
 Date: 07/05/2014  21:41  (GMT+02:00)
 To: Mike Kolesnik mkole...@redhat.com
 Cc: Yevgeny Zaspitsky yzasp...@redhat.com,devel@ovirt.org
 Subject: Re: [ovirt-devel] commons-collections v4.0
  
 
 
 - Original Message -
  From: Mike Kolesnik mkole...@redhat.com
  To: Alon Bar-Lev alo...@redhat.com
  Cc: Yevgeny Zaspitsky yzasp...@redhat.com, devel@ovirt.org
  Sent: Wednesday, May 7, 2014 9:34:03 PM
  Subject: Re: [ovirt-devel] commons-collections v4.0
  
  - Original Message -
   
   
   - Original Message -
From: Yevgeny Zaspitsky yzasp...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: devel@ovirt.org
Sent: Tuesday, April 22, 2014 11:39:11 AM
Subject: Re: [ovirt-devel] commons-collections v4.0

That means that we manage 2 separate environments:
1. Development - relies on pom files. E.g. unit tests run with
commons-collections v3.1 (and when I add v4.0) and succeed.
   
   devenv will use runtime option.
   you are right about the unit tests, these relays on the poms.
  
  I use devenv and it always uses the dev option not the runtime.
  So basically developers are using the pom specified versions and not what
  used in runtime.
  
  Even more so, in runtime it highly depends on what OS you're using, so
  someone
  developing on F19 might not be using same versions as a developer on F20
  and
  both are probably very different versions than on RHEL/CentOS.
  I won't even mention other OS`s.
  
   
2. Run-time - relies on JBoss own dependencies that bring
commons-collection
v3.2.1-redhat-2.
   
   in rhel case, yes.
   
This kind of discrepancies might be found in other libraries as we do
not
synchronize our pom files with the JBoss current version dependencies.
IMHO that could lead to some very difficult bugs that we won't be able
to
simulate in our unit tests.
   
   correct, but the java way to pull dependencies at will without being able
   to
   fix z-stream using central package management tools is more severe than
   unit
   tests not working/not working.
   
   for example, your application uses x.jar and actually delivers x.jar...
   so
   from release to eternity it is your responsibility to track x.jar for
   severe
   stability bugs and security bugs, and release your entire application
   each
   time found, now multiple it with the # of components application is using
   and see how much effort you have just to maintain stability and security
   if
   you embed 3rd party components without your application.
  
  Yes, if you use package X then you're using that specific version with it's
  behaviour and API, this is why dependencies aren't updated light headedly
  but
  with testing to see that nothing broke (since stuff does break, even in
  minor
  version, as we leave in a not so perfect world).
  
   
Why do we avoid to maintain our own packaging? IMHO Ovirt own
dependencies
could be packed in the war, can't they?
   
   yes they could, but this is not suitable for enterprise grade
   implementations, mainly per what I described above.
  
  Sorry but AFAIK enterprise grade software release fixes for their software
  on a timely basis and have processes in place to manage upgrades of
  functionality.
  
  What currently is done is relying on courtesy of other people to release a
  fix that already exists

Re: [ovirt-devel] commons-collections v4.0

2014-05-07 Thread Mike Kolesnik
- Original Message -
 
 
 - Original Message -
  From: Yevgeny Zaspitsky yzasp...@redhat.com
  To: Alon Bar-Lev alo...@redhat.com, Mike Kolesnik
  mkole...@redhat.com
  Cc: devel@ovirt.org
  Sent: Thursday, May 8, 2014 1:11:41 AM
  Subject: Re: [ovirt-devel] commons-collections v4.0
  
  On the other hand, changing a jar in the runtime environment without
  compiling and running test with the new jar could lead an application to
  stop functioning in a customer environment.
  Also not every bug found in a dependency jar would cause a problem in the
  application. (An application might not use the problematic part of the
  dependency.)
  I'd better trust the test suite (automatic and manual) that we run on the
  compiled application with all the dependencies that the developers choose
  at
  the development time and then deliver that (with its dependencies as a
  single package) to the customers.
  Every bug in a dependency should be evaluated within the given application
  scope and only if proven as the given application problem only then the
  application should be released.
 
 So what you basically claim is that java developers and technology is not
 mature enough to keep backward compatibility, so each java developer should
 freeze a snapshot in time for his application to work.
 
 I truly hope this is not the case.

There can always be regressions as you're well aware, and I don't know but
usually people who develop the libraries are not Einstein so yes, they do break
backwards compatibility on occasions, sometimes even on purpose (deprecation).

 
 And for addressing your claim explicitly, what you can test at single point
 in time, does not mean that it is definite as well, at customer site bugs
 may be found also in the packages that you do test.

Well, when you test on site by dev  qa you make sure you send something to the
customer - X. When the dependencies are updated out of band, the customer
actually is using X'.
I can see at least 2 things wrong here:
1. You're putting the customer in a position of a tester for the X' application.
2. If customer finds a bug he actually found it on X', whereas the developer who
would be assigned to the bug could be using X'' by now.

If you're so keen on packaging a jar outside WAR file, we need to specify
explicit version and not =.

 
  
  
  Sent from Samsung Mobile
  
   Original message 
  From: Alon Bar-Lev alo...@redhat.com
  Date: 07/05/2014  21:41  (GMT+02:00)
  To: Mike Kolesnik mkole...@redhat.com
  Cc: Yevgeny Zaspitsky yzasp...@redhat.com,devel@ovirt.org
  Subject: Re: [ovirt-devel] commons-collections v4.0
   
  
  
  - Original Message -
   From: Mike Kolesnik mkole...@redhat.com
   To: Alon Bar-Lev alo...@redhat.com
   Cc: Yevgeny Zaspitsky yzasp...@redhat.com, devel@ovirt.org
   Sent: Wednesday, May 7, 2014 9:34:03 PM
   Subject: Re: [ovirt-devel] commons-collections v4.0
   
   - Original Message -


- Original Message -
 From: Yevgeny Zaspitsky yzasp...@redhat.com
 To: Alon Bar-Lev alo...@redhat.com
 Cc: devel@ovirt.org
 Sent: Tuesday, April 22, 2014 11:39:11 AM
 Subject: Re: [ovirt-devel] commons-collections v4.0
 
 That means that we manage 2 separate environments:
 1. Development - relies on pom files. E.g. unit tests run with
 commons-collections v3.1 (and when I add v4.0) and succeed.

devenv will use runtime option.
you are right about the unit tests, these relays on the poms.
   
   I use devenv and it always uses the dev option not the runtime.
   So basically developers are using the pom specified versions and not what
   used in runtime.
   
   Even more so, in runtime it highly depends on what OS you're using, so
   someone
   developing on F19 might not be using same versions as a developer on F20
   and
   both are probably very different versions than on RHEL/CentOS.
   I won't even mention other OS`s.
   

 2. Run-time - relies on JBoss own dependencies that bring
 commons-collection
 v3.2.1-redhat-2.

in rhel case, yes.

 This kind of discrepancies might be found in other libraries as we do
 not
 synchronize our pom files with the JBoss current version
 dependencies.
 IMHO that could lead to some very difficult bugs that we won't be
 able
 to
 simulate in our unit tests.

correct, but the java way to pull dependencies at will without being
able
to
fix z-stream using central package management tools is more severe than
unit
tests not working/not working.

for example, your application uses x.jar and actually delivers x.jar...
so
from release to eternity it is your responsibility to track x.jar for
severe
stability bugs and security bugs, and release your entire application
each
time found, now multiple it with the # of components application is
using
and see how much effort you have