+1 :) I think getting more issues tracked on GitHub will "tempt" other GitHub users to open issues there as well, and thus present rsyslog as being more open to suggestions, feedback, contributions, etc.
I say this from my experience as a GitHub user. If I see a project with <10 issues, I assume that it's either dead/hibernating or doesn't care for "external" input. Which may be completely wrong, I don't "set myself" on this first impression, but seeing issues there flowing is a sign of health for me and maybe for others, too. 2014/1/13 Rainer Gerhards <[email protected]> > 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). > > Looking forward to your reply. > Rainer > _______________________________________________ > 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.
