[maemo-developers] maemo.org/downloads automatic updates from Extras

From: Niels Breet niels at maemo.org
Date: Thu Jul 10 17:51:33 EEST 2008
> On Mon, Jul 7, 2008 at 10:09 PM, Tim Teulings <rael at edge.ping.de> wrote:
>
>>
>>> One enhancement I would like to add is automatically update the
>>> 'Changes
>>> in latest version' field for the entry in downloads. I would like
>>> comments
>>
>> That would be nice :-)
>>
>
> Agreed.
Great!
>
>> The debian package changelog describes changed to the package made by
>> the package maintainer. If maintainer and developer are different a
>> changelog entry for a major relase could just contain "New upstream
>> version" - which would not be that helpful :-/
>
> Agreed.
>
>
>> So we can try it with these files and either put preasure on upstream
>> or let the package maintainer fix/create these files or we can define a
>> special maemo-specific file Maemo.ChangeLog that contains both
>> information in a simple to parse, extendable file format (XML?). And to
>>  make everybody happy we try a fallback for ChangeLog and changelog if
>> Maemo.Changelog does not exist - with improving magic over time.
>>
>
> Personally, I'd rather downloads.maemo.org used one fixed system and
> it was up to tools like mud to pull out heuristically derived data from
> upstream and coalesce it into the simple format.
>
I would agree about that. Let's try to find one common way to provide
change information. We can put the data extraction in mud-builder and/or
the assistant too.

>> Simple XML file could look like:
>>
>>
>> <maemo-release-changelog>
>> <revision release-date="2008-07-07 23:05:00" revision="<package
>> revision>"> <description>
>> Packages new upstream version.
>> </description>
>> </revision>
>>
>>
>> <release release-date="2008-07-01 11:55:00" version="<source package
>> version>"> <description>
>> Now plays funny sound on start.
>> </description>
>> </release>
>> </maemo-release-changelog>
>>
>>
>> However many other formats with same or similar content are possible...
>>
>
> Indeed. TBH, I wonder whether another header would be sufficient in
> debian/control? We've already got XB-Maemo-Icon, adding XBS-Version-Changes
> or something could be sufficient. Is there any need for anything other
> than the last modification?
>
> Certainly for downloads.maemo.org; for more detail the
> debian/changelog is available and /should/ be the definitive location so we
> don't diverge too much from other Debian-based systems. (Your points about
> a potential ownership mismatch between an upstream debian/changelog and
> the Maemo package's are, of course, entirely valid and correct).
>

I think that only changes since the last version are interesting to
display on d.m.o. We could additionally add a link to the package's
changelog.

>>> Another option would be to let the developer enter this data while
>>> promoting the package to extras. We could add this step to the
>>> promotion interface.
>>
>> IMHO a bad idea. I personally want to have the process as automatic as
>> possible (OK testing is still manual :-/). This way I can choose time and
>> place and tool and process and I'm not forced to use the web page (must
>> switch to dput soon :-)).
>
> Agreed. dput (or, well, scp) *must* be a supported option (well, I
> want to streamline it's use through mud[1] so not having it would mean
> screen scraping/web robots, which is fairly distasteful ;-))

I don't think doing away with dput or scp is on the roadmap ;)

> Perhaps, however, if the package doesn't contain XBS-Version-Changes,
> the web form could prompt for it.

That can certainly be done.

I have added all comments to a page[2] on the wiki, perhaps we can discuss
this more and see if we can find a good solution.

> Cheers,
>
>
> Andrew
>
--
Niels Breet
maemo.org webmaster


> [1] http://wiki.maemo.org/User:Jaffa/mud_design
[2] https://wiki.maemo.org/Providing_changes_since_last_version_of_a_package



More information about the maemo-developers mailing list