Re: How to best reach the users of a package?
Frans Pop <elendil@planet.nl> writes:
> On Saturday 05 August 2006 21:20, martin f krafft wrote:
>> I envision a tool (warning: braindump ahead) that we install *by
>> default* on a standard system, which uses cron to wake up once a day
>
> I think that installing it by default is not really an option. As all
> Debian services, it should be opt-in, not installed by default.
>
> Giving it the same status as popcon would IMO be an option. In effect that
> means: we ask the user during installation of any new system if he would
> like to use the service. If he/she declines, well, that's his/her choice.
You can do both. Ask and default to yes. I think such a service is
even more important than popcon.
>> and check online for important announcements regarding all installed
>> packages, and mails them to root if any are found. I was thinking
>> first to use the BTS for that, but we don't want that. The PTS also
>> does not provide what we need for this, so it'd be another service,
>> possibly one actually using the mirrors for distribution. And we'd
>> need a policy/moderation so as to prevent spamming the users.
>
> I like the basic idea of the service. Consider the comments below a
> braindump as well.
>
> It should also support important upgrade announcements (probably both per
> arch and per package or even arch/package combinations) before a new
> release.
> This means that the service also needs to support codename/suite.
>
> How will the service determine if a package related message is relevant
> for a user? Single version, version ranges, codename/suite, all?
>
> The service should also support systems that do not have a permanent
> internet connection.
>
> Maybe it should also support corporate installations where not each
> individual system is "subscribed", but rather a sysadmin subscribes to
> the architectures/suites that are relevant for his organization, maybe
> with a blanket selection for any announcement relating to any base system
> package + selected other packages.
>
> Cheers,
> FJP
Here is some more brain dump:
How about using ldap for this? Or some other database service.
Message infos are filed into the DB with a min/max codename/suite they
apply to, a min/max version, the package(s) affected, a date, a
type/priority and maybe some other values and an ID for the message
item themself. Small enough that downloading does not overly strain
the bandwith.
Clients can then request all message infos (since date of last query)
from the db, filter them according to installed packages, versions,
codename/suite, user preferences and download the message items left
after filtering.
There should be a direct viewer for users that aren't always online
and a mailer that can be run as daemon/cron job.
I would also like it if every uploads add the changelog entry and
Debian.News file to the service automaticaly. The type for a changelog
should include the urgency of the upload as that should reflect how
important the change is.
MfG
Goswin
Reply to: