Hmm. A valid point. How many of the other options have RSS feeds? I know that you can subscribe to an RSS feed for your Github news feed. As long as you are watching a repo you can see updates there.
-- James -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Lang Sent: Monday, January 13, 2014 1:33 PM To: rsyslog-users Subject: Re: [rsyslog] github issue tracker On Mon, 13 Jan 2014, Boylan, James wrote: > I agree with Rainer on this. If there are already issue > trackers/bugzilla instances in multiple places, then turning on issue > tracking within Github doesn't change anything except adding the > ability to added and track issues within Github as well as the other > locations. The issue I am concerned with is that if there are too many locations that have to be checked (and how many is too many??), some of them won't get checked and people will understanably get upset that they post something and get no response. For me personally, I live in e-mail. If I can get something to send me an e-mail notification, I'll respond to it pretty promptly. But if I have to point a browser at it and check it, I'm not going to do it as consistantly. I'm also not going to keep track of what I've handled in a web interface as well as I can track unhandled e-mails. a nntp news feed would be another good mechanism, but that's out of fashion today :-) the good news is that it's very possible to stup both nntp and e-mail and keep them synced :-) David Lang > -- James > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of David Lang > Sent: Monday, January 13, 2014 1:21 PM > To: rsyslog-users > Subject: Re: [rsyslog] github issue tracker > > On Mon, 13 Jan 2014, Rainer Gerhards wrote: > >> Hi all, >> >> next in the "post vacation meditation" group of messages ;) >> >> In december on this list, we had the discussion that github issue >> trackers could potentially benefit getting more contributions. At >> that time, I pointed out that we may run into troubles if we need to >> switch from github to some other platform in the future - plus some >> current contributors may not like the github system. >> >> On second and third thought, I realized that we already used and use >> a couple of differnent trackers, and all of these have entries in the >> change log. Among them are the old sourceforge.net trackers, Red Hat, >> Debian and SuSe bugzillas, the official Adiscon rsyslog bugzilla as >> well as the support forums. I also tend to link to other third-party >> sites if I fix something that's described there (even Google+, for example). >> >> In conclusion, we already have the problem that many of those URLs >> are not under our control and may go away without any chance to fix it. >> Github would be no exception from this rule. Actually, this never >> caused a problem (mabye because most of the URLS, even sf.net, still >> work ;)). The ChangeLog also always contains a base discription, so >> the information is present in any case. >> >> As such, I would actually be very interested to experiment with >> github issue trackers. As a first test, I have enabled issues in the >> newly created rsyslog-pkg-ubuntu repo. >> >> Please let me know if you think my new position on this topic is >> wrong. I like the lively discussions we have on this list and really >> value all those arguments. Let's try to make the best decision for >> our project. Just to be >> extra-clear: I would not disable the current bugzilla, but would >> enable github issues for the rsyslog main project in addition to that >> (the systems can be interlinked if required; we already do this with >> some of the other systems). > > If the tracker can generate notifications to some common feed (a mailing > list??) so that the maintainers can see them all, then it's Ok. > > If the maintainers have to go and login to each bugtracker each day to see if > there are any reports there, then I would oppose it. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This > is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our > control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE > WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites > beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
