Re: PIM: Version alignment
On Saturday 17 September 2016 08:22:20 Ben Cooksley wrote: > From their perspective their distribution shipped them Applications > 15.10 (as that will be what the release notes say) yet when they got > to report a bug they won't find those version numbers. This argument is flawed. It ignores that a lot of KDE applications (actually most KDE applications) are not released as part of a KDE Applications release. Obviously, none of these KDE applications shares the version number of the KDE Applications release. Are the users confused about the versions of those applications, too? Taking your argument one step further: Any application released with Ubuntu 16.04 (to name a random example) should share the same version number because otherwise users could be confused if they wanted to report a bug in an application shipped with Ubuntu 16.04. I hope that the absurdity of this proposal is obvious. If a user is confused about the version of a specific application, then a simple check of Help->About (or an --version on the command line) will clarify the version. And if Help->Report Bug does not automatically set the correct version, then the application's maintainer is not doing his/her job properly (or the Report Bug functionality or Bugzilla is broken). Moreover, I agree that it's confusing for potential contributors that the tags in the repositories do not match the version numbers. This should be fixed by creating tags matching the version numbers additionally to the KDE_Applications_YY.MM tags. IMO that's also part of the maintainers' job for all applications that are part of the KDE Applications release, but that do not share the KDE Applications version number. Last, but not least, all applications that are part of the KDE Applications release should define their version in a standardized way, so that it can be extracted automatically to update Bugzilla and maybe also to set the additional version tag. > Also, these > versions have already been added on Bugzilla, so the confusion is > present amongst our own developers as well. The version numbers in Bugzilla can be fixed easily. Even for long released applications. > From my perspective, this discord should be eliminated by harmonizing > the version numbers. A partial harmonization of the version numbers (because you cannot harmonize the version numbers of all KDE applications) won't fix anything. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: [Kde-scm-interest] Re: git BoF
On Saturday 25 June 2011, Raphael Kubo da Costa wrote: On Thursday 23 June 2011 14:13:01 Ian Monroe wrote: I'm thinking we should have a KDE Git transition BoF. One thought is that the Git BoF happen after the release team BoF so that they can be given the opportunity to add stuff to our agenda. Do you have anything in mind for this BoF which wouldn't fit in the release- team BoF itself? I think the audience for both BoFs is very different. The Git transition BoF appears to address projects which did not yet do the transition to Git while the release team BoF appears to address people interested in doing release work. (Or maybe I'm reading too much from the BoFs' titles.) Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Keeping binary compatibility
On Friday 01 October 2010, Lubos Lunak wrote: Hello, as you probably know, the theory is that KDE libraries keep backwards binary compatibility. As you might or might not know, that is the theory. I've found a tool called abi-compliance-checker (http://ispras.linux-foundation.org/index.php/ABI_compliance_checker) and it has a page with checks for various libraries including ours (http://linuxtesting.org/upstream-tracker/versions/kde-libs.html), which is not as green as it should be. I've also compared openSUSE packages for 4.4.4 and 4.5.1 and there are problems too (http://ktown.kde.org/~seli/abi/ for what I checked). Let me point out just one, http://reviewboard.kde.org/r/2608/ , which I think shows that this occassionally happening is inevitable. Moreover, there seem to be cases where we simply don't seem to have rules (or at least I couldn't find them). Where did you look for the rules? Did you read [1]? Do we have rules that say more than kdelibs is BC stable, we don't care about the rest? Yes, kind of. See [1] What's the status with e.g. kdeedu libs? No BC. See [1] I'm asking because, consider e.g. these errors from an attempt to uninstall kdebase/workspace package here: [snip] Looking at how KDE provides various libraries leads to a number of WTH questions, like: - WTH is the ABI stability documented, besides kdelibs? See [1] Regards, Ingo [1] http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] KDEPIM Needs More TIme
On Friday 14 May 2010, Allen Winter wrote: Howdy All, I regret to inform everyone that kdepim will not be ready for a 4.5 Beta1 that is scheduled to happen in a few days. We estimate an extra month will be needed. Unfortunately, the massive porting effort to Akonadi (an even bigger job than the Qt3/KDE3 - Qt4/KDE4 port) is taking longer than we anticipated. So, we have a couple of choices: 1) insert a 1 month long alpha [1], thereby delaying 4.5.0 by 1 month 2) keep kdepim out of 4.5.0 and release it separately 1 month later 3) keep kdepim out of 4.5.0 and release it again for 4.6.0 Of course, I'd opt for choice 1. But there is simply no way we can put kdepim out there even in a beta at this time. My suggestion (as an outsider) is to opt for choice 3 or, more precisely, to opt for the following variant of 3: - Take the time until 4.6.0 to make the Akonadi port of kdepim rock. - Move current trunk/KDE/kdepim to a branch. - Copy current branches/KDE/4.4/kdepim to trunk, i.e. revive kdepim 4.4 for KDE SC 4.5. - Probably keep kaddressbook trunk. - Optionally, spend the time until 4.5.0 to fix the most annoying shortcomings in kdepim 4.4. IMHO it does not make any sense to rush the completion of the Akonadi port of kdepim. We got enough beating (e.g. on kdepim-users) for releasing the incomplete rewrite of KAddressBook with all of its migration problems with 4.4. To prevent a similar experience with the Akonadi ports of KMail, KOrganizer, etc., we need an extended alpha and beta phase, not shortened ones. If the Akonadi port of kdepim is ready for alpha or beta testing in a couple of months then we can (and should) make an alpha/beta release of kdepim (based on KDE SC 4.5) for those who are willing to play guinea pig. Just my 2 cent as former maintainer of KMail and as support engineer for problems with kdepim 4.4 (mostly KAddressBook), Akonadi and Nepomuk on kdepim-users. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] Fwd: Re: KDE 4.4.98 (4.4 RC3)
On Friday 05 February 2010, Thomas McGuire wrote: Hi, On Thursday 04 February 2010 21:58:46 Sebastian Kügler wrote: On Monday 01 February 2010 14:29:52 Arkadiusz Miskiewicz wrote: https://bugs.kde.org/show_bug.cgi?id=211128 https://bugs.kde.org/show_bug.cgi?id=96 Bug 96 exists as long as Kontact exists, i.e. since KDE 3.something. On Thursday 04 February 2010 19:33:25 Dirk Mueller wrote: both seem to be present in 4.4.0 as well. does anyone know which commits introduced those bugs? PIMsters, any idea? I commented on both bugs. While they might be annoying, they are hardly hat important and IMHO don't warrant posting to the release-team mailing list. FWIW, I fully agree with Thomas's assessment. Regards, Ingo signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
