Eero Tamminen wrote: > It's about the amount of work needed from reducing the "raw" > list of all internal bugfixes which: > - is way too large for anybody to digest as such > - 99% of it would be fixes to bugs that are not present in > _any_ of the public releases > - has items which don't tell anything without the test-case > description (which increase the size significantly) > - might have information that our legal wants to be cleaned out > > To something that is actually: > - relevant (*tested* to happen also in previous public release) > - readable (subjects & test-cases "translated" to more legible form) > to outsiders. > > Certainly it's not impossible, but I guess currently this money > is spent better improving the software. > > > Your request about listing public bugzilla bugs on the other hand was > something that should be fairly easy and straightforward to do. > I support it, these are the issues that users themselves have bumbed > into and seen the effort to report to us. > > > - Eero
Perhaps in future you should mark internal bugs with a disclose/non-disclose flag that can be used to automatically determine whether bugs are included or excluded from a subsequent changelog query. Keep secret those bugs with legal issues attached, and don't disclose those bugs that are irrelevant, but do disclose those bugs which have resulted in material changes to applications and other components. And of course always disclose any bug aliased to a public bug. It's a matter of (development) process, and ensuring that everyone sticks to the process so that when the time comes for you to generate a changelog it's simply a case of running a query against your defect tracking system. No (adequate) process means no changelog. A project without a changelog or the ability to create one does not on the surface appear to be in good shape. You may be able to satisfy yourselves internally with a changelog, but this project is supposed to be a collaboration between yourselves and the community and withholding this information gives the wrong impression on a number of levels. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
