Hi all.
At the meeting we discussed that would be a good release official update for 3.5.13 soon. In connection with the fact that 1 May it be just half a year since the release of 3.5.13, it occurred to me that it could be a nice term for the release official updates.
Therefore I would like to discuss with you:
__1__ Is this term too soon? Can it be manageable? Which patches to wait?
Already have poised: + patch to close #372 + other patches from #675 + workaround for #922 + waiting for a patch for #258 + considering revert patch for #394
I would like (but want to wait?) + fix SAK. Does anyone work on it? Or temporarily turn it off? + find a solution for #812 + find a solution for #744, #615
__2__ Giving an update the new version number? Apply here mentioned a few times R13.1 (or R13.1.0)? They should be in this case, the patches in their own branch in GIT? Change the version number in the names of all packages (some are otherwise unchanged)? Or just change the version number within kdelibs and file names leave them unchanged? Or simply release already prepared packages without changing the version number?
What do you think? I look forward to your comments
Slávek --
At the meeting we discussed that would be a good release official update for 3.5.13 soon. In connection with the fact that 1 May it be just half a year since the release of 3.5.13, it occurred to me that it could be a nice term for the release official updates.
Therefore I would like to discuss with you:
__1__ Is this term too soon?
This time is as good as any. There are a slew of build and usability issues to resolve before R14 comes close for consideration for release.
Can it be manageable?
Sure.
Which patches to wait?
I uploaded a bunch of patches that fix HTML help page installations. Everything now installs in the same location. I'm unsure of a good strategy to back port them all.
I uploaded a slew of patches that fix numerous problems with kipi-plugins, digikam, and gwenview.
In that latter effort I discovered more inadvertent "TQ" conversions that likely cause occasional breakage.
Already have poised:
- patch to close #372
The patch seems to have resolved the problem here.
- other patches from #675
Fixing the starttde script likely is an ongoing project. I would just backport every time there is an update.
- workaround for #922
Every several days I look into this hoping I'll notice something different. Thus far no luck.
- waiting for a patch for #258
Calvin said Friday.
- considering revert patch for #394
I haven't been having any problems since reverting the patch. I'm running GIT, however, and not 3.5.13.
I would like (but want to wait?)
- fix SAK. Does anyone work on it? Or temporarily turn it off?
I haven't noticed anybody addressing the issues. SAK can be disabled two ways: through KControl, and with the build configuraton.
- find a solution for #812
No experience or testing here.
- find a solution for #744, #615
Recently in this list we discussed these svg failures. Would be nice if they could be resolved for your release. Some of the svgz background images were duplicated as png images and I pushed those all to GIT recently.
__2__ Giving an update the new version number? Apply here mentioned a few times R13.1 (or R13.1.0)?
Release as 3.5.13.1 or 3.5.13a. Otherwise many users will get confused. The "R14" versioning system should be saved for when R14 is releases. Press releases will address why we changed the release version scheme.
I hope this helps!
Darrell
On Fri, Apr 13, 2012 at 5:20 AM, Darrell Anderson humanreadable@yahoo.comwrote:
At the meeting we discussed that would be a good release official update for 3.5.13 soon. In connection with the fact that 1 May
it
be just half a year since the release of 3.5.13, it occurred to me that
it
could be a nice term for the release official updates.
Therefore I would like to discuss with you:
__1__ Is this term too soon?
This time is as good as any. There are a slew of build and usability issues to resolve before R14 comes close for consideration for release.
Can it be manageable?
Sure.
Which patches to wait?
I uploaded a bunch of patches that fix HTML help page installations. Everything now installs in the same location. I'm unsure of a good strategy to back port them all.
I uploaded a slew of patches that fix numerous problems with kipi-plugins, digikam, and gwenview.
In that latter effort I discovered more inadvertent "TQ" conversions that likely cause occasional breakage.
Already have poised:
- patch to close #372
The patch seems to have resolved the problem here.
- other patches from #675
Fixing the starttde script likely is an ongoing project. I would just backport every time there is an update.
- workaround for #922
Every several days I look into this hoping I'll notice something different. Thus far no luck.
- waiting for a patch for #258
Calvin said Friday.
- considering revert patch for #394
I haven't been having any problems since reverting the patch. I'm running GIT, however, and not 3.5.13.
I would like (but want to wait?)
- fix SAK. Does anyone work on it? Or temporarily turn it off?
I haven't noticed anybody addressing the issues. SAK can be disabled two ways: through KControl, and with the build configuraton.
- find a solution for #812
No experience or testing here.
- find a solution for #744, #615
Recently in this list we discussed these svg failures. Would be nice if they could be resolved for your release. Some of the svgz background images were duplicated as png images and I pushed those all to GIT recently.
__2__ Giving an update the new version number? Apply here mentioned a few times R13.1 (or R13.1.0)?
Release as 3.5.13.1 or 3.5.13a. Otherwise many users will get confused. The "R14" versioning system should be saved for when R14 is releases. Press releases will address why we changed the release version scheme.
AFAIK, using 3.5.13.1 may be better if some script needs to check version numbers, though this would certainly be more aptly versioned as 3.5.14. Seeing R14 using 3.6.0 would also be more apt, IMHO. I get the breaking with KDE legacy but it probably isn't practical to take it that far. It seems that non-debian package systems would be happier to see sequential and number only versioning than what has been proposed. (though I imagine upgrading from kde to tde will lead to whole new packages, appending letters to the version number seems a bad idea nonetheless).
Best regards, Tiago
I hope this helps!
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Dne pá 13. dubna 2012 Darrell Anderson napsal(a):
__2__ Giving an update the new version number? Apply here mentioned a few times R13.1 (or R13.1.0)?
Release as 3.5.13.1 or 3.5.13a. Otherwise many users will get confused. The "R14" versioning system should be saved for when R14 is releases. Press releases will address why we changed the release version scheme.
I hope this helps!
Darrell
Yes, I understand. Now R13.x could be confusing ==> rejected.
Because TDE uses three levels of version number - major - minor - release, and expects only numbers, we can not add or fourth number, or letters to the third number (release). Raising the "release" from 13 to 14 we certainly do not want.
I therefore suggest leave the real version number at 3.5.13 and use "3.5.13a" only in KDE_VERSION_STRING. Unchanged could possibly be also 3.5.13 in the names of packages.
What do you think?
Slávek --
Yes, I understand. Now R13.x could be confusing ==> rejected.
Because TDE uses three levels of version number - major - minor - release, and expects only numbers, we can not add or fourth number, or letters to the third number (release). Raising the "release" from 13 to 14 we certainly do not want.
I therefore suggest leave the real version number at 3.5.13 and use "3.5.13a" only in KDE_VERSION_STRING. Unchanged could possibly be also 3.5.13 in the names of packages.
What do you think?
I think the only "real" problem is packaging. I doubt many users care whether the patch release still says 3.5.13 in various output strings. Only the distro packaging mechanism needs a way to distinguish the difference.
Perhaps then don't worry abvout internal strings and instead provide intructions for creating unique packages.
Darrell
Dne pá 13. dubna 2012 Darrell Anderson napsal(a):
I uploaded a bunch of patches that fix HTML help page installations. Everything now installs in the same location. I'm unsure of a good strategy to back port them all.
I uploaded a slew of patches that fix numerous problems with kipi-plugins, digikam, and gwenview.
In that latter effort I discovered more inadvertent "TQ" conversions that likely cause occasional breakage.
Thank you for the tqt repairs. This extends number of updated packages. So I try to delve deeper in patches and try to fish as well as all:
+ Rename old tq methods that no longer need a unique name + Remove additional unneeded tq method conversions + Rename obsolete tq methods to standard names + Rename a few stragglers + ... and other tqt repairs that I have not caught
Process all of this but I will take some time. Then even time for testing at me and at others. I do not know if it will be before 1. May ready for official release. Never mind, especially that it ever will :)
Slávek --
Thank you for the tqt repairs. This extends number of updated packages. So I try to delve deeper in patches and try to fish as well as all:
- Rename old tq methods that no longer need a unique name
- Remove additional unneeded tq method conversions
- Rename obsolete tq methods to standard names
- Rename a few stragglers
- ... and other tqt repairs that I have not caught
Process all of this but I will take some time. Then even time for testing at me and at others. I do not know if it will be before 1. May ready for official release. Never mind, especially that it ever will :)
Thanks. :)
Please be aware that the recent scrubbing does not mean all potentially related bugs have been resolved. As David and I discovered a few days ago, the scrubbing in tde-style-qtcurve exposed a remnant patch that likely originally was intended to overcome problems caused by the inadvertent TQ renaming. Without the inadvertent renaming, the patch caused a build failure. Yet that single event helps us now understand what to watch for with any remaining cleanup that might be needed.
With that said, I suspect almost all of the previous inadvertent TQ related bugs probably are gone. I won't be surprised if a few related bugs remain, but let's just find them and resolve them. Let's put this TQ debate behind us and move one.
Yes, the TQt transition caused some bumps and regressions and has been frustrating in certain ways. But I had a decent night's sleep, feel rested, and want to put that all behind us. :)
To anybody who hasn't, please read the wiki article about TQt. Even I understood. :)
Darrell
-
Darrell Anderson -
Slávek Banko -
Tiago Marques