On Thursday 17. January 2013 18.25.29 Oswald Buddenhagen wrote: > On Thu, Jan 17, 2013 at 04:05:40PM +0100, Oswald Buddenhagen wrote: > > two more approaches have been previously proposed: > hjk suggested yet another approach: use gerrit itself to collect the > changelog entries. after some thinking, i came up with this process: > - add a ChangeLog: line to the commit message as in the previous > proposal > - the commit-msg hook extracts and removes that line; the post-commit > hook re-adds that line via git-notes > - change is pushed as usual - with git-gpush (which gets extended to > push the notes as well) > - gerrit receives the commit and notes, creates a change, and attaches > the changelog entry as an additional attribute to it > - up to now, everything was an optional extension - to save the > contributor opening the gerrit page to add a changelog entry > - but of course, it would be possible to edit the changelog entry in the > gui > - the changelog entry would be approved together with the actual change. > whether this would happen in a separate review category, with the > stage/submit button, or something yet different, i don't know. > - the system would require explicit action to approve the lack of a > changelog entry > - for final storage, changelogs would be probably re-added as git > notes again > - automated entry collection at release time would follow as with > in-commit-message ChangeLog: entries > > the advantages of the system: > - there is no "media break" like with a wiki or jira, as we use git and > gerrit anyway > - the commit messages themselves are not "polluted" > - the changelog entries can be modified without amending and re-pushing > the commit, thus not invalidating the actual review > - it would be also possible to let the reviewers write the changelog > entry (which would then have to be approved by the contributor or > another reviewer in turn) > - we could seamlessly switch from the in-commit-message ChangeLog: > variant, as nothing would change in the manual steps at commit > creation time (provided the notes-for-submission stuff would be > implemented right away) > the downside is rather obvious: > - this needs to be implemented in gerrit (unless somebody already did > something similar) > > this is just a "step 2". it is in so far relevant, as the possibility of > adding this later may be considered an endorsement for the original > ChangeLog: variant. > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development
I like the approach, I'm just afraid that nobody will work on patching gerrit. It means that in real live we will end-up with the original ChangeLog variant. It seems that it is the best solution anyway. Cheers, Jędrek _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
