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
