kde3 to 4 bugs transition policy?

[Yuriy Kozlov]

On Sun, Jan 13, 2008 at 2:15 PM, Yuriy Kozlov <yuriy-kozlov at kubuntu.org> wrote:
> Hello, happy 4.0!
>
> With KDE 4.0 out and many people's focus for hardy, I was wondering
> what the plan was for all the KDE 3.5 bugs in launchpad.  There are
> about 1900 of them open[1], and it's now increasingly likely that many
> will never get fixed in 3.5 or even looked at.  Many bugs are likely
> already fixed in KDE 4.0, and others will be fixed there and not in
> 3.5.
>
> Maybe it's time to start transitioning the bugs over to the KDE 4
> packages?  Meaning close bugs if they are fixed in 4.0, and change the
> source package to the kde4 one if it's not essential and reasonable to
> fix the bug in 3.5 for hardy.
>
> I propose to start by doing this for the wishlist and low importance
> bugs.  This is currently about 100 bugs for e.g. kdebase[2].
> Thoughts?
>
>
> [1] https://launchpad.net/~kubuntu-team/+packagebugs
> [2] https://launchpad.net/~kubuntu-team/+packagebugs-search?field.distribution=ubuntu&field.sourcepackagename=kdebase&field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.importance%3Alist=LOW&field.importance%3Alist=WISHLIST&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_contact=&field.bug_commenter=&field.subscriber=&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.tag=&field.has_cve.used=
>

Now that we have specs for Intrepid, namely replacing KDE 3 packages
with KDE 4 versions, I'd like to revisit this.  Basically, I think,
the normal policy should be followed: Either the bug qualifies for
SRU[1], or if it's fixed in the development version, that means it's
fixed since the fix is never going to get to the stable version.  In
this case, if a bug is fixed in KDE 4.1, and does not qualify for a
SRU to Hardy/KDE 3.5, then it's considered fixed.

So, the triage procedure for open (including Confirmed!) bugs in KDE
(not *-kde4) packages would be the following:
1. Test on Hardy/KDE3.  If it's not present, then mark it fixed or
invalid, as appropriate.
If you can confirm it on Hardy/KDE3:
 a. If it qualifies for SRU according to [1], mark it Confirmed and
tag it as kubuntu-needs-sru (?).  If all other needed information is
there, mark it Triaged.  In most cases, the importance should be set
to High, since if it wasn't important it probably doesn't qualify for
SRU either.
 b. If it doesn't, go on to step 2.
2 (optional). Test on Hardy/KDE4 with backports.  If it's not present,
then mark it fixed.  If not, go on to step 3.
3. Test on Hardy with KDE 4.1 daily build OR (preferably) on Intrepid.
 If it's not present mark it fixed.  If it's still there, and all
needed information is there, mark it Triaged.  As usual, for
application feature requests, and most non-packaging bugs, look for
and/or file the bug upstream at bugs.kde.org and add a bug watch.

For *-kde4 packages in Hardy:
1. Test on Hardy/KDE4.  If it's not present, then mark it fixed or
invalid, as appropriate.
If you can confirm it on Hardy/KDE4:
 a. If it qualifies for SRU according to [1], mark it Confirmed and
tag it as kubuntu-needs-sru (?).  If all other needed information is
there, mark it Triaged.  In most cases, the importance should be set
to High, since if it wasn't important it probably doesn't qualify for
SRU either.
 b. If it doesn't, go on to step 2.
2. Test on Hardy with KDE 4.1 daily build OR (preferably) on Intrepid.
 If it's not present mark it fixed.  If it's still there, and all
needed information is there, mark it Triaged and change the package to
the one without the -kde4 suffix.  As usual, for application feature
requests, and most non-packaging bugs, look for and/or file the bug
upstream at bugs.kde.org and add a bug watch.

[1] https://wiki.kubuntu.org/StableReleaseUpdates

Thoughts?
~ Yuriy