[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Lots of pkgdb mail on commits list

Hash: SHA1

Ville Skyttä wrote:
> Hello,
> Operations on the pkgdb appear to result in lots and lots of mail on the 
> commits list, one high level operation such as orphaning a package appears to 
> often spew around ten mails.
If you're getting ten messages then there's something wrong.  Orphaning
packages is currently generating one notification per branch[1]_....

> This makes following the commits list much harder than before.  Is reducing 
> the number of these messages being worked on (eg. grouping results of a 
> single high level operation into one mail instead of sending one for each 
> bit)?  I can of course add local filters to take care of it, but that's just 
> a band aid.
...but I definitely agree that there is too much mail being sent even if
it's only half that amount.

The question is what to do about it?

In the case of orphaning a package, for instance, there is no high level
 "orphaned package" operation anymore.  It's now owned and orphaned per
package-branch.  So achieving this is somewhat less than ideal.

Some options:
1) I can't see any reason for people to orphan/own/etc packages in EOL
collections.  Changing the interface to not show these by default needs
to be done at some point and discourages people from pressing "orphan
package" for that collection.  This will cut down the amount of mail
sent because people will be working with less collections.

2) Just don't send mail for EOL collections.  If someone makes a change
there, who cares?  This is somewhat a question of what we want commits
list to be.  Do we want it to record all changes to packages or just
changes that we feel we want to know about?

3) Have an asynchronous process that periodically reads the logs that
the packagedb is keeping and sends one mail per package (or package
branch) when a change occurred to that package since the last log scan.

4) Disable messages from the pkgdb to commits altogether.

#4 is easy.  #2 is somewhat easy.  #1 & #3 will take some time to implement.

#1 is something that should be done at some point anyway.

#3 seems like the right approach for the future.

Comments, other options?  I'm currently leaning towards implementing #2
short term (by end of week) and working on #3 and #1 on a broader time

- -Toshio

P.S.  Thanks to Ralf for suggesting #2

.. _[1]:
.. _[2]:

- -Toshio
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]