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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
