[Sisuite-devel] [ RFC ] SystemImager 4.0.2 or not? (was: client netboot fails (rsync: failed to set times))

[Andrea Righi]

Hi all,

it seems that someone is agree with me and someone is not about the solution to
add the pre-release of rsync (3.0.0pre4) into the stable branch of SystemImager
and tag the new 4.0.2 stable ASAP (4.0.1, since ".1" is odd, is reserved for
development pre-releases).

So, probably this is the first polling in these lists :-), don't know, but I
would really like to know opinion of the community about this issue.

The fact is that the current stable release of SystemImager 4.0.0 is not
"stable" enough: there is a bug that occurs with rsync when it's built on a
machine with a kernel >= 2.6.22 (that's actually my build server) and the
installing client uses a kernel < 2.6.22:

See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for details,
many thanks to Rochus Schmid for reporting this bug.

The proposed solutions for now are:

1) use the pre-release of rsync that seems to fix the problem and tag
SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say that I
would just proceed like the kernel guys do if there's a bug in the kernel (just
leave all the previous released kernels "forzen" and available for download in
any case, and always release new versions in case of errors/bugs)

2) remove the old 4.0.0 packages from SF.net (let me say "close" them to the
users), rebuild all the packages in a build server with a kernel < 2.6.22 and
then release the new packages using the same version number: 4.0.0

3) rebuild the packages in a build server with a kernel < 2.6.22 and changing
the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net

4) other ideas are welcome...

I vote for 1).

-Andrea

[Brian Elliott Finley]

Did we settle on a new numbering scheme? Where can I find it documented?

I'm thinking that 4.0.0 as stable, 4.0.1 as devel, and 4.0.2 as stable
again seems just a bit confusing.

Forgive me if I'm reading into this, or if I've missed an earlier email
detailing this, but I thought we were still using the "second" digit to
indicate development (4.1.0), and that the third digit still indicated a
bug-fix release (whether even or odd).

Thanks, -Brian

Post by Andrea Righi
Hi all,
it seems that someone is agree with me and someone is not about the solution to
add the pre-release of rsync (3.0.0pre4) into the stable branch of SystemImager
and tag the new 4.0.2 stable ASAP (4.0.1, since ".1" is odd, is reserved for
development pre-releases).
So, probably this is the first polling in these lists :-), don't know, but I
would really like to know opinion of the community about this issue.
The fact is that the current stable release of SystemImager 4.0.0 is not
"stable" enough: there is a bug that occurs with rsync when it's built on a
machine with a kernel >= 2.6.22 (that's actually my build server) and the
See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for details,
many thanks to Rochus Schmid for reporting this bug.
1) use the pre-release of rsync that seems to fix the problem and tag
SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say that I
would just proceed like the kernel guys do if there's a bug in the kernel (just
leave all the previous released kernels "forzen" and available for download in
any case, and always release new versions in case of errors/bugs)
2) remove the old 4.0.0 packages from SF.net (let me say "close" them to the
users), rebuild all the packages in a build server with a kernel < 2.6.22 and
then release the new packages using the same version number: 4.0.0
3) rebuild the packages in a build server with a kernel < 2.6.22 and changing
the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net
4) other ideas are welcome...
I vote for 1).
-Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
sisuite-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sisuite-devel

[Andrea Righi]

Post by Brian Elliott Finley
Did we settle on a new numbering scheme? Where can I find it documented?

http://wiki.systemimager.org/index.php/Developer_Guidelines#Versioning

Post by Brian Elliott Finley
I'm thinking that 4.0.0 as stable, 4.0.1 as devel, and 4.0.2 as stable
again seems just a bit confusing.

Sorry Brian, I meant "4.0.1 is reserved for unofficial pre-releases of 4.0.2
stable".

Post by Brian Elliott Finley
Forgive me if I'm reading into this, or if I've missed an earlier email
detailing this, but I thought we were still using the "second" digit to
indicate development (4.1.0), and that the third digit still indicated a
bug-fix release (whether even or odd).

Yes and no. Nothing changed in the second digit: odd numbers always mean
"unstable/development", even numers "stable". The third digit meaning has
changed: an odd number (N) indicates a pre-release or a release candidate for
the next even (N + 1) release. This is necesarry to correctly handle the RPM
update issue, that always requires strictly greater version numbers. Anyway, if
you have better ideas or improvements for the current versioning schema let me know.

-Andrea

[Bernard Li]

Post by Andrea Righi
Yes and no. Nothing changed in the second digit: odd numbers always mean
"unstable/development", even numers "stable". The third digit meaning has
changed: an odd number (N) indicates a pre-release or a release candidate for
the next even (N + 1) release. This is necesarry to correctly handle the RPM
update issue, that always requires strictly greater version numbers. Anyway, if
you have better ideas or improvements for the current versioning schema let me know.

Currently, the 'Release' tag in our RPM spec file always start with 1.

What we could do is with pre-releases, instead of 1, use 0 and also
append the SVN revision to this tag rather than to the version, so
instead of:

1.2.3.svn1234-1

it becomes

1.2.3-0.svn1234

so when 1.2.3-1 is released, we can upgrade.

Just another idea -- but I guess I have no issues with the current
scheme -- depends which one people prefer...

Cheers,

Bernard

[Andrea Righi]

Post by Bernard Li

Post by Andrea Righi
Yes and no. Nothing changed in the second digit: odd numbers always mean
"unstable/development", even numers "stable". The third digit meaning has
changed: an odd number (N) indicates a pre-release or a release candidate for
the next even (N + 1) release. This is necesarry to correctly handle the RPM
update issue, that always requires strictly greater version numbers. Anyway, if
you have better ideas or improvements for the current versioning schema let me know.

Currently, the 'Release' tag in our RPM spec file always start with 1.
What we could do is with pre-releases, instead of 1, use 0 and also
append the SVN revision to this tag rather than to the version, so
1.2.3.svn1234-1
it becomes
1.2.3-0.svn1234
so when 1.2.3-1 is released, we can upgrade.

That's very interesting solution for RPMs, but I think it wouldn't work for
Debian packages.

[dann frazier]

Post by Andrea Righi

Post by Bernard Li

Post by Andrea Righi
Yes and no. Nothing changed in the second digit: odd numbers always mean
"unstable/development", even numers "stable". The third digit meaning has
changed: an odd number (N) indicates a pre-release or a release candidate for
the next even (N + 1) release. This is necesarry to correctly handle the RPM
update issue, that always requires strictly greater version numbers. Anyway, if
you have better ideas or improvements for the current versioning schema let me know.

Currently, the 'Release' tag in our RPM spec file always start with 1.
What we could do is with pre-releases, instead of 1, use 0 and also
append the SVN revision to this tag rather than to the version, so
1.2.3.svn1234-1
it becomes
1.2.3-0.svn1234
so when 1.2.3-1 is released, we can upgrade.

That's very interesting solution for RPMs, but I think it wouldn't work for
Debian packages.

[Andrea Righi]

Post by Andrea Righi

Post by Bernard Li

Post by Andrea Righi
Yes and no. Nothing changed in the second digit: odd numbers always mean
"unstable/development", even numers "stable". The third digit meaning has
changed: an odd number (N) indicates a pre-release or a release candidate for
the next even (N + 1) release. This is necesarry to correctly handle the RPM
update issue, that always requires strictly greater version numbers. Anyway, if
you have better ideas or improvements for the current versioning schema let me know.

Currently, the 'Release' tag in our RPM spec file always start with 1.
What we could do is with pre-releases, instead of 1, use 0 and also
append the SVN revision to this tag rather than to the version, so
1.2.3.svn1234-1
it becomes
1.2.3-0.svn1234
so when 1.2.3-1 is released, we can upgrade.

That's very interesting solution for RPMs, but I think it wouldn't work for
Debian packages.

[Erich Focht]

The '~' operator in debs is pretty useful for doing pre-releases,
since it sorts < 0.
4.0.0~svn1234 is < 4.0.0.
4.0.1~rc1-1 < 4.0.0-1
etc.

And RPM doesn't support it... deb is good, RPM is evil. :-)

All this comes from the incrementation of the version number after tagging it.
If you leave the version number alone and increment it only when tagging:

4.0.0 < 4.0.0.svn1234 < 4.0.1 < 4.0.1.svn1300

Best regards,
Erich

[Andrea Righi]

Post by Erich Focht

The '~' operator in debs is pretty useful for doing pre-releases,
since it sorts < 0.
4.0.0~svn1234 is < 4.0.0.
4.0.1~rc1-1 < 4.0.0-1
etc.

And RPM doesn't support it... deb is good, RPM is evil. :-)

All this comes from the incrementation of the version number after tagging it.
4.0.0 < 4.0.0.svn1234 < 4.0.1 < 4.0.1.svn1300

yes, but I think 4.0.0.svn1234, for example, is a bit misleading: a user could
understand this as a pre-release of 4.0.0, instead of a pre-release of 4.0.1.

My $0.02

-Andrea

[Bernard Li]

Post by Andrea Righi
it seems that someone is agree with me and someone is not about the solution to
add the pre-release of rsync (3.0.0pre4) into the stable branch of SystemImager
and tag the new 4.0.2 stable ASAP (4.0.1, since ".1" is odd, is reserved for
development pre-releases).

I'm the 'someone' who does not agree with this :-) The main reason
being rsync is a key component of SystemImager, and using a
pre-release version (and mind you, a huge jump from 2.6.8 -> 3.0.0)
which has not been fully tested would bring the stability of the
release into question. Sure, 3.0.0pre4 might fix this particular
problem, but without full testing we will not know whether this brings
about _other_ issues that might be missed by both rsync and
systemimager developers/users.

Post by Andrea Righi
So, probably this is the first polling in these lists :-), don't know, but I
would really like to know opinion of the community about this issue.
The fact is that the current stable release of SystemImager 4.0.0 is not
"stable" enough: there is a bug that occurs with rsync when it's built on a
machine with a kernel >= 2.6.22 (that's actually my build server) and the
See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for details,
many thanks to Rochus Schmid for reporting this bug.
1) use the pre-release of rsync that seems to fix the problem and tag
SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say that I
would just proceed like the kernel guys do if there's a bug in the kernel (just
leave all the previous released kernels "forzen" and available for download in
any case, and always release new versions in case of errors/bugs)
2) remove the old 4.0.0 packages from SF.net (let me say "close" them to the
users), rebuild all the packages in a build server with a kernel < 2.6.22 and
then release the new packages using the same version number: 4.0.0
3) rebuild the packages in a build server with a kernel < 2.6.22 and changing
the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net
4) other ideas are welcome...
I vote for 1).

Okay, this is my suggestion:

Since 4.0.0 is already released, we should just leave it. I do not
feel strongly either way whether we decide to hide this release or
not, but one argument for hiding it would be that the binaries are
broken for users running Kernel < 2.6.22 (which I would think are the
majority of the users). I wouldn't want a new user to somehow stumble
upon the link for 4.0.0 and download something that does not work.

My suggestion would be to increment the version number (for no
particular reason than to keep it distinct from the bad 4.0.0 release)
and simply rebuild all the files on a server that is running Kernel <
2.6.22 (RPM, deb etc.) and (re)-release that.

I also think it would not be unreasonable to postpone the release
until we can get some more testing done -- let's call this beta, and
then after getting some more testing, we make the release.

I would like to take this opportunity to invite the community to help
us grow the project. The developers have put in a great deal of time
and effort into adding new features and as we support more features
and distribution/versions etc., we really need more volunteers to help
us test the software before we release it. This will ensure that our
code is as stable as possible prior to release.

For argument's sake, I will call this solution b) :-) I'd like to
cast my vote on b)

Cheers,

Bernard

[Erich Focht]

Hi,

I'm for 1), too. If Brian's right and there was a decision on having the second
digit as sign for stability, then I'd rather make it 4.0.1.

If the architecture change of trunk is big enough for getting a 4.1.X version,
better move 4.0.X into a si-4.0 branch, and evolve it separately into 4.0.1/2/3...

Whether rsync is called 2.6.X or 3.0.X, I'm optimistic that code is generally
improving. If the new version does the job, why not?

Can you change the release notes of the 4.0.0 version on the sourceforge page?
If you can add a comment on the bug, you should leave the version there. But
it has no value, actually, once you added the fixed version. You're not deleting
the svn tags, so old versions are still available, even if you remove the buggy
things from SF.net.

Regards,
Erich

Post by Andrea Righi
Hi all,
it seems that someone is agree with me and someone is not about the solution to
add the pre-release of rsync (3.0.0pre4) into the stable branch of SystemImager
and tag the new 4.0.2 stable ASAP (4.0.1, since ".1" is odd, is reserved for
development pre-releases).
So, probably this is the first polling in these lists :-), don't know, but I
would really like to know opinion of the community about this issue.
The fact is that the current stable release of SystemImager 4.0.0 is not
"stable" enough: there is a bug that occurs with rsync when it's built on a
machine with a kernel >= 2.6.22 (that's actually my build server) and the
See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for details,
many thanks to Rochus Schmid for reporting this bug.
1) use the pre-release of rsync that seems to fix the problem and tag
SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say that I
would just proceed like the kernel guys do if there's a bug in the kernel (just
leave all the previous released kernels "forzen" and available for download in
any case, and always release new versions in case of errors/bugs)
2) remove the old 4.0.0 packages from SF.net (let me say "close" them to the
users), rebuild all the packages in a build server with a kernel < 2.6.22 and
then release the new packages using the same version number: 4.0.0
3) rebuild the packages in a build server with a kernel < 2.6.22 and changing
the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net
4) other ideas are welcome...
I vote for 1).
-Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
sisuite-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sisuite-devel

[Andrea Righi]

Post by Erich Focht
Hi,
I'm for 1), too. If Brian's right and there was a decision on having the second
digit as sign for stability, then I'd rather make it 4.0.1.

As I said in the previous email, the next "official" version should be 4.0.2,
according to the new versioning rules (4.0.1 is reserved for pre-releases of 4.0.2):

http://wiki.systemimager.org/index.php/Developer_Guidelines#Versioning

Post by Erich Focht
Can you change the release notes of the 4.0.0 version on the sourceforge page?

Sounds good. Done:

http://sourceforge.net/project/shownotes.php?group_id=259&release_id=551739

Post by Erich Focht
If you can add a comment on the bug, you should leave the version there. But
it has no value, actually, once you added the fixed version. You're not deleting
the svn tags, so old versions are still available, even if you remove the buggy
things from SF.net.

Thanks,
-Andrea

[Andrea Righi]

Post by Andrea Righi
1) use the pre-release of rsync that seems to fix the problem and tag
SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say that I
would just proceed like the kernel guys do if there's a bug in the kernel (just
leave all the previous released kernels "forzen" and available for download in
any case, and always release new versions in case of errors/bugs)
2) remove the old 4.0.0 packages from SF.net (let me say "close" them to the
users), rebuild all the packages in a build server with a kernel < 2.6.22 and
then release the new packages using the same version number: 4.0.0
3) rebuild the packages in a build server with a kernel < 2.6.22 and changing
the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net
4) other ideas are welcome...

After few days the result of the polling seems to be the following:

- 3 votes for solution #1
- 3 votes for solution #2

So, nothing changed... :-) Let me try to formulate a reasonable compromise...
What do you think about tagging 4.1.0 (based on the current trunk), release
4.1.0 (unstable) and if we don't see any bug report for a week backport the
4.1.0 patches in the stable branch and tag 4.0.2?

-Andrea

[Bernard Li]

Post by Andrea Righi
- 3 votes for solution #1
- 3 votes for solution #2
So, nothing changed... :-) Let me try to formulate a reasonable compromise...
What do you think about tagging 4.1.0 (based on the current trunk), release
4.1.0 (unstable) and if we don't see any bug report for a week backport the
4.1.0 patches in the stable branch and tag 4.0.2?

More testing = good -- If we can get a bunch of volunteers to sign up
and test different distroes/archs for the upcoming release that would
be awesome.

Just thought I'd try to engage the community once again.

Thanks for putting together the release, Andrea.

Cheers,

Bernard

[Brian Elliott Finley]

I like this the best, and think it is the most straightforward. We
should clearly document whatever we do in the download section of the
wiki, and in the DEVELOPERS file.

-Brian

Post by Erich Focht

The '~' operator in debs is pretty useful for doing pre-releases,
since it sorts < 0.
4.0.0~svn1234 is < 4.0.0.
4.0.1~rc1-1 < 4.0.0-1
etc.

And RPM doesn't support it... deb is good, RPM is evil. :-)

All this comes from the incrementation of the version number after tagging
it.
4.0.0 < 4.0.0.svn1234 < 4.0.1 < 4.0.1.svn1300
Best regards,
Erich
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
sisuite-devel mailing list
https://lists.sourceforge.net/lists/listinfo/sisuite-devel