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. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
