--===============1911395181==
Content-Type: multipart/alternative;
boundary="Boundary-01=_HExmMP8fpANSayI"
Content-Transfer-Encoding: 7bit
--Boundary-01=_HExmMP8fpANSayI
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Recently the Nokia testers have started to report bugs against the Essen
branch. This is part of the Nokia effort to open up the development process
and put it more into the open, something I think we should be grateful for.
However, this hasn't been well received everywhere. Thomas has moved the
resolution of these bugs to WAIT [1] and asking that the testing be done
against trunk instead. He writes:
"Please test against the main branch and not an unstable
feature branch thats not supported by the KOffice core team.
Feel free to reopen if the bug exists in the main branch. "
I can see his point, but I thought that I would ask the rest of the community
about this. Here are the facts:
- Nokia is going to test the Essen branch since that is what is being used
for their releases. Once trunk is open for features again, this will move back
to trunk.
- Most bugs exist in both the branch and trunk. Some (a few?) bugs only exist
in branch, of course.
So, I can see these alternatives:
1. Nokia is allowed to report bugs against the branch.
2. Nokia is not allowed to report bugs and will move back to the internal
Maemo.org bugzilla.
In case 1, there will be a few bugs that cannot be reproduced in trunk. That
is a cost, but in my mind not very high. In return we will get a lot of bugs
reported that would otherwise go unnoticed by us.
In case 2, we will save some work (won't have to check the bugs against trunk)
but we miss out on a lot of bugs. It will also mean a setback to the opening
up process.
So, what do you think? My own opinion is that alternative 1 is better and that
it's not very difficult to ignore the bugs that are against the branch if you
don't like them. After the freeze is lifted, they will be moved to trunk
anyway, or closed if the bug in question doesn't exist any more.
-Inge
[1]
https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&resolution=WAITINGFORINFO&emailassigned_to1=1&emailreporter1=1&emailtype1=exact&email1=swathi.vegesna@wipro.com&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+so
--Boundary-01=_HExmMP8fpANSayI
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Recently th=
e Nokia testers have started to report bugs against the Essen branch. This=
is part of the Nokia effort to open up the development process and put it =
more into the open, something I think we should be grateful for.
However, th=
is hasn't been well received everywhere. Thomas has moved the resolution o=
f these bugs to WAIT [1] and asking that the testing be done against trunk =
instead. He writes:
&qu=
ot;Please test a=
gainst the main branch and not an unstable
feature branch thats not supported=
by the KOffice core team.
Feel free to reopen if the bug exi=
sts in the main branch. "
I can see h=
is point, but I thought that I would ask the rest of the community about th=
is. Here are the facts:
- Nokia is=
going to test the Essen branch since that is what is being used for their =
releases. Once trunk is open for features again, this will move back to tru=
nk.
- Most bug=
s exist in both the branch and trunk. Some (a few?) bugs only exist in bran=
ch, of course.
So, I can s=
ee these alternatives:
1. Nokia is=
allowed to report bugs against the branch.
2. Nokia is=
not allowed to report bugs and will move back to the internal Maemo.org bu=
gzilla.
In case 1, =
there will be a few bugs that cannot be reproduced in trunk. That is a cos=
t, but in my mind not very high. In return we will get a lot of bugs repor=
ted that would otherwise go unnoticed by us.
In case 2, =
we will save some work (won't have to check the bugs against trunk) but we =
miss out on a lot of bugs. It will also mean a setback to the opening up pr=
ocess.
So, what do=
you think? My own opinion is that alternative 1 is better and that it's no=
t very difficult to ignore the bugs that are against the branch if you don'=
t like them. After the freeze is lifted, they will be moved to trunk anywa=
y, or closed if the bug in question doesn't exist any more.
-Inge
[1] =
https://bugs.kde.org/buglist.cgi?query_format=3Dadvanced&short_desc_typ=
e=3Dallwordssubstr&short_desc=3D&long_desc_type=3Dallwordssubstr&am=
p;long_desc=3D&bug_file_loc_type=3Dallwordssubstr&bug_file_loc=3D&a=
mp;keywords_type=3Dallwords&keywords=3D&resolution=3DWAITINGFORINFO=
&emailassigned_to1=3D1&emailreporter1=3D1&emailtype1=3Dexact&am=
p;email1=3Dswathi.vegesna@wipro.com&emailtype2=3Dsubstring&email2=
=3D&bugidtype=3Dinclude&bug_id=3D&votes=3D&chfieldfrom=3D&a=
mp;chfieldto=3DNow&chfieldvalue=3D&cmdtype=3Ddoit&order=3DReuse=
+same+so
--Boundary-01=_HExmMP8fpANSayI--
--===============1911395181==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
--===============1911395181==--