Hey Amos and Alex, (Writing freely)
It's pretty simple to understand that there are two sides to the same picture so it's possible that there are multiple scenarios. To my understanding opening GitHub issues is not an explicit move that states any migration from https://bugs.squid-cache.org/ towards any other option. I want to believe that developers and sysadmins are smart enough to understand a declaration on the GitHub issues template. (Assuming they will read the text..) In general opening an issue is nice and will probably help to work with PR's but the main question is: Will it bring more then there is today? However, there is another issue. The development team will need to be watch another vector in the development cycle and I believe that it's already not a simple task as it is. It's better to think about any way to address both the technical and the administrative overhead that I might suspect it will leave the development team with before the full adoption. I believe that for now restricting the issues with an experimental statement would be enough. If Amos feels fine with handling all the issues related syn/syn-ack/ack of any issue being opened by himself I believe it will not harm anyone. HTH, Eliezer -----Original Message----- From: squid-dev <squid-dev-boun...@lists.squid-cache.org> On Behalf Of Alex Rousskov Sent: Friday, May 5, 2023 6:51 PM To: squid-dev@lists.squid-cache.org Subject: Re: [squid-dev] RFC: GitHub Projects and Issues On 5/5/23 09:39, Amos Jeffries wrote: > You may (or not) have noticed that recently I have been experimenting > with GitHub Projects. > Creating a few for the major long-term efforts and assigned a number of > the open PRs to them. > > IMO this looks like it could be a better way to track progress on > incomplete features or code conversions instead of wiki Feature pages. I am against using GitHub Projects for projects that lack Squid Project consensus. Just like Feature pages, GitHub Projects currently create a false impression that the Squid Project has agreed that some activity is a good idea, that some details of that activity have been reviewed and approved by the Squid Project, and/or that some GitHub PRs match that good idea. I wish you have not started using GitHub Projects before discussing that shared Squid Project resource use. Please pause that experiment. > That limitation might be resolved by enabling GitHub Issues for (only) > feature-enhancement TODO items prior to PR creation. Enabling GitHub Issues and then rejecting "regular" bug reports submitted via GitHub Issues is bad UX. IMO, we should either enable GitHub Issues for regular bug reports and other issues that folks expect to file via GitHub Issues (and deprecate Bugzilla) or not enable them at all. HTH, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
