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
