[squid-dev] [RFC] Disable Github issue tracker

[Alex Rousskov]

On 07/19/2017 06:31 AM, Amos Jeffries wrote:
> On 19/07/17 16:41, Alex Rousskov wrote:
>> On 07/18/2017 09:26 PM, Amos Jeffries wrote:
>>> There are maintainer workflow scripts still todo, but before going to
>>> the trouble I'm considering whether that workflow still makes any sense
>>> - it was designed for CVS, and adapted to bzr in absence of good bzr
>>> tooling. If anyone knows of some good branch management tools for git
>>> I'm interested.

>> I wish I could help, but I do not really know what the old tools did,
>> and do not have enough git expertise to advice on such general topics as
>> "good branch management tools for git". If nobody answers here, consider
>> enumerating the primary needs in general terms. Such a list would make
>> it easier to solicit external advice.

> I was hoping "branch management" might bring up things I'm not
> aware of myself.

Wrong audience, I suppose.


> The tools I have right now are a bunch of scripts that maintain a
> todo-list for each release series, a per-release patch list, and running
> statistics about the quantities of code change.
>  * For each revision/patch in any branch I can mark it as a feature and

>  * For each revision/patch I can see whether it has been cherrypicked
> into an older series (and to what revision in that destination branch),
> and if it is a backport the revision/patch ID in the branch where it
> originated.

If you prefer, the above can be done using PR labels. For example, some
projects use a pair of labels for each backporting target X:

* X-nominated -- somebody wants this PR ported to X; it is not in X
* X-accepted -- maintainer supports the nomination

The four combinations of the above two labels reflect all possible
states of the PR with regard to porting to version X (e.g., a lonely
X-accepted means the PR was ported). Github search can be used to find
PRs to backport.

If you need to remember which non-nominated PRs should not be nominated,
you need another label to mark those (e.g., maintainer-processed).


> group other revisions/patches as delayed fixes to the primary commit.

This important requirement cannot be supported using PR labels. If you
prefer, you can maintain a (specially formatted) Github comment in a
merged PR that accumulates delayed fixes. This will place all
information about the PR in one place.

Needless to say, it is possible to automatically find to-be-ported PRs
and form changesets. Github has an API for querying PRs.


I have no idea whether the above Github hacks are overall better than
what you already have and whether there are better hacks/tooling I do
not know about.

Alex.