On Sat, Feb 28, 2009 at 10:46:10AM -0600, Andy Lester wrote: > > On Feb 28, 2009, at 10:29 AM, Patrick R. Michaud wrote: > >> So, for the time being Rakudo's official policy will be to >> accept patch submissions via RT. I've now cleared the fork queue >> on GitHub; any patches that were previously there need to be >> resubmitted. > > My understanding is that this is bad for everyone else, because it loses > the changeset history by making your committed patch different than the > accumulated changesets that you're applying.
I suspect that "everyone else" should be making their changes in personal branches as well, rather than expecting the rakudo/master repository to exactly follow the commits in their forks. > I suspect there's a way of working the workflow that lets you easily > view them in aggregate. Perhaps the RT ticket would include not a patch > but the commit IDs that the patch would include. The submitter says > <<END_OF_RT > > "Hey, Patrick, I finished the work on the wangdoodle. Here are the > commits for it: > > 88b9da2ce43c4e8583cda28ace5144e0a618d70b > 4a03ba2fe2e94895881d301de0446158424e7c1d > 9e8c18ff0093125830a4bd06a3daee2e20cd8faa > 0240f7776a9a01443567dfeaa98bba91b734affd > END_OF_RT This approach goes totally the wrong way -- the submitter has to somehow produce a (long) list of commits, which the maintainer then has to manually replay in the review and test. > I'm sorry this is poorly researched. I'm heading out for the day, or > I'd have spent more time on it. I'm just concerned that using patches > is very anti-git and will make things worse. I agree we probably need more research here to potentially use git/github more effectively, but what little I understand of the fork queue absolutely doesn't work for me as a maintainer, and turns the maintainers into a bottleneck. The "send a patch via RT" approach is well understood, and has worked fine for us for years. So, we either somehow improve our understanding of git patch management (and believe me, I've unsuccessfully looked for guides on "fork queue management for maintainers"), or we stick with RT. Pm
