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
