[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-release-team
Subject: Re: Exception for Dolphin - KFileMetadataWidget
From: Vishesh Handa <me () vhanda ! in>
Date: 2013-01-08 7:30:13
Message-ID: CAOPTMKByXkuf=BYXsJ_G+JjhWbutPwZLPPz=_Kwxf9aSqz1hiA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, Jan 6, 2013 at 10:08 PM, Frank Reininghaus <frank78ac@googlemail.com
> wrote:
>
> What I found hackish was to make Nepomuk2::FileMetaDataWidget a
> typedef for the old widget from kdelibs. One can probably achieve this
> in a cleaner way using #ifdef HAVE_NEPOMUK.
>
> Your patch will certainly be welcome :-)
>
Submitted - https://git.reviewboard.kde.org/r/108236/
> >> Yes, it's a hack, but it could be made
> >> slightly less hackish and include the case that nepomuk-core is there,
> >> but nepomuk-widgets isn't, and then everything would at least build.
> >
> >
> > nepomuk-widget and nepomuk-core are both a part of KDE SC 4.10, so I
> don't
> > think there should be a problem of only one of them existing. Even PIM
> > depends on nepomuk-widgets.
>
> OK, but then the build system should set HAVE_NEPOMUK only if core AND
> widgets are found.
>
Done
>
> >> The alternative would be to make both nepomuk-core AND nepomuk-widgets
> >> hard dependencies for Dolphin. In the long term, this might even be
> >> something to think about because we could then also remove all the
> >> HAVE_NEPOMUKs from the source (even though the feedback that I got
> >> shows that some users like to build Dolphin without Nepomuk, possibly
> >> because they are not using a full KDE desktop and don't want to pull
> >> in too many dependencies), but adding new hard dependencies this late
> >> in the release process is wrong IMHO.
> >
> >
> > Of course.
> >
> >>
> >> The third option (revert the patch) is something that even I am not in
> >> favour of at this point, now that the release delay for the new widget
> >> has been announced to the public.
> >>
> >> Now people will probably ask why I did not notice this problem before.
> >> Simple answer: I hadn't looked at the patch at all. I was quite busy
> >> around Christmas and New Year, mostly with real life issues, and saw
> >> no point in reviewing something that I did not want in KDE 4.10 at
> >> all, and when the extra RC was announced, I only had a 4" screen,
> >> which is not exactly suitable for looking at code, and little
> >> motivation to spend my holiday working on this, because I was quite
> >> frustrated by how the discussion went.
> >>
> >> And to answer the next question: no, I never said that Vishesh should
> >> ask the release-team about including this in KDE 4.10. Even though
> >> Vishesh seems to have misunderstood me, my earlier messages
> >>
> >> http://lists.kde.org/?l=kfm-devel&m=135601666623890&w=2
> >> http://lists.kde.org/?l=kfm-devel&m=135601860424533&w=2
> >>
> >> only mention the release team in response to the statements "At the
> >> end, it's your call" and "Anyway, it's your choice". What I meant was
> >> that even if I agreed (and I listed enough good reasons for not
> >> agreeing IMHO), the change still couldn't go in unless the release
> >> team agreed as well.
> >>
> >> So I was quite surprised by Vishesh's request here, but I still tried
> >> to write a polite answer that shows appreciation for the work of
> >> others, because that's how I like to communicate (even though I now
> >> see that simply saying "no" might have been better):
> >>
> >> http://mail.kde.org/pipermail/release-team/2012-December/006624.html
> >>
> >> But at least my later message was clear, I think:
> >>
> >> http://mail.kde.org/pipermail/release-team/2012-December/006630.html
> >>
> >
> > Perhaps I've been a little short sighted over here.
> >
> > I really wanted to get the widget in cause of its very obvious benefits
> > which I've mentioned earlier. Maybe cause of that I overlooked your firm
> > "no" as a "no - cause you're too late and we have rules". I thought that
> if
> > the rules were the only reason, an exception granted by the release team
> > would be alright.
> >
> > Even in the later email - I mostly focused on how you felt that it
> wouldn't
> > get tested enough. The email mentioned how there would be excessive bug
> > reports and angry emails from users. I thought that the additional RC and
> > increased awareness addressed those concerns.
> >
> > I didn't think that you would still disagree after the issues raised had
> > been addressed. I was obviously wrong.
> >
> > If possible, I would like to know why you still felt that this shouldn't
> > have gone in? Is it just cause of the lack of testing?
>
> I see that the new widget has lots of benefits. But every new feature
> has benefits, or it wouldn't be worth calling it a feature. OTOH,
> every new feature might bring serious new bugs, which is why there is
> the betas and RCs for testing. Now if the procedure is changed, I
> think there should be good reasons why the "usefulness of the new
> feature" vs "risk of new bugs" ratio can be expected to be extremely
> good.
>
> I know that you put a lot of work into the new widget. You deserve to
> be proud of it, and I understand that you wanted to ship it to users
> ASAP. But I might be biased a bit to the other sider because I still
> remember the times when we got a couple of Dolphin crash reports a day
> which were due to Nepomuk (no, not all of them were DBus' fault).
> Based on these experiences and the fact that Nepomuk is certainly a
> very useful, but also a quite complex piece of software, I might tend
> to be a bit careful about using new Nepomuk code that hasn't seen wide
> testing yet so late in the release cycle.
>
> But now it's clear that the change will be in KDE 4.10, so let's try
> to make it work as good as we can.
>
Thanks
>
> >> Please note that I'm not blaming anyone for anything here, I'm just
> >> trying to answer the obvious question "why did the maintainer not
> >> notice this before?" in advance.
> >>
> >> I'm sorry if this message is considered offensive, but I'm seriously
> >> fed up with the way Nepomuk repeatedly broke things in the last years
> >> and caused extra work for everyone.
> >
> > Last years?
>
> I was thinking of issues like the introduction of SDO as a hard
> dependency without any prior announcement, which caused lots of pain
> for everyone building KDE from source:
>
> http://thread.gmane.org/gmane.comp.kde.cvs/845288/focus=62296
>
>
Interesting. I didn't know about this. I started contributing to Nepomuk
sometime in early 2010. Though since then we have had another SDO related
goof-up.
> There were more occasions where Nepomuk-related things caused trouble
> for other developers and/or packagers, one could certainly find out by
> digging in the mailing list archives. I'll do that if there is some
> interest.
>
> These issues were not your fault, of course, but when things like
> these happen, people who are not involved with Nepomuk might start to
> wonder if enough attention is given to the possible consequences that
> any changes in and around Nepomuk will have for developers of other
> parts of KDE, packagers, and users.
>
I understand.
For this particular release I've tried to focus less on - "This is
technologically superior" and just improve the "user experience". I hope it
turns out okay.
>
> >> I'm still willing to collaborate
> >> constructively with Nepomuk and Vishesh in particular, but IMHO, the
> >> way Nepomuk interacts with the rest of the KDE community has to
> >> change.
> >
> >
> > Please note that I've only recently (last 6 months) taken up
> maintainer-ship
> > of Nepomuk. I thought I was doing a decent job - maybe I've only been
> > focusing on the technical aspects. It would be nice if someone could
> gently
> > prod me in the right direction.
>
> I think that you are doing a good job!
>
Thank you.
>
> > For one - I will try to abide by the higher quality standards and get
> > everything in well before the release date.
>
> Perfect!
>
> > This entire process of getting
> > in the new widget has been fairly eventful, and while it might be an
> > improvement for the users, it has caused a lot of strife between the
> > developers.
>
> Yes, but for me the issue is resolved now (except for the build
> system), so I'm looking forward to a fruitful collaboration in the
> future.
>
Great. Cause we have lots to do.
--
Vishesh Handa
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, \
Jan 6, 2013 at 10:08 PM, Frank Reininghaus <span dir="ltr"><<a \
href="mailto:frank78ac@googlemail.com" \
target="_blank">frank78ac@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><br>What I found hackish was to make \
Nepomuk2::FileMetaDataWidget a<br> typedef for the old widget from kdelibs. One can \
probably achieve this<br> in a cleaner way using #ifdef HAVE_NEPOMUK.<br>
<br>
Your patch will certainly be welcome \
:-)<br></blockquote><div><br></div><div>Submitted - <a \
href="https://git.reviewboard.kde.org/r/108236/" \
target="_blank">https://git.reviewboard.kde.org/r/108236/</a><br> \
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>>> Yes, it's a hack, but it could be made<br>
>> slightly less hackish and include the case that nepomuk-core is there,<br>
>> but nepomuk-widgets isn't, and then everything would at least build.<br>
><br>
><br>
> nepomuk-widget and nepomuk-core are both a part of KDE SC 4.10, so I \
don't<br> > think there should be a problem of only one of them existing. Even \
PIM<br> > depends on nepomuk-widgets.<br>
<br>
</div>OK, but then the build system should set HAVE_NEPOMUK only if core AND<br>
widgets are found.<br></blockquote><div><br></div><div>Done<br> <br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div><div><br>
>> The alternative would be to make both nepomuk-core AND nepomuk-widgets<br>
>> hard dependencies for Dolphin. In the long term, this might even be<br>
>> something to think about because we could then also remove all the<br>
>> HAVE_NEPOMUKs from the source (even though the feedback that I got<br>
>> shows that some users like to build Dolphin without Nepomuk, possibly<br>
>> because they are not using a full KDE desktop and don't want to pull<br>
>> in too many dependencies), but adding new hard dependencies this late<br>
>> in the release process is wrong IMHO.<br>
><br>
><br>
> Of course.<br>
><br>
>><br>
>> The third option (revert the patch) is something that even I am not in<br>
>> favour of at this point, now that the release delay for the new widget<br>
>> has been announced to the public.<br>
>><br>
>> Now people will probably ask why I did not notice this problem before.<br>
>> Simple answer: I hadn't looked at the patch at all. I was quite busy<br>
>> around Christmas and New Year, mostly with real life issues, and saw<br>
>> no point in reviewing something that I did not want in KDE 4.10 at<br>
>> all, and when the extra RC was announced, I only had a 4" screen,<br>
>> which is not exactly suitable for looking at code, and little<br>
>> motivation to spend my holiday working on this, because I was quite<br>
>> frustrated by how the discussion went.<br>
>><br>
>> And to answer the next question: no, I never said that Vishesh should<br>
>> ask the release-team about including this in KDE 4.10. Even though<br>
>> Vishesh seems to have misunderstood me, my earlier messages<br>
>><br>
>> <a href="http://lists.kde.org/?l=kfm-devel&m=135601666623890&w=2" \
target="_blank">http://lists.kde.org/?l=kfm-devel&m=135601666623890&w=2</a><br>
>> <a href="http://lists.kde.org/?l=kfm-devel&m=135601860424533&w=2" \
target="_blank">http://lists.kde.org/?l=kfm-devel&m=135601860424533&w=2</a><br>
>><br>
>> only mention the release team in response to the statements "At the<br>
>> end, it's your call" and "Anyway, it's your choice". \
What I meant was<br> >> that even if I agreed (and I listed enough good reasons \
for not<br> >> agreeing IMHO), the change still couldn't go in unless the \
release<br> >> team agreed as well.<br>
>><br>
>> So I was quite surprised by Vishesh's request here, but I still \
tried<br> >> to write a polite answer that shows appreciation for the work \
of<br> >> others, because that's how I like to communicate (even though I \
now<br> >> see that simply saying "no" might have been better):<br>
>><br>
>> <a href="http://mail.kde.org/pipermail/release-team/2012-December/006624.html" \
target="_blank">http://mail.kde.org/pipermail/release-team/2012-December/006624.html</a><br>
>><br>
>> But at least my later message was clear, I think:<br>
>><br>
>> <a href="http://mail.kde.org/pipermail/release-team/2012-December/006630.html" \
target="_blank">http://mail.kde.org/pipermail/release-team/2012-December/006630.html</a><br>
>><br>
><br>
> Perhaps I've been a little short sighted over here.<br>
><br>
> I really wanted to get the widget in cause of its very obvious benefits<br>
> which I've mentioned earlier. Maybe cause of that I overlooked your firm<br>
> "no" as a "no - cause you're too late and we have \
rules". I thought that if<br> > the rules were the only reason, an exception \
granted by the release team<br> > would be alright.<br>
><br>
> Even in the later email - I mostly focused on how you felt that it \
wouldn't<br> > get tested enough. The email mentioned how there would be \
excessive bug<br> > reports and angry emails from users. I thought that the \
additional RC and<br> > increased awareness addressed those concerns.<br>
><br>
> I didn't think that you would still disagree after the issues raised had<br>
> been addressed. I was obviously wrong.<br>
><br>
> If possible, I would like to know why you still felt that this shouldn't<br>
> have gone in? Is it just cause of the lack of testing?<br>
<br>
</div></div>I see that the new widget has lots of benefits. But every new feature<br>
has benefits, or it wouldn't be worth calling it a feature. OTOH,<br>
every new feature might bring serious new bugs, which is why there is<br>
the betas and RCs for testing. Now if the procedure is changed, I<br>
think there should be good reasons why the "usefulness of the new<br>
feature" vs "risk of new bugs" ratio can be expected to be \
extremely<br> good.<br>
<br>
I know that you put a lot of work into the new widget. You deserve to<br>
be proud of it, and I understand that you wanted to ship it to users<br>
ASAP. But I might be biased a bit to the other sider because I still<br>
remember the times when we got a couple of Dolphin crash reports a day<br>
which were due to Nepomuk (no, not all of them were DBus' fault).<br>
Based on these experiences and the fact that Nepomuk is certainly a<br>
very useful, but also a quite complex piece of software, I might tend<br>
to be a bit careful about using new Nepomuk code that hasn't seen wide<br>
testing yet so late in the release cycle.<br>
<br>
But now it's clear that the change will be in KDE 4.10, so let's try<br>
to make it work as good as we can.<br></blockquote><div><br></div><div>Thanks<br> \
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><br>
>> Please note that I'm not blaming anyone for anything here, I'm \
just<br> >> trying to answer the obvious question "why did the maintainer \
not<br> >> notice this before?" in advance.<br>
>><br>
>> I'm sorry if this message is considered offensive, but I'm \
seriously<br> >> fed up with the way Nepomuk repeatedly broke things in the \
last years<br> >> and caused extra work for everyone.<br>
><br>
> Last years?<br>
<br>
</div>I was thinking of issues like the introduction of SDO as a hard<br>
dependency without any prior announcement, which caused lots of pain<br>
for everyone building KDE from source:<br>
<br>
<a href="http://thread.gmane.org/gmane.comp.kde.cvs/845288/focus=62296" \
target="_blank">http://thread.gmane.org/gmane.comp.kde.cvs/845288/focus=62296</a><br> \
<br></blockquote><div><br></div><div>Interesting. I didn't know about this. I \
started contributing to Nepomuk sometime in early 2010. Though since then we have had \
another SDO related goof-up.<br> <br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">
There were more occasions where Nepomuk-related things caused trouble<br>
for other developers and/or packagers, one could certainly find out by<br>
digging in the mailing list archives. I'll do that if there is some<br>
interest.<br>
<br>
These issues were not your fault, of course, but when things like<br>
these happen, people who are not involved with Nepomuk might start to<br>
wonder if enough attention is given to the possible consequences that<br>
any changes in and around Nepomuk will have for developers of other<br>
parts of KDE, packagers, and users.<br></blockquote><div><br></div><div>I \
understand.<br><br></div><div>For this particular release I've tried to focus \
less on - "This is technologically superior" and just improve the \
"user experience". I hope it turns out okay.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><br>
>> I'm still willing to collaborate<br>
>> constructively with Nepomuk and Vishesh in particular, but IMHO, the<br>
>> way Nepomuk interacts with the rest of the KDE community has to<br>
>> change.<br>
><br>
><br>
> Please note that I've only recently (last 6 months) taken up \
maintainer-ship<br> > of Nepomuk. I thought I was doing a decent job - maybe \
I've only been<br> > focusing on the technical aspects. It would be nice if \
someone could gently<br> > prod me in the right direction.<br>
<br>
</div>I think that you are doing a good \
job!<br></blockquote><div><br></div><div>Thank you.<br> <br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">
<div><br>
> For one - I will try to abide by the higher quality standards and get<br>
> everything in well before the release date.<br>
<br>
</div>Perfect!<br>
<div><br>
> This entire process of getting<br>
> in the new widget has been fairly eventful, and while it might be an<br>
> improvement for the users, it has caused a lot of strife between the<br>
> developers.<br>
<br>
</div>Yes, but for me the issue is resolved now (except for the build<br>
system), so I'm looking forward to a fruitful collaboration in the<br>
future.<br></blockquote><div><br></div><div>Great. Cause we have lots to \
do.</div></div><br><br>-- <br><span style="color:rgb(192,192,192)">Vishesh \
Handa</span><br> </div></div>
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic