public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile
Date: Tue, 21 Oct 2008 16:59:07 +0200	[thread overview]
Message-ID: <20081021145907.10097835694E@gemini.denx.de> (raw)
In-Reply-To: <1224600029.18428.339.camel@localhost.localdomain>

Dear Peter Tyser,

In message <1224600029.18428.339.camel@localhost.localdomain> you wrote:
> 
> > Actually the time stamp is completely useless in determining  if  the
> > code is the same or different. I can compile the same code many times
> > resulting  in  different time stamps and yet it's the very same code.
> 
> The code won't be the same - the version string will be different and
> the different binaries would have different md5sums.

The *code* will be exactly the same. The binary images may differ in
some strings, but the code is still the same.

But actually you just confirmed my argumnt.

> > U-Boot 2008.10-rc2-00018-g8fd4166-dirty (Sep 30 2008 - 13:42:17)
> > 
> > This clearly tells you which version the code was based on (and  that
> > it contains local modifications that were not yet checked in).
> 
> Which local modifications though?  Until I make another commit every
> version string will be the same.

Indeed. Which tells you that it is a bad idea to ship any binaries
with uncommitted modifications in your tree.

Hey, we can only provide the best environment for a sane  development
process. If you don't play by the rules you are then not exactly in a
good  position  to complain. Talk to your QA manager, if you doubt my
words ;-)

> > Timestamps are not suitable to provide this type of  information.  If
> > you care about which code you are running, than make sure to use git.
> 
> I do, but the minor annoyance of having the exact same version
> string/time stamp for different code still exists for uncommited
> changes.

You must be doing something awfully wrong when  you  have  uncommited
changes in any form of software you're releasing.

> I use git, but its version strings only change when commits occur.  I

Thisis intentional - commits are the only way  to  change  the  code.
Anything  between  commits is work in progress which you never should
release to anybody, not even your bst friends.

> I know this patch isn't a big deal, but I think it would be a valuable
> change.  If others don't agree I'll drop the issue.

We take great care to generate a useful version ID string that really
gets updated as soon as one of the files changes. The fact that we
apend the __DATE__ and  __TIME__ output to the boot messages is just
for informational purposes (and a relict from earlier times, when git
did not exist yet).1s

Note that there are more than 40 places in the  code  where  __DATE__
and/or __TIME__ get used, in different ways. If you want to put more
meaning into these strings than we have now, you will have to address
all these use cases.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Being schizophrenic is better than living alone.

  parent reply	other threads:[~2008-10-21 14:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-17 22:51 [U-Boot] [PATCH][RFC] Update U-Boot's build timestamp on every compile Peter Tyser
2008-10-17 22:55 ` Peter Tyser
2008-10-21  0:59 ` Kim Phillips
2008-10-21  2:02   ` Peter Tyser
2008-10-21  7:04     ` Wolfgang Denk
2008-10-21 14:40       ` Peter Tyser
2008-10-21 14:51         ` Jerry Van Baren
2008-10-21 15:02           ` Wolfgang Denk
2008-10-21 15:17             ` Peter Tyser
2008-10-21 14:57         ` Stefan Roese
2008-10-21 15:04           ` Wolfgang Denk
2008-10-21 14:59         ` Wolfgang Denk [this message]
2008-10-21 18:52           ` Andy Fleming
2008-10-21 19:03             ` Peter Tyser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081021145907.10097835694E@gemini.denx.de \
    --to=wd@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox