[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#687632: pre-approve unblock: tryton-modules-calendar-classification/2.2.1-1

* Betr.: " Bug#687632: pre-approve unblock:
  tryton-modules-calendar-classification/2.2.1-1" (Sat, 15 Sep 2012 11:07:32

> 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:

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).

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.


Attachment: signature.asc
Description: PGP signature

Reply to: