* Betr.: " Bug#687632: pre-approve unblock: tryton-modules-calendar-classification/2.2.1-1" (Sat, 15 Sep 2012 11:07:32 +0100): > On Sat, 2012-09-15 at 10:05 +0200, Mathias Behrle wrote: > > > On 14.09.2012 13:01, Mathias Behrle wrote: > > > > * Convert buffer into string for vobject > > > > > > That's really not a particular helpful description for deciding whether > > > the upload is appropriate for an unblock; upstream's changelog of "* Bug > > > fixes (see mercurial logs for details)" doesn't provide much elucidation > > > either. > [...] > > This issue is caused by the migration of the binary field format to buffer > > [1]. Writing and reading from the DB affords the conversion from buffer to > > string. > > > > Would it be adequate to post for each package the link to the mercurial > > repository? The standard commit messages are linked to the reviews [1] > > and/or issue numbers in the bug tracker of tryton.org to provide easy > > tracking information. For this package the link can be found at [2]. > [...] > > [1] http://codereview.tryton.org/426003/diff/1/calendar_.py > > [2] http://hg.tryton.org/2.2/modules/calendar_classification > > Thanks for the links. It's possible I'm missing something, but from an > initial look they don't actually provide any further information on the > change. :-( [1] contains the one line diff which was already attached > to your mail. From there one can reach > http://codereview.tryton.org/426003/ , although the only information > there other than the diff is a "message" from the committer, which > appears to be entirely empty. > > [2] leads to > http://hg.tryton.org/2.2/modules/calendar_classification/rev/efc13781a75e , > which points to a commit from which the change was copied. That in turn is > http://hg.tryton.org/modules/calendar_classification/rev/74d42794032d , which > is simply exactly the same change on another branch with no comment / > discussion there either. > > I appreciate that from the perspective of someone who knows the code, > it's probably obvious why the change was required, but a one line of > something similar to "the field in the database is a string; we need to > cast as a result of moving to using a buffer in commit ABCDEF" would be > beneficial to those of us who don't. (I've possibly got the reasoning > wrong there, it was based on your comment above linking to [1].) I agree, that the commit messages on upstream were far from optimal and still are subject to be improved. It's a long way... Indeed the original change for all kind of buffer/string migrations was the move from base64 encoding to buffer for binary fields in the server: http://hg.tryton.org/trytond/rev/8d2762bb1aa4?revcount=160 It was one of those moves causing a lot more side effects than was assumed at first glance, hence those bug fixes still necessary after 12 months of the first commit to trunk. > > What I did already per package is to summarize those commit messages > > as provided in the mercurial logs. Could you please just mark the > > messages, where you need more detailed information? > > I'll have a go when I've got a little more free time to try and attack > them as a set. There are quite a lot of them to go through though (and > I notice some more this morning). :-( Thanks a lot for looking into it. I assumed it would be best to have them complete, because some fixes in different packages relate to the same origin (like the buffer issue). NB: I am aware, that there were changes in COPYRIGHT years. It is understood, that I will adapt debian/copyright before uploading, so no need to mark them. Regards, Mathias
Attachment:
signature.asc
Description: PGP signature