[FFmpeg-cvslog] r14363 - in trunk/libavcodec: ra288.c ra288.h

[Uoti Urpala]

On Fri, 2008-07-25 at 02:06 +0200, Michael Niedermayer wrote:
> On Fri, Jul 25, 2008 at 12:50:33AM +0300, Uoti Urpala wrote:
> > On Thu, 2008-07-24 at 22:39 +0200, Michael Niedermayer wrote:
> > > On Thu, Jul 24, 2008 at 08:16:31PM +0300, Uoti Urpala wrote:
> > > > [FFmpeg-cvslog] r14265 - Rearrange AV_[RW][BL]*() macros
> > > > [FFmpeg-cvslog] r14275 - intreadwrite: support DEC compiler __unaligned type qualifier
> > 
> > > I suggest:
> > > 14265 u/intreadwrite.h - Rearrange AV_[RW][BL]*() macros
> > > 14275 u/intreadwrite.h - support DEC compiler __unaligned type qualifier
> > > 
> > > Mine needs 14 chars less
> > 
> > It's misleading to mix dropping the list prefix with other changes in
> > one length comparison. Whether to use the prefix is an independent
> > issue.
> 
> Its not independent, if we want commit messages and filenames in the subj,
> it makes sense to drop the prefix, it might not make sense otherwise.

Maybe that gives extra motivation to drop the prefix, but it's still
misleading to count the prefix when comparing the lengths of proposed
subject formats. It makes no sense to say "this is shorter *if I remove
the prefix*", as the prefix can be equally removed from any format.

> > >  and displays both the filename and the commit msg
> > > and if the space for the filename is not enough for a list of names a + can
> > > be added at the end to indicate there are more.
> > 
> > What would "the space for the filename"[s] be? There is no amount of
> > space you could safely use for them at the start of the subject without
> > increasing the likelihood that (more from) the end of the log message is
> > hidden. 
> 
> What is it that you are trying to say? 
> That a commit message could have any arbitrary finite length and thus
> n-1 could always be too small while n would be enough?

The first line of the commit message alone can take all the space
available for a mail subject in a reasonably set up MUA. There is no
"free" amount of text that you could safely use for filenames before the
message without hiding more important information.

>  And that because
> of that the commit message must always be shown alone?

The most important information should come first. If filenames are the
best way to do that then the commit message should start with them; if
they're not then the script should not force them to be added before
more relevant information.

> come on, with that reasoning we may not display anything else on the whole
> screen than a single commit message.

That makes no sense even as an exaggeration when talking about mail
subject lines (you can select the contents of the subject but you cannot
force displaying it or other things in a particular way). The log
message is supposed to start with the most important information about
the commit so that's what should be shown at the start of the mail
subject.

> > > but 2 filenames should easily have space in there, and with more the commit
> > > message should probably clarify what part is being changed anyway.
> > 
> > 2 filenames can already use a significant portion of the space for
> > commit-specific information (revision number and possible list prefix
> > already take some space from the subject field). What do you even
> > concretely propose? That the script show the first 2 filenames? No
> > filenames at all if >= 3 files are changed? With no regard to the length
> > of those names?
> 
> My suggestion would be a variable size field for the revission number,
> a fixed size field (in chars) that is used for
> filenames,

How big a fixed size field? If you want a big enough field to hold two
different filenames that and the revision number already use up a
significant amount of space and either the first line of the commit
message would need to be very short or you'd need to have a lot of space
for the subject in your MUA.

>  we currently have a (totally useless) list prefix that noone
> ever complained about that can easily be removed. The rest of the subject

It's mainly useful if you don't automatically sort mailing list mails to
subfolders (or do it according to the prefix, but I think fixing that
shouldn't be too hard for anyone). I'm not sure if anyone reads them
without automatic sorting.

> directories can easily be abbreviated to f/ c/ u/ for lavf/lavc/lavu
> If the filename field is too short for all a + is placed at its end.
> We might also use abbreviations like intreadwrite.c/h if that can be
> implemented easily.

I think it'd take less effort for people to use such abbreviations in
log messages when it makes sense than trying to automate their
generation...