--===============2730881600902509800== Content-Type: multipart/alternative; boundary=e89a8fb206a8f464a404d186a2c8 --e89a8fb206a8f464a404d186a2c8 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Dec 23, 2012 at 8:01 PM, Frank Reininghaus wrote: > I agree with Sebastian - the freezes are there for a reason. I > appreciate all offers to help with testing in the remaining time until > the 4.10.0 release, but if that was really enough to make sure that > there are no regressions, then we could just drop the betas and > release a single RC in the future. That's making a very generalized statement, and ignoring the current situation. Please look at how much the code has changed from the 4.9. I'm not advocating shipping something written from scratch this late into the schedule. > However, past experience shows that > the user feedback that we get for the 4 unstable releases before each > 4.x.0 release helps to find many annoying bugs, but is still not > enough to prevent that a few regressions make it into 4.x.0. Yes, we > do have 4.x.1 and further bug fix releases, but in the end, users just > don't like it when there are new bugs in 4.x.0, and I perfectly > understand that. Users always dislike bugs. We all understand that. > The angry bug reports would end up in my inbox, and > the reporters would even be right because I would be responsible for > any problems if I approved the use of code that has not seen any wide > testing before RC 2. > That's for the general case. You have to look at exactly what I'm proposing and how much the code has changed. The answer is not much. I understand that almost all code have bugs, but you should at least look at the uses cases of this widget, and if my patch satisfies all of the use cases you can think of. > Therefore, I think that using the new widget in Dolphin should not > happen before KDE 4.11. Users who really want to use it earlier can > just build Dolphin from source and apply the patch (which is not that > hard even if you do not use a source-based distro, just install the > kdelibs headers and then perform a few simple steps). > This rules out about 99% of the users. I also thought again about Vishesh's argument that he would "have to > spend 2-3 days (maybe even more?)" if we do not use the new widget in > KDE 4.10, and I must say that I do not understand this at all. How can > can using the old widget in KDE 4.10 make the user experience worse > than in KDE 4.9 if he does not spend 2-3 days hacking on the old code? > You loose consistency. If a file is now indexed by Nepomuk it will show different metadata in the Information Panel than if the file was not indexed, and the user selected the file. Current bugs visible via the KFileMetadataWidget - * https://bugs.kde.org/show_bug.cgi?id=257438 (crash) * https://bugs.kde.org/show_bug.cgi?id=270739 (crash) * https://bugs.kde.org/show_bug.cgi?id=270739 (crash) * https://bugs.kde.org/show_bug.cgi?id=281342 (crash) * https://bugs.kde.org/show_bug.cgi?id=160157 * https://bugs.kde.org/show_bug.cgi?id=285039 * https://bugs.kde.org/show_bug.cgi?id=311796 * https://bugs.kde.org/show_bug.cgi?id=303875 * https://bugs.kde.org/show_bug.cgi?id=311201 Some of these bugs are already fixed in nepomuk-core. Other bugs can easily be fixed in nepomuk-core and be properly tested. They cannot be properly tested in kdelibs/nepomuk. The code base is too different now, and it would require too much effort. > > Best regards > Frank > _______________________________________________ > Nepomuk mailing list > Nepomuk@kde.org > https://mail.kde.org/mailman/listinfo/nepomuk > -- Vishesh Handa --e89a8fb206a8f464a404d186a2c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Dec 23, 2012 at 8:01 PM, Frank Reininghaus <frank78= ac@googlemail.com> wrote:
I agree with Sebastian - = the freezes are there for a reason. I
appreciate all offers to help with testing in the remaining time until
the 4.10.0 release, but if that was really enough to make sure that
there are no regressions, then we could just drop the betas and
release a single RC in the future.

That'= ;s making a very generalized statement, and ignoring the current situation.= Please look at how much the code has changed from the 4.9. I'm not adv= ocating shipping something written from scratch this late into the schedule= .
=A0
However, pa= st experience shows that
the user feedback that we get for the 4 unstable releases before each
4.x.0 release helps to find many annoying bugs, but is still not
enough to prevent that a few regressions make it into 4.x.0. Yes, we
do have 4.x.1 and further bug fix releases, but in the end, users just
don't like it when there are new bugs in 4.x.0, and I perfectly
understand that.

Users always dislike bugs.= We all understand that.
=A0
The angry bug reports would end up in my inbox, and
the reporters would even be right because I would be responsible for
any problems if I approved the use of code that has not seen any wide
testing before RC 2.

That's for the= general case.

You have to look at exactly what I'm p= roposing and how much the code has changed. The answer is not much.

I understand that almost all code have bugs, but you should = at least look at the uses cases of this widget, and if my patch satisfies a= ll of the use cases you can think of.


Therefore, I think that using the new widget in Dolphin should not
happen before KDE 4.11. Users who really want to use it earlier can
just build Dolphin from source and apply the patch (which is not that
hard even if you do not use a source-based distro, just install the
kdelibs headers and then perform a few simple steps).
=
This rules out about 99% of the users.

I also thought again about Vishesh's argument that he would "have = to
spend 2-3 days (maybe even more?)" if we do not use the new widget in<= br> KDE 4.10, and I must say that I do not understand this at all. How can
can using the old widget in KDE 4.10 make the user experience worse
than in KDE 4.9 if he does not spend 2-3 days hacking on the old code?
<= /blockquote>

You loose consistency. If a file is now ind= exed by Nepomuk it will show different metadata in the Information Panel th= an if the file was not indexed, and the user selected the file.

Some of these bugs are already fixed in nepomuk-core. Other = bugs can easily be fixed in nepomuk-core and be properly tested. They canno= t be properly tested in kdelibs/nepomuk. The code base is too different now= , and it would require too much effort.
=A0

Best regards
Frank
_______________________________________________
Nepomuk mailing list
Nepomuk@kde.org https://mail.kde.org/mailman/listinfo/nepomuk



--
Vishesh Handa
--e89a8fb206a8f464a404d186a2c8-- --===============2730881600902509800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team --===============2730881600902509800==--