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 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
