Bug#756954: subscription by uploaders
Hello,
على ٧/٧/١٤٤٠ هـ ٥:٢٢ م، كتب Raphael Hertzog:
> Hello Afif,
>
> sorry for the delay.
I read your reply before and put it aside for later, but reading it
again now, I have a comment--
>
> On Sun, 03 Feb 2019, Afif Elghraoui wrote:
>> The way I was hoping this could work is that Uploaders are automatically
>> subscribed. I don't know of any reason why an Uploader should not be
>> following their packages. I think it would also motivate people who
>> really don't co-maintain a package to get themelves removed from the
>> Uploaders list, thereby correcting the package metadata.
>
> Uploaders should be following their packages but they might already be
> following their packages in some other way: through a (tracker-)team
> subscription. Or through a mailing list that is referenced in the
> Maintainer field.
>
Yes, but this would be addressed by the mechanism you described in the
requirement below [1]
> So maintainers should be able to opt-out from this automatic subscription
> or at least blacklist some packages (so that a manual unsubscription is
> not followed by an automatic subscription because of the Uploaders field).
>
One of the main points of this feature as I see it is that it helps to
keep the Uploaders field accurate. If co-maintainers want to completely
unsubscribe, why shouldn't they achieve this by just removing themselves
from Uploaders altogether?
>> I think this would also be simpler to implement than subscription
>> keywords in d/control (as mentioned in the OP). If it's still too far
>> out of you way, I'd be willing to implement a patch, but would
>> appreciate a tip about where to look in the code-base. I looked around
>> it and couldn't find a good starting point in the file hierarchy.
>
> I believe this feature is important and it would be nice to have it
> working in the not too distant future but I'm unfortunately not actively
> working on the tracker lately (just look at how much time it took me to
> respond to your mail!).
>
> A good start would be to modify the database so that we can record the
> origin of each subscription. I imagine it would be a simple text value
> associated to the subscription: "manual:web" or "manual:email" for a
> manual subscription from the web interface or from the email interface. Or
> "auto:uploaders" for this new feature.
>
> You will have to modify the Subscription model in
> distro_tracker/core/models.py and you probably want to create a new
> task in distro_tracker/core/retrieve_data.py (or modify an existing one?)
> to create/delete the subscriptions as appropriate.
>
> You will have to review the places where the subscriptions are created
> and add the required origin value.
>
> The task should be smart enough to detect when the given email already
> gets the package notifications through a tracker team or through a pre-existing
> (manual) subscription or through an alternate email associated to the same
> user.
1. ^ here
Thanks for the tips! Not sure when I'll get to it, but it'll probably be
before I package anything golang-* because I really do not want to
subscribe to the Go team mailing list nor manage my PTS subscriptions
manually.
Thanks and regards
Afif
--
Afif Elghraoui | عفيف الغراوي
https://afif.ghraoui.name
Reply to: