Mojca Miklavec wrote:
>> 1- Do you agree there is no need for (this many) notifications concerning >> changes to attachments (= you never missed it)? > > No. I have always been annoyed by the fact that some users (me > included) uploaded an attachment and then I had to tell everyone > explicitly that a new attachment was there, and some users (me > included) forgot. The only thing I've been mildly annoyed with is that you have to browse back to the ticket page and then post a new comment. Other bug tracker allow you to attach a comment to a new attachment with only some scrolling down the page required. > attachment, the submitter fixes the problems, but then nobody is aware > that those things have been changed. But you'll notice the next time you think of looking at it; I don't think there's really a problem here if it concerns something either of the parties considers important/urgent. >> 3- Do you agree that ideally this should be a per-user setting? > > This cannot hurt, but as you said this is not up to us to implement > and you should ask upstream. That was the idea - if there's enough demand. A random (from upstream perspective) trac user filing requests about features missing on some trac installation might well have adverse effects so I think we need to be careful with that. > The only "problem" with per-user setting is that: ... > ready to be committed" (or anything else). And then people might end > up with three notifications (attachment deleted, attachment added, the > additional comment by the user) or no notification at all. Well, you can't have everything, but I'd assume that if notifications are on by default, those users who bother to turn them off will know they'll have to monitor for silent changes themselves. Either way, I consider it bad practice to change an attachment (or add a new one) without a word of explanation except if it concerns only minor changes. Trac (also) doesn't have a diff feature for attachments, so without explanation you're leaving it up to your "audience" to figure out what just changed. So yes, I indeed get 3 emails most of the time when I change an attachment, 2 of which are to be trashed immediately. > PS: Isn't that question more suitable for the development mailing > list? Regular users that don't maintain any port might open a ticket Yes and no (I did consider cross-posting). I'd assume that most if not all developers are also on the users list. Of course the direction this discussion is taking has no place on the users list so I'm redirecting. But originally I wanted to reach the broadest audience to have the best chance to know what the entire community thinks. But above all, it's the people who open a ticket who are the most likely to be unhappy with the new set-up, because they really don't need all those notifications. It's been happening several times now that I made a number of changes to one of my tickets (that never drew much feedback) and moments later had a wow-moment when I saw the number of notifications in my inbox. That got old VERY quickly when I realised all those emails just confirmed things I knew I had done not even minutes before. The problem here is also that it seems risky to filter out these notifications automatically, but I haven't looked into that yet. Would prefer not to, of course. Maybe I would find attachment notifications less annoying for the tickets I'm following but didn't author. IOW, maybe trac could avoid sending the notification to the person making the attachment change. I'm rarely really interested in a copy of my own prose either, in fact. Either way, there is really no need for 2 notifications when you replace an attachment. In fact, I find that all the more irksome because each deletion notification is a reminder I can't *delete* attachments... Clemens wrote: > > Option 4: I'm glad we now have notifications for attachments. It used to be > quite annoying that you wouldn't notice if somebody attached a patch to a > ticket without leaving a comment. That's a no to question 1... > They are, however, not worded to avoid bias against the status quo. Of course they aren't. I'm not sure they could have been, but that's why I pointed out the fact. The ultimate goal was mostly to get people to reply who would otherwise have dismissed this as another one of my crazy ideas. >> (and I agree this isn't for us to fix though evidently someone could try and >> submit a patch). > > That someone could be you! That would be very welcome! I guess you know me well enough that if this were written in a language I knew and was set up to work with I'd already have done so before even opening a ticket. As it is someone would have to provide guidance, and that would probably cost more time than figuring out the patch. Not to open another can of worms, but just how married are we to trac? Of course it's never evident to migrate a web service, but has it never been considered to investigate other popular bug trackers (e.g. bugzilla) and possibly switch over by redirecting all new ticket requests to the new service? Github also has an issue tracker, for instance. I'm not familiar enough with its advanced features. I couldn't say if it does attachments, but it does have 1 rare feature I like very much: replying by email. R _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
