Re: 3.2007.10-7 - Detailed change log?
Quim Gil wrote: About fixed bugs reported in the public bugzilla, we know we owe to the users and developers reporting those bugs a better response. The progress done in the last 6 months is remarkable but we are still not there. We tried but we couldn't have an updated report in the last release. We are still working in our processes. Being conservative I expect the Chinook release to have a partial collection of fixed bugs and get into good quality standards by Diablo. Hi Quim - resurrecting this old chestnut once again. :) Any chance of an update regarding a change log for Chinook, if not a full and detailed change log then at the very least a cross reference with the public bugzilla? Happy New Year to everyone at maemo.org and the mailing list! :) Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Mon, 2007-08-06 at 17:21 +0300, Marius Vollmer wrote: ext Guillem Jover [EMAIL PROTECTED] writes: What you seem to be asking for, is some kind of Release Notes, with the most important package versions, or really big features. What is missing from my packages (and probably others) is a properly maintained NEWS file, and maybe a channel to make these NEWS files easily accessible from the Release Notes of a OS release. I don't maintain the NEWS file since I don't make proper releases of my packages: I just make snapshot after snaphot and then suddenly its over and the OS is released, containing whatever was my last snapshot. I would be good to maintain the NEWS file also for snapshots, and I should force myself to do it. Yes, this would be a big help. You'd have my thanks. You probably do something similar for your debian changelogs already. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: 3.2007.10-7 - Detailed change log?
How about all of them? Please check what's available; kernel and X git repositories you should find with Google, Application framework stuff you will find from Maemo (until it's moved to Gnome), new Browser is in Garage. For all the open source(d) packages you find the debian source package from the maemo repos and those contain change logs. Maybe you could view them and tell what specifically you're lacking? Hmmm, I think someone's missing the point here. You Nokia tell me as an end user nothing about what's in each release. From start to finish, there's no information in a release that tells me what it includes. I can't see *end user* caring a bit about having a Freetype 2.2.1-1osso3 in the release and how it differs from the Freetype in previous release. That is probably not what you meant. At the very minimum I want the delta between the current and previous releases. Like the delta we announced for the latest release? http://repository.maemo.org/stable/3.2/content_comparison.html http://tablets-dev.nokia.com/3.2/maemo-sdk-relnotes_3.2.txt http://tablets-dev.nokia.com/3.2/content_changes.html http://europe.nokia.com/A4307030 To be honest, your response is more along the same line of the previous responses, i.e. it's more complex than you understand which again just tells me Nokia either can't or won't provide this information. Makes me sad people see it this way without knowing enough. Br, --jakub ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] schreef: To be honest, your response is more along the same line of the previous responses, i.e. it's more complex than you understand which again just tells me Nokia either can't or won't provide this information. Makes me sad people see it this way without knowing enough. Makes me sad when nokia (employees) don't tell us enough and then try guilting us into shutting up with statements like the above. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGtvYkMkyGM64RGpERAnwcAJ4n7xhy/yyJ1s/L+5qoZamGLpOJfgCffT4J R7nCzJO33MnEsTcK4cAhslo= =0jBs -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
Hi, back from holidays. mmm where to start On Fri, 2007-08-03 at 20:23 +0100, ext Andy Mulhearn wrote: You Nokia tell me as an end user nothing about what's in each release. From start to finish, there's no information in a release that tells me what it includes. Let's see what Nokia has told end users about the last release: (((moved to the end of the message since Jakub posted most if it while I was writing this email))) I would say the majority of end users and application developers can live happily with this. All this is much more than we had in previous releases: compare to the IT OS 2007 / maemo 3.0 release 6 months before and you will see the progress done. Is this not enough? Agreed, this is why more work is being done. In order to get into details let's de-mix some aspects that are quite mixed in this discussion - helping nobody: NEW FEATURES vs FIXED BUGS Features and bugs go through totally different channels in our development process. Offering more level of detail about new features is doable. We made a first step for the latest update, and for Chinook we plan to have a level of detail that will hopefully make happy power users (and developers when we talk about development related tools). About fixed bugs reported in the public bugzilla, we know we owe to the users and developers reporting those bugs a better response. The progress done in the last 6 months is remarkable but we are still not there. We tried but we couldn't have an updated report in the last release. We are still working in our processes. Being conservative I expect the Chinook release to have a partial collection of fixed bugs and get into good quality standards by Diablo. END USER ORIENTED vs DEVELOPER ORIENTED Nokia develops products mainly for mainstream consumers and maemo offers a platform mainly to application developers. I think the level of detail provided in the last release to these two groups is quite decent. One exception would be the users that have submitted bugs, as mentioned before. Another exception would be the platform developers, that just recently we have confirmed that we want to serve as well. If you disagree with the previous paragraph please file bugs and requests for enhancement, being as specific as possible. I'm the direct responsible of this area and this is one of my priorities (again) for the current release under development. INTERNAL vs EXTERNAL Nowadays a Nokia developed piece of code goes through a full internal process before being published in a new release. Testing and bugfixing are part of this process, generating lots of bugs that are fixed before the code is made public. Nokia won't publish information about bugs fixed before the new code is released. Things change as soon as the code is published. Known bugs should be shared and updates on publicly submitted bugs should be updated. In fact those bugs already solved in internal releases should be already updated, and some of this is already happening now. A field of progress has been the release of software under development, allowing the community to file bugs before an official release. We will do more of this and we can do more if all of us conclude that is worth going for a public maemo distribution, where our integration process would be public. DISTRIBUTION vs PACKAGES Even if we agree that we need t provide more details on new features and fixed bugs, things like a detailed change log and a full list of bugs fixed belong more to the package / application level than to the release of a whole distribution / operating system. An IT OS consists of hundreds of packages and we can't expect each one of them offering the same level of detail than i.e. a new Inkscape release. We are happy comparing maemo release notes with the release notes of other distributions or operating systems. And then we can also compare releases of applications with an end user impact, platform components and so on. Comparing apples with apples and oranges with oranges we will be able to find easier a satisfactory solution. For instance at a package level all the open sources include a changelog. If you find the level of detail isn't enough please file a bug against that package. OPEN SOURCE vs PROPRIETARY Open source software and non-free software usually deal differently with the details provided in updates and new developments. We need to agree in the appropriate feedback and level of detail that is desirable, useful and possible for each case. We are happy agreeing on documented levels of details to be satisfied. NOKIA DEVELOPED vs THIRD PARTY We are responsible of all the software released in the IT OS, but we are more responsible of the software we develop. We are happy agreeing on the information to be provided in the new releases of the packages developed by Nokia. We are more likely to remit responsibilities to upstream projects, partners or other 3rd party combination when it comes to discuss their own packages.
Re: 3.2007.10-7 - Detailed change log?
On Mon, Aug 06, 2007 at 12:21:24PM +0200, ext Koen Kooi wrote: Makes me sad when nokia (employees) don't tell us enough and then try guilting us into shutting up with statements like the above. Hi, It's pretty easy to just see Nokia as a nameless, faceless corporation responsible for all the world's evils. But please remember that, on maemo-developers, you're talking to people (often free software developers in their own time[0]). You can try to pin every single failing of Nokia, or a couple-of-hundred-person organisation within Nokia, on them, but after a while, we'll probably just give up and go back to lurking. I'm not responding to this thread, because every time I do, I end up feeling like every single shortcoming of Maemo is on my shoulders, and quite honestly, I can't be arsed with that. Cheers, Daniel, free software developer paying food and rent through his job [0]: On this list, you have active developers from Debian, the Linux kernel, and X.Org to name but a few. Between us, we've maintained dpkg, X, DirectFB, KDE, GNU/Hurd, GNU/kFreeBSD and many others, in both Debian and Ubuntu. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Speaking in the name of Nokia (was Re: 3.2007.10-7 - Detailed change log?)
Just to clarify some roles here: - Some people like Daniel are developing specific stuff for maemo. You can ask, suggest, criticize and they will probably answer to the best of their knowledge and time about the areas they work in. They might eventually scale up and discuss some maemo or Nokia wide topics, and even join uncomfortable discussions that are not directly under their responsibility - just because they love you (aka have much respect for your time, brain and energies invested in this project). - Some people like me (and my direct managers that probably won't come to maemo-developers to discuss) are quite useless alone when it comes to give help or discuss technicalities about package X. In exchange we can offer a general vision about maemo and Nokia, try to clarify things, take note of general improvements, better strategic approaches and so on. Take the best from each of us, that's my advice. We are just as good people and as well intentioned as you. And we work at Nokia, yes. On Mon, 2007-08-06 at 14:39 +0300, ext Daniel Stone wrote: It's pretty easy to just see Nokia as a nameless, faceless corporation responsible for all the world's evils. But please remember that, on maemo-developers, you're talking to people (often free software developers in their own time[0]). -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
Hi, (as always, my own opinions, not Nokia's) ext Andy Mulhearn wrote: Hmmm, I think someone's missing the point here. You Nokia tell me as an end user nothing about what's in each release. From start to finish, there's no information in a release that tells me what it includes. At the very minimum I want the delta between the current and previous releases. This is not really an area where I can have an effect except by making sure my own packages changelogs are OK(ish), but I'm genuinely interested about things improving. Please be a bit more specific about what things need to improve, and how they should be improved, answering Everything! to a question of what's wrong doesn't really say anything (any developer should know that). If you have examples, the better. As a start, I Googled a bit what the other distributions have as their release notes (I did this pretty quickly so I'm sure I've missed/misread some information that is available): Maemo: http://maemo.org/news/view/1183705330.html http://maemo.org/news/view/1183706440.html http://repository.maemo.org/stable/3.2/content_comparison.html http://maemo.org/news/view/1186118712.html List of the new features in ITOS, more details about SDK, list of packages and their versions, installation instructions. How to get source packages (with their changelogs) for the Open Source/Sourced components. In the latest ITOS release there really weren't that much changes besides the listed new features, mostly it's just support for the new features listed in the announcement. RedHat: http://docs.fedoraproject.org/release-notes/f7/en_US/ http://fedoraproject.org/wiki/Docs/Beats/PackageChanges/UpdatedPackages Quite nice, has installation/upgrade notes, requirements, some screenshots, notes about changes in (some) packages usage. Suse: http://www.suse.com/relnotes/i386/openSUSE/10.2/RELEASE-NOTES.en.html http://www.novell.com/documentation/sled10/readme/RELEASE-NOTES.en.html http://www.novell.com/products/desktop9/ http://www.novell.com/products/linuxpackages/desktop/index_all.html About the same information. Ubuntu: http://www.ubuntu.com/GetUbuntu/releasenotes/606 https://wiki.ubuntu.com/EdgyReleaseNotes Even less information. Debian: Good per package upgrade information. No screenshots. Windows (Vista): http://www.microsoft.com/windows/products/windowsvista/default.mspx http://technet.microsoft.com/en-us/windowsvista/default.aspx Very extensive (but then, with Office, Windows is the main MS product and it does releases a bit less often). Some observations: * For all of these Linux distros the package change list seems to be provided only by distrowatch (community), for example: http://distrowatch.com/table.php?distribution=fedora * None of these list bugs fixed in the release. Comments on Maemo: * As noted earlier, public vs. internal Bugzilla handling could be improved. It should be possible to query what public bugs are fixed between public releases and get a good answer (especially as Maemo package source package changelogs list internal bug numbers) * _No_ other distro is providing bugfix list for releases, so I don't see why it's so huge deal Maemo not providing one either. For open source components the fixes can be seen from the changelogs. For closed components, if the possible bugs haven't bothered anybody enough to file bug reports (so that status could be seen from a public Bugzilla), clearly they are not an issue... - Note: security bugs in closed components could be a different issue, but the closed components handling data from the network are mostly things that Nokia doesn't control (Flashplayer, Opera, multimedia codecs). I think you need to bug upstream provider about them also. * For many of the Linux distros, www-sites not associated with the project can also contain articles which Tour the new release and provide screenshots, so this could be provided by the community, if Nokia is not doing it * There could be a list of all packages and table of their versions also for ITOS releases, not just the SDK ones (which lacks proprietary packages from ITOS, but has additional devel packages) I guess, but that doesnt' add that much If that's fixed defect this in package that and upgraded Opera to version y then that's fine. But you seem incapable of doing even that. Are you talking about: - Bugs in the upstream Opera - Bugs in Maemo specific Opera changes (if any), hopefully filed to Maemo bugzilla ? For former you would anyway need go to upstream bug tracking system, I don't think we internally track all the bugs in upstream components, at least there's nobody duplicating upstream bugs to our internal bugzilla. If the proprietary components would be available also as separate binary packages, and (most of) those would have (reasonable) changelogs, would that seem a reasonable aim? The packages version list table could maybe then have
Re: 3.2007.10-7 - Detailed change log?
On 06/08/07 16:10 +0300, ext Eero Tamminen wrote: * _No_ other distro is providing bugfix list for releases, so I don't see why it's so huge deal Maemo not providing one either. I guess it's a deal for those who want to maintain another distro based on the maemo components but not the packaging. If such a thing is good, useful, great or something else, I don't know. /lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Fri, Aug 03, 2007 at 06:19:40PM +0100, ext Neil MacLeod wrote: Let's face it, the existence of two bug tracking systems (one internal and one public) isn't helping matters This is a basic requirement of corporate security, for reasons I assumed were obvious, but given that they apparently aren't: having non-public information in the same BTS as the public one opens it wide up for abuse if a hole is found in Bugzilla, e.g. This is not acceptable. nor is the repeated promises that the situation will improve when there is little evidence of this happening - there is precious little Nokia involvement in the public Bugzilla, bug #1204 being a prime example. As has been noted repeatedly in public, our SD/MMC guy is on holiday (continental Europe has this one month of holiday in summer thing), so there's not a lot a lot we can do until he gets back. There is no more information about this in private than in public. So that's a pretty terrible example. Why is it not possible to use the public bugzilla to track the majority of the bugs? I'm sure your internal system is tracking bugs that we also eventually find, but why do we have to double up on bug detection and reporting duties? Because of reasons of security I've explained above. A decision was made (for better or worse) to launch the N800 immediately as it was sold. Now imagine that we had the same Bugzilla, and back in January 2006, someone used one of the Bugzilla vulnerabilities (of which there have been a few) to access private bugs, which dealt with the N800. Wouldn't really work so well. Changelogs though are fundamental, and I don't really care for Nokia bureaucracy or inefficiency. I realise that's not your fault, and I'm sorry to say that it's this Nokia bureaucracy that is going to kill the Nokia Internet Tablet project as developers move on to other projects where they don't have to bang their heads against these kind of brick walls. I'm glad to hear that you don't really care for it (you're hardly the only one), but however you word it, the procedures and rules exist, and we all have to deal with them. Ranting at the developers who take their time out to try to get involved in maemo-developers@ will hardly help this, since it's not like we can change it. But maybe that's just me. Cheers, Daniel, but a cog signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Fri, Aug 03, 2007 at 06:32:07PM +0300, Eero Tamminen wrote: Please check what's available; kernel and X git repositories you should find with Google Actually, you can't find the X git repository. This is partially because I can't publish the one I use for actual development, as it contains a few things which cannot be made public, but the reason I haven't made a user repository on freedesktop.org with the Maemo changes is just because I'm crap and disorganised, rather than any deliberate Nokia conspiracy to keep people from finding the precious changes. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
Hi, First I should mention that I was discussing only bugfixes, I agree that features should be listed, but I've understood from Quim's mail that this should be already improving. (Like all my other mails on this list, these are personal opinions.) ext Neil MacLeod wrote: We certainly know what we've fixed, but the issue is that there's no reasonable way to know what part of that is relevant to you. At the very least publish those bugs that are aliased to bugs in the Public bugzilla. Any half-decent bug tracking system should allow this type of query. Agree, and the fixed bugs in public bugzilla could be marked fixed at the same time when the changelog is released, so that people can verify the fixes immediately. You have the public bugs aliased to internal bug references and I assume (bad I know) that a similar relationship exists internally in which case simply pull out those aliased bugs that are fixed in the most recent release. I think there might be few bugs in the public bugzilla that are not reported internally. At least several bugs in the public bugzilla don't have internal bugzilla numbers in them. For some this might be because there's some problem with the bug report, for example the steps are not specific enough or the bug was not reproduceble. Anyway, I think we should have more strict rules about that. Besides the internal bug always referring the corresponding public one, IMHO Maemo QA should add internal bug numbers to external bugzilla once the bugs have been reported internally. It kind of tells the community when and that the message has been forwarded. Quim, could you comment this? I don't think anyone here is willing to take the cost of e.g. testing all the major bugs fixed from the intermediate development releases and test whether they can be also replicated in the previous public release, especially as 1% of that work would actually produce anything to the release notes (and even less to end-user release notes) and this large testing cost (for example some tests need quite elaborate setups) wouldn't do anything to make the new release any better! Is there any scope here to introduce automated testing? It sounds like that's what you need. We (of course) have a huge amount of automated tests, for the (almost as) huge number of requirements, but: - Automated UI testing is less reliable than unit testing - Different testing tools and methods (which are used internally) have different pros and cons All this means that although test execution and most of test setup is automated, a lot of the automated tests requires somebody to manually verify that the test results are correct and sometimes even to verify that test was executed correctly from the intermediate results (screenshots etc) or just by monitoring it being run. To give some scope on this, go to www.w3.org and browse through the specifications required to implement a standards compliant HTML widget for a browser application. Then think about how many test-cases and different tests you would need for the different aspects in the specs. And this is just one part of one application, then there are rest of the apps, rest of the system, non-functional requirements etc. On top of that we have ad-hoc manual testing done by everybody in the product organization. If you were asking whether we automate tests for each bug that has been reported and/or fixed, in general tests for bugs from ad-hoc testing are not automated. However I fail to understand what your point has to do with the generation of a changelog. 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 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
Hi, ext Andy Mulhearn wrote: On Thursday, August 02, 2007, at 12:11PM, Daniel Stone [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 02:05:31AM -0700, ext Andy Mulhearn wrote: On Thursday, August 02, 2007, at 09:56AM, Eero Tamminen [EMAIL PROTECTED] wrote: We certainly know what we've fixed, but the issue is that there's no reasonable way to know what part of that is relevant to you. Well publish the whole list then. Surely it can't be that hard? The whole list includes not only internal codenames etc which can't be published, but details of proprietary components. So it's not just a matter of dumping the BTS, it still requires someone to go through and make the changelog (which we should have anyway). And which people have been requesting for a significant period of time. For example I don't think you would be interested about a list of a few hundred localization issues (missing localization, typos etc) found by the localization testing while a new release is being developed, especially as none of these issues is in any release you can install to your device. They are not in the latest public release where they are fixed nor in the previous one which didn't have them. When the fixes were checked into your source repository, did you detail every single change made or the headline? 'your source repository'. Do you mean the Application Framework SVN repository, the Complementary Applications SVN repository, my X server git repository, the kernel git repository, ... ? How about all of them? Please check what's available; kernel and X git repositories you should find with Google, Application framework stuff you will find from Maemo (until it's moved to Gnome), new Browser is in Garage. For all the open source(d) packages you find the debian source package from the maemo repos and those contain change logs. Maybe you could view them and tell what specifically you're lacking? Sorry to be blunt but I'm beginning to believe there are two reasons this hasn't been done before. 1) Your development processes are so chaotic/broken that you simply can't do it., e.g. you don't use a decent bug-tracking tool and no one manages what goes into a release. 2) You just don't want to and no one can be bothered to make the statement. When the team I work with produce a new cut of software, we include all of the specific requirements added to the release and any defects fixed in the release. And what's fixed in any third party products we use. This can run to hundreds of specific changes in a major release but we manage to do it and we dont' have a huge team to managed it because we have good processes and controls and use the right tools to manage releases and defect tracking.. So I fail to see why you can't present this information other than one of the two reasons above. I think you're confusing things. We have all that for internal releases and internal customers. External distro/core developers can already follow changes live through maemo-developers, sardine, ubuntu-mobile/embdded, gtk etc mailing lists and svn to an extent (although there's still a lot to improve). I understood the problem being discussed here is how to map that to public releases and for end-users? As Quim stated, this is being (slowly) improved. ext Neil MacLeod wrote: A project without a changelog or the ability to create one does not on the surface appear to be in good shape. Agree. 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. It's not so much withholding the information as getting somebody spending large effort on collecting, filtering/reducing and translating this information to publicly relevant/usable form. As an open source developer I hope that eventually as the platform becomes more open, the significance of proprietary part fades away (because there's so much cool stuff on the open :)). As the community starts to participate more in the Maemo development, I see the importance (and benefit) of concise whole distribution changelog increasing. But when the platform opens more, the people from the community could also provide it... Nokia changelog would anyway be boring consumer related thing lacking all the cool technical details, I feel maemo-developers want something more snazzy. ;-) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
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
Re: 3.2007.10-7 - Detailed change log?
Hi, On Fri, 2007-08-03 at 16:39:07 +0100, ext Andrew Flegg wrote: On 8/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: Please check what's available; kernel and X git repositories you should find with Google, Application framework stuff you will find from Maemo (until it's moved to Gnome), new Browser is in Garage. For all the open source(d) packages you find the debian source package from the maemo repos and those contain change logs. Maybe you could view them and tell what specifically you're lacking? OK, so the only changelog we need is: * Moved from vX.Y.Z to vX.Y.Z2 of Xorg * Moved from v2.6.20-arm-rmk0 to v2.26.23-arm-rmk1 of Linux kernel * Moved from branches/20060403-HAF r3929 to branches/20070801-HAF r3829 * ... Err, then I think the problem is that people don't seem to be talking about the same things here. When I read people demanding changelogs, for me that maps to debian/changelog or GNU style kind of ChangeLog in the source tree. Any package w/o a proper descriptive changelog is broken IMO, and it must be fixed. What you seem to be asking for, is some kind of Release Notes, with the most important package versions, or really big features. And if I'm not mistaken we have that already, it might be lacking, though. Otherwise please explain exactly what are you requesting, I think Eero is having the same problem understanding what people is asking. Of course, this presupposes there are absolute *zero* patches that you're maintaining internally for these things which aren't upstream. I say that presupposition is wrong. Take Debian as an example, most of the packages contain changes relative to upstream, yet this is not announced in any kind of distro-wide Release Notes. It's present, though, on the particular NEWS.Debian files or debian/changelogs. regards, guillem ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On 8/3/07, Eero Tamminen [EMAIL PROTECTED] wrote: Please check what's available; kernel and X git repositories you should find with Google, Application framework stuff you will find from Maemo (until it's moved to Gnome), new Browser is in Garage. For all the open source(d) packages you find the debian source package from the maemo repos and those contain change logs. Maybe you could view them and tell what specifically you're lacking? OK, so the only changelog we need is: * Moved from vX.Y.Z to vX.Y.Z2 of Xorg * Moved from v2.6.20-arm-rmk0 to v2.26.23-arm-rmk1 of Linux kernel * Moved from branches/20060403-HAF r3929 to branches/20070801-HAF r3829 * ... Of course, this presupposes there are absolute *zero* patches that you're maintaining internally for these things which aren't upstream. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On 3 Aug 2007, at 16:32, Eero Tamminen wrote: Hi, ext Andy Mulhearn wrote: On Thursday, August 02, 2007, at 12:11PM, Daniel Stone [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 02:05:31AM -0700, ext Andy Mulhearn wrote: On Thursday, August 02, 2007, at 09:56AM, Eero Tamminen [EMAIL PROTECTED] wrote: We certainly know what we've fixed, but the issue is that there's no reasonable way to know what part of that is relevant to you. Well publish the whole list then. Surely it can't be that hard? The whole list includes not only internal codenames etc which can't be published, but details of proprietary components. So it's not just a matter of dumping the BTS, it still requires someone to go through and make the changelog (which we should have anyway). And which people have been requesting for a significant period of time. For example I don't think you would be interested about a list of a few hundred localization issues (missing localization, typos etc) found by the localization testing while a new release is being developed, especially as none of these issues is in any release you can install to your device. They are not in the latest public release where they are fixed nor in the previous one which didn't have them. When the fixes were checked into your source repository, did you detail every single change made or the headline? 'your source repository'. Do you mean the Application Framework SVN repository, the Complementary Applications SVN repository, my X server git repository, the kernel git repository, ... ? How about all of them? Please check what's available; kernel and X git repositories you should find with Google, Application framework stuff you will find from Maemo (until it's moved to Gnome), new Browser is in Garage. For all the open source(d) packages you find the debian source package from the maemo repos and those contain change logs. Maybe you could view them and tell what specifically you're lacking? Hmmm, I think someone's missing the point here. You Nokia tell me as an end user nothing about what's in each release. From start to finish, there's no information in a release that tells me what it includes. At the very minimum I want the delta between the current and previous releases. If that's fixed defect this in package that and upgraded Opera to version y then that's fine. But you seem incapable of doing even that. And the new browser is not part of the released image so I'm not interested. But will be when it is. To be honest, your response is more along the same line of the previous responses, i.e. it's more complex than you understand which again just tells me Nokia either can't or won't provide this information. Sorry to be blunt but I'm beginning to believe there are two reasons this hasn't been done before. 1) Your development processes are so chaotic/broken that you simply can't do it., e.g. you don't use a decent bug-tracking tool and no one manages what goes into a release. 2) You just don't want to and no one can be bothered to make the statement. When the team I work with produce a new cut of software, we include all of the specific requirements added to the release and any defects fixed in the release. And what's fixed in any third party products we use. This can run to hundreds of specific changes in a major release but we manage to do it and we dont' have a huge team to managed it because we have good processes and controls and use the right tools to manage releases and defect tracking.. So I fail to see why you can't present this information other than one of the two reasons above. I think you're confusing things. We have all that for internal releases and internal customers. No, I can't help thinking that it's you that's trying to obfuscate things. External distro/core developers can already follow changes live through maemo-developers, sardine, ubuntu-mobile/embdded, gtk etc mailing lists and svn to an extent (although there's still a lot to improve). I understood the problem being discussed here is how to map that to public releases and for end-users? As Quim stated, this is being (slowly) improved. If slow improvement means not seeing any change over a period of six months then yes, there is slow improvement. [snipped a response to a different author's questions] Andy ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Mulhearn schreef: I understood the problem being discussed here is how to map that to public releases and for end-users? As Quim stated, this is being (slowly) improved. If slow improvement means not seeing any change over a period of six months then yes, there is slow improvement. Six months? I think you mean 2 years :( regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGs4JxMkyGM64RGpERApXnAJ9ENMUQbN84Il0O+MM6zAWeTjahZgCgqGln 60+EAGvIcQu2CIw8Psw9hg4= =rX1k -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
Hi, ext Neil MacLeod wrote: Quim Gil wrote: On Sat, 2007-07-07 at 18:41 +0100, ext Neil MacLeod wrote: By Diablo, perhaps. We hope so. I should hope it should be possible to release something as basic as a changelog by v5 of a project. I know that sounds harsh, but seriously... if you don't what you've fixed in any given release it really does suggest a chaotic process. We certainly know what we've fixed, but the issue is that there's no reasonable way to know what part of that is relevant to you. For example I don't think you would be interested about a list of a few hundred localization issues (missing localization, typos etc) found by the localization testing while a new release is being developed, especially as none of these issues is in any release you can install to your device. They are not in the latest public release where they are fixed nor in the previous one which didn't have them. I don't think anyone here is willing to take the cost of e.g. testing all the major bugs fixed from the intermediate development releases and test whether they can be also replicated in the previous public release, especially as 1% of that work would actually produce anything to the release notes (and even less to end-user release notes) and this large testing cost (for example some tests need quite elaborate setups) wouldn't do anything to make the new release any better! - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Thursday, August 02, 2007, at 09:56AM, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Neil MacLeod wrote: Quim Gil wrote: On Sat, 2007-07-07 at 18:41 +0100, ext Neil MacLeod wrote: By Diablo, perhaps. We hope so. I should hope it should be possible to release something as basic as a changelog by v5 of a project. I know that sounds harsh, but seriously... if you don't what you've fixed in any given release it really does suggest a chaotic process. We certainly know what we've fixed, but the issue is that there's no reasonable way to know what part of that is relevant to you. Well publish the whole list then. Surely it can't be that hard? For example I don't think you would be interested about a list of a few hundred localization issues (missing localization, typos etc) found by the localization testing while a new release is being developed, especially as none of these issues is in any release you can install to your device. They are not in the latest public release where they are fixed nor in the previous one which didn't have them. When the fixes were checked into your source repository, did you detail every single change made or the headline? I don't think anyone here is willing to take the cost of e.g. testing all the major bugs fixed from the intermediate development releases and test whether they can be also replicated in the previous public release, especially as 1% of that work would actually produce anything to the release notes (and even less to end-user release notes) and this large testing cost (for example some tests need quite elaborate setups) wouldn't do anything to make the new release any better! i'm not sure I see the relevance of this comment. Is it a reply to a different question? Andy ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Thu, Aug 02, 2007 at 02:05:31AM -0700, ext Andy Mulhearn wrote: On Thursday, August 02, 2007, at 09:56AM, Eero Tamminen [EMAIL PROTECTED] wrote: We certainly know what we've fixed, but the issue is that there's no reasonable way to know what part of that is relevant to you. Well publish the whole list then. Surely it can't be that hard? The whole list includes not only internal codenames etc which can't be published, but details of proprietary components. So it's not just a matter of dumping the BTS, it still requires someone to go through and make the changelog (which we should have anyway). For example I don't think you would be interested about a list of a few hundred localization issues (missing localization, typos etc) found by the localization testing while a new release is being developed, especially as none of these issues is in any release you can install to your device. They are not in the latest public release where they are fixed nor in the previous one which didn't have them. When the fixes were checked into your source repository, did you detail every single change made or the headline? 'your source repository'. Do you mean the Application Framework SVN repository, the Complementary Applications SVN repository, my X server git repository, the kernel git repository, ... ? Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Thursday, August 02, 2007, at 12:11PM, Daniel Stone [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 02:05:31AM -0700, ext Andy Mulhearn wrote: On Thursday, August 02, 2007, at 09:56AM, Eero Tamminen [EMAIL PROTECTED] wrote: We certainly know what we've fixed, but the issue is that there's no reasonable way to know what part of that is relevant to you. Well publish the whole list then. Surely it can't be that hard? The whole list includes not only internal codenames etc which can't be published, but details of proprietary components. So it's not just a matter of dumping the BTS, it still requires someone to go through and make the changelog (which we should have anyway). And which people have been requesting for a significant period of time. For example I don't think you would be interested about a list of a few hundred localization issues (missing localization, typos etc) found by the localization testing while a new release is being developed, especially as none of these issues is in any release you can install to your device. They are not in the latest public release where they are fixed nor in the previous one which didn't have them. When the fixes were checked into your source repository, did you detail every single change made or the headline? 'your source repository'. Do you mean the Application Framework SVN repository, the Complementary Applications SVN repository, my X server git repository, the kernel git repository, ... ? How about all of them? Sorry to be blunt but I'm beginning to believe there are two reasons this hasn't been done before. 1) Your development processes are so chaotic/broken that you simply can't do it., e.g. you don't use a decent bug-tracking tool and no one manages what goes into a release. 2) You just don't want to and no one can be bothered to make the statement. When the team I work with produce a new cut of software, we include all of the specific requirements added to the release and any defects fixed in the release. And what's fixed in any third party products we use. This can run to hundreds of specific changes in a major release but we manage to do it and we dont' have a huge team to managed it because we have good processes and controls and use the right tools to manage releases and defect tracking.. So I fail to see why you can't present this information other than one of the two reasons above. Andy ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
Eero Tamminen wrote: Hi, We certainly know what we've fixed, but the issue is that there's no reasonable way to know what part of that is relevant to you. At the very least publish those bugs that are aliased to bugs in the Public bugzilla. You have the public bugs aliased to internal bug references and I assume (bad I know) that a similar relationship exists internally in which case simply pull out those aliased bugs that are fixed in the most recent release. Any half-decent bug tracking system should allow this type of query. I don't think anyone here is willing to take the cost of e.g. testing all the major bugs fixed from the intermediate development releases and test whether they can be also replicated in the previous public release, especially as 1% of that work would actually produce anything to the release notes (and even less to end-user release notes) and this large testing cost (for example some tests need quite elaborate setups) wouldn't do anything to make the new release any better! Is there any scope here to introduce automated testing? It sounds like that's what you need. However I fail to understand what your point has to do with the generation of a changelog. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Mon, 2007-07-09 at 06:45 +0100, ext Neil MacLeod wrote: I should hope it should be possible to release something as basic as a changelog by v5 of a project. It's not about versions but about integrating/coordinating our internal development process with http://bugs.maemo.org . This is what we are doing but progress is slower as (I) expected. There is progress, though. I hope to see some concrete results for Chinook and the problem solved at least at satisfactory levels for Diablo. One visible step forward to be seen (soon) and shared with you will be the reorganization of bugs.maemo.org. The current structure of products and components needs a drastic improvement in order to be more comprehensive to users and developers, and also in order to match better our internal tools and processes. I know that sounds harsh, but seriously... if you don't what you've fixed in any given release it really does suggest a chaotic process. No problem sounding harsh, we know that we should do much better at this point. However, the process is not chaotic. It is precisely the structure and complexity of the process what makes changes and gathering/sharing information more difficult than it seems. I'm not looking for anything fancy, a list of bug identifiers and associated subjects would suffice as a minimum - anything in addition would be a bonus. I wasn't asking for anything fancy. You perfectly answered my question. Changelog and Release notes might have different meanings for different people. I'm asking in order to know better the expectations. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Mon, 2007-07-09 at 08:36 +0300, Quim Gil wrote: Something that would help are links to your preferred release notes. Yes we know that in principle the more details the better, but providing examples of non-exhaustive yet satisfactory release notes you like and find useful would help us focusing in a model. One of the things that we've found really useful on the Inkscape project is that the release notes for the next release are a wiki page. Then, as we're working on the next release the notes are being written. There is lots of peer pressure internally that when a feature is committed, the notes are written. These usually end up more detailed than most of the stuff that we publish on places like Freshmeat or to news sites. But having more detail and distilling means that things don't get forgotten as easily. Plus, must of the work is front loaded instead of being at the point someone really wants to get a release out. Here are the notes for the next release: http://wiki.inkscape.org/wiki/index.php/ReleaseNotes046 --Ted signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Sat, 2007-07-07 at 18:41 +0100, ext Neil MacLeod wrote: Are there any plans to publish a detailed changelog for 4.2007.26-8? Nope, sorry. We have tried but our internal process is not ready for this, yet. We have improved providing more details than before about the new features implemented. You can see the results comparing http://maemo.org/news/view/1183705330.html to the brief notes released in the past. At a maemo level there is http://repository.maemo.org/stable/3.2/content_comparison.html but I agree all this is not enough. We have been working on the internal processes though, in order to end up delivering proper release notes as open source development is used to. This will allow us to provide more details in the Chinook release, although already today I can see that we (and you) are not going to be totally happy about them. By Diablo, perhaps. We hope so. In any case let's state clear that publishing proper release notes is a goal for us, including a changelog with improvements / modifications in the IT OS functionality and public bugs fixed. Something that would help are links to your preferred release notes. Yes we know that in principle the more details the better, but providing examples of non-exhaustive yet satisfactory release notes you like and find useful would help us focusing in a model. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
Quim Gil wrote: On Sat, 2007-07-07 at 18:41 +0100, ext Neil MacLeod wrote: By Diablo, perhaps. We hope so. I should hope it should be possible to release something as basic as a changelog by v5 of a project. I know that sounds harsh, but seriously... if you don't what you've fixed in any given release it really does suggest a chaotic process. Something that would help are links to your preferred release notes. Yes we know that in principle the more details the better, but providing examples of non-exhaustive yet satisfactory release notes you like and find useful would help us focusing in a model. I'm not looking for anything fancy, a list of bug identifiers and associated subjects would suffice as a minimum - anything in addition would be a bonus. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
[EMAIL PROTECTED] wrote: Did you (or anyone else) manage to make any progress on a changelog for 3.2007.10-7? I have started the internal discussion with the aim of having a changelog linking to maemo's bugzilla being published together with the next IT OS release notes. And improve from that point in next releases. Still a proposal, but looking good. Quim Hi Quim Are there any plans to publish a detailed changelog for 4.2007.26-8? Many thanks Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: 3.2007.10-7 - Detailed change log?
Did you (or anyone else) manage to make any progress on a changelog for 3.2007.10-7? I have started the internal discussion with the aim of having a changelog linking to maemo's bugzilla being published together with the next IT OS release notes. And improve from that point in next releases. Still a proposal, but looking good. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
[EMAIL PROTECTED] wrote: On Behalf Of ext Neil MacLeod Would it be possible to provide a detailed change log for 3.2007.10-7, ideally cross-referenced with the public Bugzilla so that we (the users) known which of those bugs we have raised have been addressed? The published change log is extremely inadequate, unfortunately. Many thanks... Hi all, This sounds like something technically easy to do (for Nokia): 1) get all the internal bugs we have fixed 2) extract the referrences to public bugzilla 3) make sure all the public bugzilla bugs are marked as FIXED the same day we release the update And as a bonus lets list the public bugs in the changelog as fixed. This all should be done automatically, perhaps even for the 3.2007.10-7 so that we do not forget about it next time again. Br, --jakub Hi Jakub Did you (or anyone else) manage to make any progress on a changelog for 3.2007.10-7? Thanks Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: 3.2007.10-7 - Detailed change log?
On Wed, 2007-03-28 at 18:15 +0200, ext Murray Cumming wrote: On Wed, 2007-03-28 at 14:16 +0300, [EMAIL PROTECTED] wrote: Do not give up on it just yet, it is changing for better. We have a real person behind [EMAIL PROTECTED] If not counting enhancement requests and reports on closed applications then almost all new bug reports get handled. Jake co is going through all the bugs, step by step. I'm getting CCed in all the feature requests. New entries are being redirected quickly. Even if the workforce starts being there, we still need to improve software, structure and processes. This will take longer but I'm pushing for a little plan to make most of this happening in the following months. I would like to see a sanitized maemo bugzilla in good shape in less than one year, as friendly as GNOME's (or more, if you have ideas how) ;) -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
Daniel Stone wrote: You got it. The majority of the bug work happens before product release: going by what's in the changelogs, the external database has roughly 2% of the bugs as the internal one. That might well be because I (and others) have given up on using the external bug database as it seems next to useless. spaetz ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Using the external bugzilla (was: 3.2007.10-7 - Detailed change log?)
On Wed, 2007-03-28 at 11:41 +0200, ext Sebastian Spaeth wrote: Daniel Stone wrote: You got it. The majority of the bug work happens before product release: going by what's in the changelogs, the external database has roughly 2% of the bugs as the internal one. That might well be because I (and others) have given up on using the external bug database as it seems next to useless. Please use it at least for reporting bugs in the open source components (https://maemo.org/bugzilla/describecomponents.cgi?product=haf) -- we are trying to use it. -- Tommi Komulainen[EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: 3.2007.10-7 - Detailed change log?
Daniel Stone wrote: You got it. The majority of the bug work happens before product release: going by what's in the changelogs, the external database has roughly 2% of the bugs as the internal one. That might well be because I (and others) have given up on using the external bug database as it seems next to useless. spaetz Hi, Do not give up on it just yet, it is changing for better. We have a real person behind [EMAIL PROTECTED] If not counting enhancement requests and reports on closed applications then almost all new bug reports get handled. What is still missing is a more sane structure in bugzilla and more active (or powerfull?) QA getting rid of enhancement requests and making sure bug reports meet basic standards (templates for new bug reports?). Br, --jakub ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
[EMAIL PROTECTED] wrote: Hi, Do not give up on it just yet, it is changing for better. We have a real person behind [EMAIL PROTECTED] If not counting enhancement requests and reports on closed applications then almost all new bug reports get handled. Jakke is quite active! :) What is still missing is a more sane structure in bugzilla and more active (or powerfull?) QA getting rid of enhancement requests and making sure bug reports meet basic standards (templates for new bug reports?). Regarding the basic standards, some bugs are indeed poor but there is often no request from Nokia for more detailed information until some months later by which time the bug is cold and the original reporter doesn't always respond. What would help is for Nokia to respond more quickly to new bugs, thus improving the chance of obtaining the missing bug information. A template may help, but you're always going to get poor bug reports in which case early dialogue with the bug reporter should elicit more information, not to mention educate. Br, --jakub ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: 3.2007.10-7 - Detailed change log?
Hi all, This sounds like something technically easy to do (for Nokia): 1) get all the internal bugs we have fixed 2) extract the referrences to public bugzilla 3) make sure all the public bugzilla bugs are marked as FIXED the same day we release the update And as a bonus lets list the public bugs in the changelog as fixed. This all should be done automatically, perhaps even for the 3.2007.10-7 so that we do not forget about it next time again. Br, --jakub On Behalf Of ext Neil MacLeod Would it be possible to provide a detailed change log for 3.2007.10-7, ideally cross-referenced with the public Bugzilla so that we (the users) known which of those bugs we have raised have been addressed? The published change log is extremely inadequate, unfortunately. Many thanks... ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
[EMAIL PROTECTED] wrote: Hi all, This sounds like something technically easy to do (for Nokia): 1) get all the internal bugs we have fixed 2) extract the referrences to public bugzilla 3) make sure all the public bugzilla bugs are marked as FIXED the same day we release the update And as a bonus lets list the public bugs in the changelog as fixed. This all should be done automatically, perhaps even for the 3.2007.10-7 so that we do not forget about it next time again. Hi Jakub That's exactly what I would hope for, and we can then VERIFY those bugs that have been FIXED (for example, bug 990[1] is supposed to have been fixed but is still present in 3.2007.10-7). Detailing internal bug fixes would be a bonus, simply because known problems don't always have a corresponding public bug, but I can appreciate this may be more difficult to extract and publish without incurring the wrath of management. Many thanks Neil 1. https://maemo.org/bugzilla/show_bug.cgi?id=990 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On 3/27/07, Neil MacLeod [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hi all, This sounds like something technically easy to do (for Nokia): 1) get all the internal bugs we have fixed 2) extract the referrences to public bugzilla 3) make sure all the public bugzilla bugs are marked as FIXED the same day we release the update And as a bonus lets list the public bugs in the changelog as fixed. This all should be done automatically, perhaps even for the 3.2007.10-7 so that we do not forget about it next time again. Hi Jakub That's exactly what I would hope for, and we can then VERIFY those bugs that have been FIXED (for example, bug 990[1] is supposed to have been fixed but is still present in 3.2007.10-7). Detailing internal bug fixes would be a bonus, simply because known problems don't always have a corresponding public bug, but I can appreciate this may be more difficult to extract and publish without incurring the wrath of management. I think the ideal situation would be if the public bugzilla was used by Nokia when fixing bugs submitted publicly and the internal bugzilla used when fixing bugs Nokia feels need to be hidden from public view for whatever reason. Actually, ideally the public bugzilla was the only bug listing, but I know some components can't be open sourced. However, I believe bugzilla allows access controls to particular bugs. I seem to remember the Mozilla foundation marking bugs as private such that only the title of the bug was publicly viewable as they pertained to major security holes. Perhaps down the road something like this could be done? Or maybe some sort of automated import/export between the public and private bugzilla? I assume the reason the public bugzilla doesn't seem to get updated is that the bugs are actually worked on using the internal bug tracker and it's inconvenient to put the same messages in the internal and external tracker. --Paul ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 3.2007.10-7 - Detailed change log?
On Tue, Mar 27, 2007 at 10:22:25AM -0500, ext Paul Klapperich wrote: I think the ideal situation would be if the public bugzilla was used by Nokia when fixing bugs submitted publicly and the internal bugzilla used when fixing bugs Nokia feels need to be hidden from public view for whatever reason. Actually, ideally the public bugzilla was the only bug listing, but I know some components can't be open sourced. However, I believe bugzilla allows access controls to particular bugs. I seem to remember the Mozilla foundation marking bugs as private such that only the title of the bug was publicly viewable as they pertained to major security holes. Perhaps down the road something like this could be done? Or maybe some sort of automated import/export between the public and private bugzilla? Products don't exist before announcement by definition, so it's very difficult to work in an environment where most every bug must be secret by default (anything pertaining to particular unannounced features). There's also the matter of managing what to report to: there would need to be some kind of permissions per-product or so. I assume the reason the public bugzilla doesn't seem to get updated is that the bugs are actually worked on using the internal bug tracker and it's inconvenient to put the same messages in the internal and external tracker. You got it. The majority of the bug work happens before product release: going by what's in the changelogs, the external database has roughly 2% of the bugs as the internal one. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
3.2007.10-7 - Detailed change log?
Would it be possible to provide a detailed change log for 3.2007.10-7, ideally cross-referenced with the public Bugzilla so that we (the users) known which of those bugs we have raised have been addressed? The published change log is extremely inadequate, unfortunately. Many thanks... ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: 3.2007.10-7 - Detailed change log?
Would it be possible to provide a detailed change log for 3.2007.10-7, ideally cross-referenced with the public Bugzilla so that we (the users) known which of those bugs we have raised have been addressed? Good question. I will try to answer officially as soon as possible. I mean, the answer depends not only on the will to publish more details but also on some improvements in the way we currently work. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
