Greg Smith wrote:
> I tend not to think in terms of solutions that involve web applications
> because I never build them, but this seems like a useful approach to
> consider. Given that the list of tags is pretty static, I could see a
> table with a line for each commit, and a series of check boxes in
> columns for each tag next to it. Then you just click on each of the
> tags that apply to that line.
>
> Once that was done, increasing the amount of smarts that go into
> pre-populating which boxes are already filled in could then happen, with
> "docs only" being the easiest one to spot. A really smart
> implementation here might even eventually make a good guess for "bug
> fix" too, based on whether a bunch of similar commits happened to other
> branches around the same time. Everyone is getting better lately at
> noting the original SHA1 when fixing a mistake too, so being able to
> identify "repair" seems likely when that's observed.
>
> This approach would pull the work from being at commit time, but it
> would still be easier to do incrementally and to distribute the work
> around than what's feasible right now. Release note prep takes critical
> project contributors a non-trivial amount of time, this would let anyone
> who felt like tagging things for an hour help with the early stages of
> that. And it would provide a functional source for the metadata I've
> been searching for too, to drive all this derived data about sponsors etc.
We could have the items put into release note categories and have a
button that marks incompatibilties.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
