On the problem of Nokia bugs substituting changelogs
On the problem of Nokia bugs substituting changelogs
Re: On the problem of Nokia bugs substituting changelogs
2008-08-24 19:02 UTC
On Sun, 2008-08-24 at 14:15 -0400, ext Ryan Abel wrote:
> While this is great for Nokia employees and contractors, this
> is not an OK thing to hoist upon the community.
Even for internals it's not so nice to constantly refer to bugzilla and
certainly very few bugs are known by heart by developers - and even then
not _that_many_ developers.
--
Cheers, Igor
---
Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki
> While this is great for Nokia employees and contractors, this
> is not an OK thing to hoist upon the community.
Even for internals it's not so nice to constantly refer to bugzilla and
certainly very few bugs are known by heart by developers - and even then
not _that_many_ developers.
--
Cheers, Igor
---
Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki
Re: On the problem of Nokia bugs substituting changelogs
2008-08-25 07:42 UTC
Hi,
ext Ryan Abel wrote:
> itT user free was kind enough to compile what basically amounts to a
> changelog for 4.2008.30-2[1] (something Nokia has been promising to
> do for 2 years now with zero results).
I remember the discussion, but I think the promise was more about it
being possible to be able to get a changelog of the changes relevant
to the community by linking the public bugzilla (alias field) contents
to the internal bug numbers in the packages changelog.
> What I've noticed about these
> changelogs is that many of them mention Nokia bug numbers in lieu of
> actually providing real information on changes. Though typical of
> Nokia, this is _NOT_ acceptable. This practice limits deciphering of
> these changelogs to people who have access to Nokia's internal
> tracker. While this is great for Nokia employees and contractors, this
> is not an OK thing to hoist upon the community.
While this would be nice (and is up to each specific project), I'm not
sure how much of a problem it really is when the public bug / internal
bug linking works. Most of the internal bugs aren't really relevant
to the users as they are issues that haven't been in any of the public
releases (most are for internal changes (feature development) and all
significant bugs that have been found internally are naturally fixed
before public release).
As to linking internal and external bugs, I think more interesting
would be how many of the public bugs (which aren't enhancements
or unconfirmed) don't have a corresponding internal bug alias...
- Eero
ext Ryan Abel wrote:
> itT user free was kind enough to compile what basically amounts to a
> changelog for 4.2008.30-2[1] (something Nokia has been promising to
> do for 2 years now with zero results).
I remember the discussion, but I think the promise was more about it
being possible to be able to get a changelog of the changes relevant
to the community by linking the public bugzilla (alias field) contents
to the internal bug numbers in the packages changelog.
> What I've noticed about these
> changelogs is that many of them mention Nokia bug numbers in lieu of
> actually providing real information on changes. Though typical of
> Nokia, this is _NOT_ acceptable. This practice limits deciphering of
> these changelogs to people who have access to Nokia's internal
> tracker. While this is great for Nokia employees and contractors, this
> is not an OK thing to hoist upon the community.
While this would be nice (and is up to each specific project), I'm not
sure how much of a problem it really is when the public bug / internal
bug linking works. Most of the internal bugs aren't really relevant
to the users as they are issues that haven't been in any of the public
releases (most are for internal changes (feature development) and all
significant bugs that have been found internally are naturally fixed
before public release).
As to linking internal and external bugs, I think more interesting
would be how many of the public bugs (which aren't enhancements
or unconfirmed) don't have a corresponding internal bug alias...
- Eero
Re: On the problem of Nokia bugs substituting changelogs
2008-09-02 10:05 UTC
ext Ryan Abel wrote:
> itT user free was kind enough to compile what basically amounts to a
> changelog for 4.2008.30-2[1]
Thanks for the script.
> (something Nokia has been promising to do
> for 2 years now with zero results).
(humble acceptance)
> What I've noticed about these
> changelogs is that many of them mention Nokia bug numbers in lieu of
> actually providing real information on changes. Though typical of
> Nokia, this is _NOT_ acceptable. This practice limits deciphering of
> these changelogs to people who have access to Nokia's internal
> tracker. While this is great for Nokia employees and contractors, this
> is not an OK thing to hoist upon the community.
Yes, you have a point. Internal bug numbers without description are
pretty useless (even for internal use, as Igor points out). Probably
what needs to be done though is what Marius recommends: use the news
file in the deb package to describe what is really new and interesting
for someone else out of the internal development process.
> Now, there are a few projects that aren't so bad
Let's list them and help getting the excellence they pursue.
> but there are others that are about as bad as they could get.
Let's list them too, and we will show them the previous list for
reference on how a Nokia team can do things right.
> I was considering how I might go about filing a bug in Bugzilla about
> this, but the problem is too widespread and I don't feel like filling
> a bug for each individual project that allows this practice
Agreed.
> (they'll
> just be ignored anyway https://bugs.maemo.org/show_bug.cgi?id=3442
> :\)
An additional problem here is that AGPS is not part of the Maemo release
but a component developed by another team with its own feedback channel:
http://betalabs.nokia.com/blog/tag/agps-tablet/
> and a wiki page about it wont accomplish anything.
I disagree. Documenting what is good and what is wrong in a wiki page,
fine tune the message, add links, summarize discussions... makes easier
to push proposals internally referring to a single URL.
> So I'm
> appealing to this list and any Nokia developers on it responsible for
> creating changelogs, or who have any influence over their creation.
What is true is that this is one of those things where developers and
project managers can improve as much as they want without depending on
Nokia processes and whatnot. I have forwarded your email internally for
wider distribution.
> Please, try not to exclude the community even more from Nokia's
> development process, and please stop degrading Nokia's image in the
> community. It's bad enough as-is.
Ouch.
> Now, I realize some things are confidential, and can't be mentioned in
> public changelogs, but this exception doesn't apply to open source
> packages. At the very least, you could at least provide a bug summary
> to go with the bug number (this can be scripted, so "too much work"
> isn't a valid excuse),
In a worst case, every bug number has a corresponding bug subject easy
to copy&paste.
> or go the extra mile and provide real
> changelogs (perhaps with maemo.org bugzilla bug numbers when
> relevant?).
This is what probably could be handled better in the news file.
> I thank you for your time and consideration. Remember: the community
> wants to help, and excluding it is bad for you and bad for Nokia. :)
Yes, the theory is clear. Thanks for your patience.
> [1]http://p.quinput.eu/debfarm/changelog.html
> [2]Actually, let me take this opportunity to CALL OUT the Modest
> developers for very poor communication with the community for a
> supposedly "open source" project. Their component on Bugzilla seems to
> be virtually barren of real Modest-developer participation, and one
> only seems to be able to elicit a response from any of them when
> they're practically cornered on significant bugs. This is very
> unfortunate for what I hope will become a very cool, lightweight, and
> open source email client. . . . :(
An explanation here could be a coincidence of factors: Dirk was the
project manager and was quite open about the development, blogging and
stuff - but he changed his role at Nokia and now is elsewhere. Most of
the core development was/is done out of Nokia. Philip can answer for any
tinymail related stuff since he is public upstream but the Modest
implementation is upstream itself and open source, but developed through
traditional contractual relations.
Another lesson to learn here. If any Modest developer (or any Nokia
subcontractor) reading this has ideas for improvement please let us/me
know. Thanks again.
--
Quim Gil
marketing manager, open source
Maemo Software @ Nokia
> itT user free was kind enough to compile what basically amounts to a
> changelog for 4.2008.30-2[1]
Thanks for the script.
> (something Nokia has been promising to do
> for 2 years now with zero results).
(humble acceptance)
> What I've noticed about these
> changelogs is that many of them mention Nokia bug numbers in lieu of
> actually providing real information on changes. Though typical of
> Nokia, this is _NOT_ acceptable. This practice limits deciphering of
> these changelogs to people who have access to Nokia's internal
> tracker. While this is great for Nokia employees and contractors, this
> is not an OK thing to hoist upon the community.
Yes, you have a point. Internal bug numbers without description are
pretty useless (even for internal use, as Igor points out). Probably
what needs to be done though is what Marius recommends: use the news
file in the deb package to describe what is really new and interesting
for someone else out of the internal development process.
> Now, there are a few projects that aren't so bad
Let's list them and help getting the excellence they pursue.
> but there are others that are about as bad as they could get.
Let's list them too, and we will show them the previous list for
reference on how a Nokia team can do things right.
> I was considering how I might go about filing a bug in Bugzilla about
> this, but the problem is too widespread and I don't feel like filling
> a bug for each individual project that allows this practice
Agreed.
> (they'll
> just be ignored anyway https://bugs.maemo.org/show_bug.cgi?id=3442
> :\)
An additional problem here is that AGPS is not part of the Maemo release
but a component developed by another team with its own feedback channel:
http://betalabs.nokia.com/blog/tag/agps-tablet/
> and a wiki page about it wont accomplish anything.
I disagree. Documenting what is good and what is wrong in a wiki page,
fine tune the message, add links, summarize discussions... makes easier
to push proposals internally referring to a single URL.
> So I'm
> appealing to this list and any Nokia developers on it responsible for
> creating changelogs, or who have any influence over their creation.
What is true is that this is one of those things where developers and
project managers can improve as much as they want without depending on
Nokia processes and whatnot. I have forwarded your email internally for
wider distribution.
> Please, try not to exclude the community even more from Nokia's
> development process, and please stop degrading Nokia's image in the
> community. It's bad enough as-is.
Ouch.
> Now, I realize some things are confidential, and can't be mentioned in
> public changelogs, but this exception doesn't apply to open source
> packages. At the very least, you could at least provide a bug summary
> to go with the bug number (this can be scripted, so "too much work"
> isn't a valid excuse),
In a worst case, every bug number has a corresponding bug subject easy
to copy&paste.
> or go the extra mile and provide real
> changelogs (perhaps with maemo.org bugzilla bug numbers when
> relevant?).
This is what probably could be handled better in the news file.
> I thank you for your time and consideration. Remember: the community
> wants to help, and excluding it is bad for you and bad for Nokia. :)
Yes, the theory is clear. Thanks for your patience.
> [1]http://p.quinput.eu/debfarm/changelog.html
> [2]Actually, let me take this opportunity to CALL OUT the Modest
> developers for very poor communication with the community for a
> supposedly "open source" project. Their component on Bugzilla seems to
> be virtually barren of real Modest-developer participation, and one
> only seems to be able to elicit a response from any of them when
> they're practically cornered on significant bugs. This is very
> unfortunate for what I hope will become a very cool, lightweight, and
> open source email client. . . . :(
An explanation here could be a coincidence of factors: Dirk was the
project manager and was quite open about the development, blogging and
stuff - but he changed his role at Nokia and now is elsewhere. Most of
the core development was/is done out of Nokia. Philip can answer for any
tinymail related stuff since he is public upstream but the Modest
implementation is upstream itself and open source, but developed through
traditional contractual relations.
Another lesson to learn here. If any Modest developer (or any Nokia
subcontractor) reading this has ideas for improvement please let us/me
know. Thanks again.
--
Quim Gil
marketing manager, open source
Maemo Software @ Nokia
RE: On the problem of Nokia bugs substituting changelogs
2008-09-02 12:25 UTC
Hi Ryan,
> -----Original Message-----
> From: maemo-developers-bounces@maemo.org
> [mailto:maemo-developers-bounces@maemo.org] On Behalf Of ext Quim Gil
> ext Ryan Abel wrote:
> > itT user free was kind enough to compile what basically amounts to a
> > changelog for 4.2008.30-2[1]
> > [2]Actually, let me take this opportunity to CALL OUT the Modest
> > developers for very poor communication with the community for a
> > supposedly "open source" project. Their component on
> Bugzilla seems to
> > be virtually barren of real Modest-developer participation, and one
> > only seems to be able to elicit a response from any of them when
> > they're practically cornered on significant bugs. This is very
> > unfortunate for what I hope will become a very cool,
> lightweight, and
> > open source email client. . . . :(
>
> An explanation here could be a coincidence of factors: Dirk was the
> project manager and was quite open about the development, blogging and
> stuff - but he changed his role at Nokia and now is elsewhere. Most of
> the core development was/is done out of Nokia. Philip can
> answer for any
> tinymail related stuff since he is public upstream but the Modest
> implementation is upstream itself and open source, but
> developed through
> traditional contractual relations.
>
> Another lesson to learn here. If any Modest developer (or any Nokia
> subcontractor) reading this has ideas for improvement please let us/me
> know. Thanks again.
Thanks Quim -- to add to that; I still keep an eye on Modest
development,
applying the occasional parch (as I did this morning).
Anyhow, regarding Bugzilla - we do look at it, but as Quim explains, it
takes quite some acrobatics to take care of both internal and external
worlds. The Modest development team is very busy with feature
development
and bug fixes, and admittedly, after that there's not soooo much time
left
for interacting with the community. That's a sad fact.
But, in the end, we are really trying to produce the best possible
e-mail
client, no matter what. We really appreciate the feedback through
bugzilla
and elsewhere. And if you have any specific issue, please mail me
directly,
let's see what we can do.
Best wishes,
Dirk.
> -----Original Message-----
> From: maemo-developers-bounces@maemo.org
> [mailto:maemo-developers-bounces@maemo.org] On Behalf Of ext Quim Gil
> ext Ryan Abel wrote:
> > itT user free was kind enough to compile what basically amounts to a
> > changelog for 4.2008.30-2[1]
> > [2]Actually, let me take this opportunity to CALL OUT the Modest
> > developers for very poor communication with the community for a
> > supposedly "open source" project. Their component on
> Bugzilla seems to
> > be virtually barren of real Modest-developer participation, and one
> > only seems to be able to elicit a response from any of them when
> > they're practically cornered on significant bugs. This is very
> > unfortunate for what I hope will become a very cool,
> lightweight, and
> > open source email client. . . . :(
>
> An explanation here could be a coincidence of factors: Dirk was the
> project manager and was quite open about the development, blogging and
> stuff - but he changed his role at Nokia and now is elsewhere. Most of
> the core development was/is done out of Nokia. Philip can
> answer for any
> tinymail related stuff since he is public upstream but the Modest
> implementation is upstream itself and open source, but
> developed through
> traditional contractual relations.
>
> Another lesson to learn here. If any Modest developer (or any Nokia
> subcontractor) reading this has ideas for improvement please let us/me
> know. Thanks again.
Thanks Quim -- to add to that; I still keep an eye on Modest
development,
applying the occasional parch (as I did this morning).
Anyhow, regarding Bugzilla - we do look at it, but as Quim explains, it
takes quite some acrobatics to take care of both internal and external
worlds. The Modest development team is very busy with feature
development
and bug fixes, and admittedly, after that there's not soooo much time
left
for interacting with the community. That's a sad fact.
But, in the end, we are really trying to produce the best possible
client, no matter what. We really appreciate the feedback through
bugzilla
and elsewhere. And if you have any specific issue, please mail me
directly,
let's see what we can do.
Best wishes,
Dirk.
SDK, sources Re: On the problem of Nokia bugs substituting changelogs
2008-09-02 13:25 UTC
Hi Quim,
nice to see you back :-)
Quim Gil wrote:
>> but there are others that are about as bad as they could get.
>
> Let's list them too, and we will show them the previous list for
> reference on how a Nokia team can do things right.
Another bad example here is the kernel, search the
http://p.quinput.eu/debfarm/changelog.html file for 'kernel-diablo'. We
can see only '* Updated kernel version XXX' instead of real info. So
basically we are completely in the dark if new kernel actually fixes
something or not.
This is yet another annoyance to the fact that we still don't have
updated sources in http://repository.maemo.org/pool/diablo/free for
GPLed stuff updated in latest 4.2008.30-2 Diablo update.
This is of course bad for any GPLed package but it causes practical
problems especially for linux kernel source. There are a lot of kernel
hacks in the wild and after each firmware people must choose between
older customized kernel and new (possibly fixed? how can we know?) one.
So will we get updated SDK release with sources for latest Diablo update
(and any further one too)?
Also can this whole firmware and SDK release procedure be changed so
building and releasing sources is integral part of building and
releasing any binary (firmware or SSU) as it is 'suggested' by GPL licence?
We discussed this topic many times here with no visible change so far.
Random pointers to previous discussion:
http://lists.maemo.org/pipermail/maemo-developers/2008-January/031424.html
http://lists.maemo.org/pipermail/maemo-developers/2008-January/031426.html
Frantisek
nice to see you back :-)
Quim Gil wrote:
>> but there are others that are about as bad as they could get.
>
> Let's list them too, and we will show them the previous list for
> reference on how a Nokia team can do things right.
Another bad example here is the kernel, search the
http://p.quinput.eu/debfarm/changelog.html file for 'kernel-diablo'. We
can see only '* Updated kernel version XXX' instead of real info. So
basically we are completely in the dark if new kernel actually fixes
something or not.
This is yet another annoyance to the fact that we still don't have
updated sources in http://repository.maemo.org/pool/diablo/free for
GPLed stuff updated in latest 4.2008.30-2 Diablo update.
This is of course bad for any GPLed package but it causes practical
problems especially for linux kernel source. There are a lot of kernel
hacks in the wild and after each firmware people must choose between
older customized kernel and new (possibly fixed? how can we know?) one.
So will we get updated SDK release with sources for latest Diablo update
(and any further one too)?
Also can this whole firmware and SDK release procedure be changed so
building and releasing sources is integral part of building and
releasing any binary (firmware or SSU) as it is 'suggested' by GPL licence?
We discussed this topic many times here with no visible change so far.
Random pointers to previous discussion:
http://lists.maemo.org/pipermail/maemo-developers/2008-January/031424.html
http://lists.maemo.org/pipermail/maemo-developers/2008-January/031426.html
Frantisek
Re: On the problem of Nokia bugs substituting changelogs
2008-09-02 13:26 UTC
Hi,
I hope this doesn't get taken too badly...
Dirk-Jan.Binnema@nokia.com wrote:
> The Modest development team is very busy with feature
> development
> and bug fixes, and admittedly, after that there's not soooo much time
> left
> for interacting with the community. That's a sad fact.
The problem I have seen in the past is that when developers and project
managers think of "interacting with the community" as a separate task,
it doesn't get done.
Open development is interacting with the community already, surely?
If developers of a free software program are using a public mailing list
to discuss features, a public bugzilla to handle bug reports, and
perhaps an IRC channel or Jabber chat room for real-time interaction,
then interacting with the commuinity is not a task to do, it is a side
effect of product development.
Would it be possible for the Modest team to exclusively use the external
bugzilla, given that it's a free software project?
Cheers,
Dave.
--
maemo.org docsmaster
Email: dneary@maemo.org
Jabber: bolsh@jabber.org
I hope this doesn't get taken too badly...
Dirk-Jan.Binnema@nokia.com wrote:
> The Modest development team is very busy with feature
> development
> and bug fixes, and admittedly, after that there's not soooo much time
> left
> for interacting with the community. That's a sad fact.
The problem I have seen in the past is that when developers and project
managers think of "interacting with the community" as a separate task,
it doesn't get done.
Open development is interacting with the community already, surely?
If developers of a free software program are using a public mailing list
to discuss features, a public bugzilla to handle bug reports, and
perhaps an IRC channel or Jabber chat room for real-time interaction,
then interacting with the commuinity is not a task to do, it is a side
effect of product development.
Would it be possible for the Modest team to exclusively use the external
bugzilla, given that it's a free software project?
Cheers,
Dave.
--
maemo.org docsmaster
Email: dneary@maemo.org
Jabber: bolsh@jabber.org
RE: On the problem of Nokia bugs substituting changelogs
2008-09-02 13:41 UTC
Hi Dave,
> -----Original Message-----
> From: Dave Neary [mailto:nearyd@gmail.com] On Behalf Of ext Dave Neary
> I hope this doesn't get taken too badly...
no worries...
> Dirk-Jan.Binnema@nokia.com wrote:
> > The Modest development team is very busy with feature
> > development
> > and bug fixes, and admittedly, after that there's not soooo
> much time
> > left
> > for interacting with the community. That's a sad fact.
>
> The problem I have seen in the past is that when developers
> and project
> managers think of "interacting with the community" as a separate task,
> it doesn't get done.
>
> Open development is interacting with the community already, surely?
>
> If developers of a free software program are using a public
> mailing list
> to discuss features, a public bugzilla to handle bug reports, and
> perhaps an IRC channel or Jabber chat room for real-time interaction,
> then interacting with the commuinity is not a task to do, it is a side
> effect of product development.
>
> Would it be possible for the Modest team to exclusively use
> the external
> bugzilla, given that it's a free software project?
It would be very nice from the community perspective, very much so,
and of course it would make open development much easier as well.
But, internally, the development process is highly regulated, and tools
like bugzilla play different roles than they do outside -- trust me
on that one. Modest has to satisfy both of its natures, with
the internal one getting the most emphasis, for very pedestrian
reasons...
So, while I agree that it would be nice to have one open bugzilla,
I do not see that happening anytime soon.
Best wishes,
Dirk.
> -----Original Message-----
> From: Dave Neary [mailto:nearyd@gmail.com] On Behalf Of ext Dave Neary
> I hope this doesn't get taken too badly...
no worries...
> Dirk-Jan.Binnema@nokia.com wrote:
> > The Modest development team is very busy with feature
> > development
> > and bug fixes, and admittedly, after that there's not soooo
> much time
> > left
> > for interacting with the community. That's a sad fact.
>
> The problem I have seen in the past is that when developers
> and project
> managers think of "interacting with the community" as a separate task,
> it doesn't get done.
>
> Open development is interacting with the community already, surely?
>
> If developers of a free software program are using a public
> mailing list
> to discuss features, a public bugzilla to handle bug reports, and
> perhaps an IRC channel or Jabber chat room for real-time interaction,
> then interacting with the commuinity is not a task to do, it is a side
> effect of product development.
>
> Would it be possible for the Modest team to exclusively use
> the external
> bugzilla, given that it's a free software project?
It would be very nice from the community perspective, very much so,
and of course it would make open development much easier as well.
But, internally, the development process is highly regulated, and tools
like bugzilla play different roles than they do outside -- trust me
on that one. Modest has to satisfy both of its natures, with
the internal one getting the most emphasis, for very pedestrian
reasons...
So, while I agree that it would be nice to have one open bugzilla,
I do not see that happening anytime soon.
Best wishes,
Dirk.
Re: On the problem of Nokia bugs substituting changelogs
2008-09-02 15:08 UTC
Am Montag, den 25.08.2008, 10:42 +0300 schrieb Eero Tamminen:
> As to linking internal and external bugs, I think more interesting
> would be how many of the public bugs (which aren't enhancements
> or unconfirmed) don't have a corresponding internal bug alias...
the quota for the last month should be around 60%.
I'm currently conservative about transfering maemo.org bug reports to
Nokia's internal bug tracker because it's lots of work to keep them in
sync (been working on some scripts to save me some time, but you cannot
automatize this because of the noise ratio. This is another debate I
won't start in this thread), and I normally wait until maemo.org bug
reports have enough valuable information. Many reports are in moreinfo
state or cannot be reproduced easily, hence the quota will never be
100%.
andre
--
Andre Klapper (maemo.org bugmaster)
> As to linking internal and external bugs, I think more interesting
> would be how many of the public bugs (which aren't enhancements
> or unconfirmed) don't have a corresponding internal bug alias...
the quota for the last month should be around 60%.
I'm currently conservative about transfering maemo.org bug reports to
Nokia's internal bug tracker because it's lots of work to keep them in
sync (been working on some scripts to save me some time, but you cannot
automatize this because of the noise ratio. This is another debate I
won't start in this thread), and I normally wait until maemo.org bug
reports have enough valuable information. Many reports are in moreinfo
state or cannot be reproduced easily, hence the quota will never be
100%.
andre
--
Andre Klapper (maemo.org bugmaster)
RE: On the problem of Nokia bugs substituting changelogs
2008-09-02 15:16 UTC
Am Dienstag, den 02.09.2008, 16:41 +0300 schrieb
Dirk-Jan.Binnema@nokia.com:
> > -----Original Message-----
> > From: Dave Neary [mailto:nearyd@gmail.com] On Behalf Of ext Dave Neary
> > Dirk-Jan.Binnema@nokia.com wrote:
> > Would it be possible for the Modest team to exclusively use
> > the external bugzilla, given that it's a free software project?
>
> It would be very nice from the community perspective, very much so,
> and of course it would make open development much easier as well.
>
> But, internally, the development process is highly regulated, and tools
> like bugzilla play different roles than they do outside -- trust me
> on that one. Modest has to satisfy both of its natures, with
> the internal one getting the most emphasis, for very pedestrian
> reasons...
>
> So, while I agree that it would be nice to have one open bugzilla,
> I do not see that happening anytime soon.
I also do not see this happening very soon, but it is definitely a
long-term target of mine.
Developers want one central place to track software issues.
This currently is Nokia's internal bug tracker, this should become
bugs.maemo.org for Maemo open source projects.
The task is to work out those issues that currently block managing
Modest, MicroB, etc. completely in public and find solutions for each
issue, most probably quite often with the input of lawyers, sigh...
So adopting/using Nokia's current internal processes and workflows in
public (bugs.maemo.org) requires having a policy about those pieces of
information that a commercial company does not want to be accessed by
its competitors, such as policy plans, product and hardware information,
information about the internal testing infrastructure or especially
copyright related issues.
(Half of this email copied from a blog entry I was just writing on.)
andre
--
Andre Klapper (maemo.org bugmaster)
Dirk-Jan.Binnema@nokia.com:
> > -----Original Message-----
> > From: Dave Neary [mailto:nearyd@gmail.com] On Behalf Of ext Dave Neary
> > Dirk-Jan.Binnema@nokia.com wrote:
> > Would it be possible for the Modest team to exclusively use
> > the external bugzilla, given that it's a free software project?
>
> It would be very nice from the community perspective, very much so,
> and of course it would make open development much easier as well.
>
> But, internally, the development process is highly regulated, and tools
> like bugzilla play different roles than they do outside -- trust me
> on that one. Modest has to satisfy both of its natures, with
> the internal one getting the most emphasis, for very pedestrian
> reasons...
>
> So, while I agree that it would be nice to have one open bugzilla,
> I do not see that happening anytime soon.
I also do not see this happening very soon, but it is definitely a
long-term target of mine.
Developers want one central place to track software issues.
This currently is Nokia's internal bug tracker, this should become
bugs.maemo.org for Maemo open source projects.
The task is to work out those issues that currently block managing
Modest, MicroB, etc. completely in public and find solutions for each
issue, most probably quite often with the input of lawyers, sigh...
So adopting/using Nokia's current internal processes and workflows in
public (bugs.maemo.org) requires having a policy about those pieces of
information that a commercial company does not want to be accessed by
its competitors, such as policy plans, product and hardware information,
information about the internal testing infrastructure or especially
copyright related issues.
(Half of this email copied from a blog entry I was just writing on.)
andre
--
Andre Klapper (maemo.org bugmaster)
changelog for 4.2008.30-2[1] (something Nokia has been promising to do
for 2 years now with zero results). What I've noticed about these
changelogs is that many of them mention Nokia bug numbers in lieu of
actually providing real information on changes. Though typical of
Nokia, this is _NOT_ acceptable. This practice limits deciphering of
these changelogs to people who have access to Nokia's internal
tracker. While this is great for Nokia employees and contractors, this
is not an OK thing to hoist upon the community.
Now, there are a few projects that aren't so bad (rtcomm, in
particular, seems consistent about using the Nokia bug #'s more as
backgrounds references rather than substitutions for real changelogs),
but there are others that are about as bad as they could get. Modest,
in fact, seems to ENTIRELY substitute NB#'s for real changelogs[2].
Quoting a recent Modest changelog:
> modest (1.0-2008.26-1) hardy; urgency=low
>
> * Fixes: NB#83920, NB#86372, NB#86116, NB#84538, NB#84757, NB#85343
> * Fixes: NB#85344, NB#85034, NB#83892, NB#84808, NB#84791, NB#82137
> * Fixes: NB#83135, NB#85622, NB#86097, NB#86176, NB#85201, NB#84348
> * Fixes: NB#81798, NB#85873, NB#85743, NB#84605, NB#81429
>
> -- Dirk-Jan C. Binnema <dirk-jan.binnema@nokia.com> Mon, 23 Jun 2008 11:01:57 +0300
I was considering how I might go about filing a bug in Bugzilla about
this, but the problem is too widespread and I don't feel like filling
a bug for each individual project that allows this practice (they'll
just be ignored anyway https://bugs.maemo.org/show_bug.cgi?id=3442
:\), and a wiki page about it wont accomplish anything. So I'm
appealing to this list and any Nokia developers on it responsible for
creating changelogs, or who have any influence over their creation.
Please, try not to exclude the community even more from Nokia's
development process, and please stop degrading Nokia's image in the
community. It's bad enough as-is.
Now, I realize some things are confidential, and can't be mentioned in
public changelogs, but this exception doesn't apply to open source
packages. At the very least, you could at least provide a bug summary
to go with the bug number (this can be scripted, so "too much work"
isn't a valid excuse), or go the extra mile and provide real
changelogs (perhaps with maemo.org bugzilla bug numbers when
relevant?).
I thank you for your time and consideration. Remember: the community
wants to help, and excluding it is bad for you and bad for Nokia. :)
[1]http://p.quinput.eu/debfarm/changelog.html
[2]Actually, let me take this opportunity to CALL OUT the Modest
developers for very poor communication with the community for a
supposedly "open source" project. Their component on Bugzilla seems to
be virtually barren of real Modest-developer participation, and one
only seems to be able to elicit a response from any of them when
they're practically cornered on significant bugs. This is very
unfortunate for what I hope will become a very cool, lightweight, and
open source email client. . . . :(