Re: IPFire 2.17 - Core Update 91 release schedule

Re: IPFire 2.17 - Core Update 91 release schedule

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

Hello,

just follow this guide:

http://wiki.ipfire.org/en/configuration/ipfire/pakfire/testing

-Michael

On Thu, 2015-06-11 at 11:44 +0200, Jan Lentfer wrote:
> Hi, could you shortly describe (possibly once more) how can follow the testing branch instead of the stable branch? TIA Jan
> 
> Von meinem iPad gesendet
> 
> > Am 11.06.2015 um 10:51 schrieb Michael Tremer <michael.tremer(a)ipfire.org>:
> > 
> > Hello,
> > 
> > I just wanted to update you quickly about the upcoming Core Update 91
> > release plan.
> > 
> > There will be a new OpenSSL release at some time today (Thursday) which
> > fixes several security vulnerabilities in this library. We do not know
> > much about the severity of those vulnerabilities, yet, but we will
> > release a new Core Update any ways.
> > 
> > The changes that have been pushed into the next branch will be released
> > as well with an exception of Python. The Python package won't build on
> > some systems and due to lack of time to debug this properly the Python
> > update has been postponed.
> > 
> > As soon as the OpenSSL update is released we will start the build. We
> > expect this to be late at night (as it has been in the past) and
> > therefore the will be a build available Friday morning/noon European
> > time. The ARM build will take much longer to complete though.
> > 
> > We will push that build to the testing tree so that as many people can
> > help testing as possibly can.
> > 
> > If everything goes well we intend to release the final update 24 hours
> > after that - which will be Saturday some time after mid day.
> > 
> > Best,
> > -Michael
> > 
> > P.S. I was asked to send a short release plan for Core Updates on this
> > list because it is not so easy to find out what the current status is
> > sometimes. I would like your feedback about if this is a good idea and
> > if this is helping. I am hoping that it is helping us to engage more
> > testers into the testing procedure of new Core Updates and let you plan
> > some time for doing that.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Aw: Re: IPFire 2.17 - Core Update 91 release schedule

[Bernhard Bitsch]

[-- Attachment #1: Type: text/plain, Size: 3218 bytes --]

Hi,

a thread in the forum showed up a little issue in our tests.
Some parts, don't know how many, just have a status of "untouched for a long time".
This is mainly true for Perl scripts in the WUI.
I would be a big effort to check all this files.
But some issues will come in sight, if at least during test period these files contain the lines

use strict;
use warnings;
use CGI::Carp 'fatalsToBrowser';

Perl does tolerate so much dirty coding. In such cases it isn't sure whether the intentions of the programmer meet the interpretation of the interpreter.
These three lines force a check and log possible errors to the WUI.

I fear, without these statements a couple of faulty test cases are reported as error-free.

Bernhard

> Gesendet: Donnerstag, 11. Juni 2015 um 11:46 Uhr
> Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
> An: "Jan Lentfer" <Jan.Lentfer(a)web.de>
> Cc: "development(a)lists.ipfire.org" <development(a)lists.ipfire.org>
> Betreff: Re: IPFire 2.17 - Core Update 91 release schedule
>
> Hello,
> 
> just follow this guide:
> 
> http://wiki.ipfire.org/en/configuration/ipfire/pakfire/testing
> 
> -Michael
> 
> On Thu, 2015-06-11 at 11:44 +0200, Jan Lentfer wrote:
> > Hi, could you shortly describe (possibly once more) how can follow the testing branch instead of the stable branch? TIA Jan
> > 
> > Von meinem iPad gesendet
> > 
> > > Am 11.06.2015 um 10:51 schrieb Michael Tremer <michael.tremer(a)ipfire.org>:
> > > 
> > > Hello,
> > > 
> > > I just wanted to update you quickly about the upcoming Core Update 91
> > > release plan.
> > > 
> > > There will be a new OpenSSL release at some time today (Thursday) which
> > > fixes several security vulnerabilities in this library. We do not know
> > > much about the severity of those vulnerabilities, yet, but we will
> > > release a new Core Update any ways.
> > > 
> > > The changes that have been pushed into the next branch will be released
> > > as well with an exception of Python. The Python package won't build on
> > > some systems and due to lack of time to debug this properly the Python
> > > update has been postponed.
> > > 
> > > As soon as the OpenSSL update is released we will start the build. We
> > > expect this to be late at night (as it has been in the past) and
> > > therefore the will be a build available Friday morning/noon European
> > > time. The ARM build will take much longer to complete though.
> > > 
> > > We will push that build to the testing tree so that as many people can
> > > help testing as possibly can.
> > > 
> > > If everything goes well we intend to release the final update 24 hours
> > > after that - which will be Saturday some time after mid day.
> > > 
> > > Best,
> > > -Michael
> > > 
> > > P.S. I was asked to send a short release plan for Core Updates on this
> > > list because it is not so easy to find out what the current status is
> > > sometimes. I would like your feedback about if this is a good idea and
> > > if this is helping. I am hoping that it is helping us to engage more
> > > testers into the testing procedure of new Core Updates and let you plan
> > > some time for doing that.
> 

Re: perl code cleanup (was: IPFire 2.17 - Core Update 91 release schedule)

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 4837 bytes --]

Hi Bernhard,

I am not really sure in what way this is related to this Core Update. I
guess it is not.

On Thu, 2015-06-11 at 15:55 +0200, Bernhard Bitsch wrote:
> Hi,
> 
> a thread in the forum showed up a little issue in our tests.

Which one?

> Some parts, don't know how many, just have a status of "untouched for a long time".

Indeed, we won't touch the web user interface in order to clean up the
code if we do not need to. It has been a nightmare from the very
beginning since we forked the project. We never invested much into
cleaning up the code because there will be a complete rewrite of the
entire thing.

That does not mean that we don't fix bugs though.

> This is mainly true for Perl scripts in the WUI.

Yes. Some other things have been replaced over time. The most recent
example is the setddns.pl script that was replaced by ddns.

> I would be a big effort to check all this files.
> But some issues will come in sight, if at least during test period these files contain the lines
> 
> use strict;
> use warnings;
> use CGI::Carp 'fatalsToBrowser';
> 
> Perl does tolerate so much dirty coding. In such cases it isn't sure whether the intentions of the programmer meet the interpretation of the interpreter.
> These three lines force a check and log possible errors to the WUI.

I am not really sure what you are saying here. If you want to clean up
the code that would be helpful. Eventually we will have to update our
version of perl and we know that huge chunks of the web user interface
code are incompatible to that. I have never done any actual testing if
it works but we have many features in the code that have been removed.
There is for example the smart match operator.

> I fear, without these statements a couple of faulty test cases are reported as error-free.

Of course we cannot ship code that will show error messages to the user.
Those changes should be also very small so that they can be easily
reviewed and should not cause too much damage. It is just essential to
keep the development process tidy to not create an even bigger mess.

New functionality or changed functionality should be done in separate
patches of course.

-Michael

> 
> Bernhard
> 
> > Gesendet: Donnerstag, 11. Juni 2015 um 11:46 Uhr
> > Von: "Michael Tremer" <michael.tremer(a)ipfire.org>
> > An: "Jan Lentfer" <Jan.Lentfer(a)web.de>
> > Cc: "development(a)lists.ipfire.org" <development(a)lists.ipfire.org>
> > Betreff: Re: IPFire 2.17 - Core Update 91 release schedule
> >
> > Hello,
> > 
> > just follow this guide:
> > 
> > http://wiki.ipfire.org/en/configuration/ipfire/pakfire/testing
> > 
> > -Michael
> > 
> > On Thu, 2015-06-11 at 11:44 +0200, Jan Lentfer wrote:
> > > Hi, could you shortly describe (possibly once more) how can follow the testing branch instead of the stable branch? TIA Jan
> > > 
> > > Von meinem iPad gesendet
> > > 
> > > > Am 11.06.2015 um 10:51 schrieb Michael Tremer <michael.tremer(a)ipfire.org>:
> > > > 
> > > > Hello,
> > > > 
> > > > I just wanted to update you quickly about the upcoming Core Update 91
> > > > release plan.
> > > > 
> > > > There will be a new OpenSSL release at some time today (Thursday) which
> > > > fixes several security vulnerabilities in this library. We do not know
> > > > much about the severity of those vulnerabilities, yet, but we will
> > > > release a new Core Update any ways.
> > > > 
> > > > The changes that have been pushed into the next branch will be released
> > > > as well with an exception of Python. The Python package won't build on
> > > > some systems and due to lack of time to debug this properly the Python
> > > > update has been postponed.
> > > > 
> > > > As soon as the OpenSSL update is released we will start the build. We
> > > > expect this to be late at night (as it has been in the past) and
> > > > therefore the will be a build available Friday morning/noon European
> > > > time. The ARM build will take much longer to complete though.
> > > > 
> > > > We will push that build to the testing tree so that as many people can
> > > > help testing as possibly can.
> > > > 
> > > > If everything goes well we intend to release the final update 24 hours
> > > > after that - which will be Saturday some time after mid day.
> > > > 
> > > > Best,
> > > > -Michael
> > > > 
> > > > P.S. I was asked to send a short release plan for Core Updates on this
> > > > list because it is not so easy to find out what the current status is
> > > > sometimes. I would like your feedback about if this is a good idea and
> > > > if this is helping. I am hoping that it is helping us to engage more
> > > > testers into the testing procedure of new Core Updates and let you plan
> > > > some time for doing that.
> > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Aw: Re: perl code cleanup (was: IPFire 2.17 - Core Update 91 release schedule)

[Bernhard Bitsch]

[-- Attachment #1: Type: text/plain, Size: 3793 bytes --]

Hi Michael,

> Hi Bernhard,
> 
> I am not really sure in what way this is related to this Core Update. I
> guess it is not.
> 

You are right. I was just thinking about a post to the mailing list, when your annoucement about the new test release arrived.
Because of the relation to testing, I posted my proposal in this thread.


> On Thu, 2015-06-11 at 15:55 +0200, Bernhard Bitsch wrote:
> > Hi,
> > 
> > a thread in the forum showed up a little issue in our tests.
> 
> Which one?

https://forum.ipfire.org/viewtopic.php?f=22&t=13965&p=86585#p86576
When looking at the code of this web page, I found errors ( the standard language files are not used, "undefined" vars ) which are reported by switching on the debug output.

 
> > Some parts, don't know how many, just have a status of "untouched for a long time".
> 
> Indeed, we won't touch the web user interface in order to clean up the
> code if we do not need to. It has been a nightmare from the very
> beginning since we forked the project. We never invested much into
> cleaning up the code because there will be a complete rewrite of the
> entire thing.

Nevertheless there are possible errors or "issues" in this code.


> That does not mean that we don't fix bugs though.
> 
> > This is mainly true for Perl scripts in the WUI.
> 
> Yes. Some other things have been replaced over time. The most recent
> example is the setddns.pl script that was replaced by ddns.

If we don't know the errors, they can't be fixed. My proposal reports those deficiencies.
Even whilst testing phase this should be done.



> > I would be a big effort to check all this files.
> > But some issues will come in sight, if at least during test period these files contain the lines
> > 
> > use strict;
> > use warnings;
> > use CGI::Carp 'fatalsToBrowser';
> > 
> > Perl does tolerate so much dirty coding. In such cases it isn't sure whether the intentions of the programmer meet the interpretation of the interpreter.
> > These three lines force a check and log possible errors to the WUI.
> 
> I am not really sure what you are saying here. If you want to clean up
> the code that would be helpful. Eventually we will have to update our
> version of perl and we know that huge chunks of the web user interface
> code are incompatible to that. I have never done any actual testing if
> it works but we have many features in the code that have been removed.
> There is for example the smart match operator.
>

A new version of Perl doesn't really help. The Perl interpreter is built around compatibility to older versions and coding styles.
To achieve this assumptions about the semantics of the "dirty code" are made. These must not meet the intention of the programmer of the original code.



> > I fear, without these statements a couple of faulty test cases are reported as error-free.
> 
> Of course we cannot ship code that will show error messages to the user.

This is an old discussion in software development: "Should the released code contain checks for correctness ( 'assert' in C, 'use strict' in Perl, ...)?"
My (personal) answer: Yes! Because these errors shouldn't show up in the shipped product, but the conditions proven are essential for a effective functioning.


> Those changes should be also very small so that they can be easily
> reviewed and should not cause too much damage. It is just essential to
> keep the development process tidy to not create an even bigger mess.
> 

In first application the addition proposed is small ( 3 lines per cgi file) and doesn't change processing of programs without "issues".
The corrections for errors shown may be of a greater extent. But they are necessary, thus the effort is legitimate.

Bernhard