From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing
Date: Wed, 30 Jan 2013 15:27:15 -0500 (EST) [thread overview]
Message-ID: <alpine.DEB.2.02.1301301520430.3650@oneiric> (raw)
In-Reply-To: <20130129112406.GK16904@jama.palm1.palmone.com>
On Tue, 29 Jan 2013, Martin Jansa wrote:
... snip ...
> It would be better to change SRCREV to hash corresponding to that
> tag and move tag only to comment above SRCREV. Such patch could be
> applied in upstream...
which brings up a larger issue ... what is the *preferred* way of
doing this if one was writing a style guide? i understand developers
might like to set git SRCREV variables to meaningful tag names but, as
i've learned, that really screws up the possibility of building with
no network. as it is, quite a few recipes set SRCREV to a hash ID for
*precisely* that reason and, in a short comment above (as you say),
mention the tag it corresponds to.
which brings me to what caused this annoyance in the first place --
the meta-ti layer, which has only four recipes that use
SRCREV = <tag name>
so it wouldn't be that hard to submit a patch to adjust those, but
then there's this in
meta-ti/recipes-kernel/linux/linux-keystone_3.6.6.bb:
# The tree tends to rebase, use literal stable tags
SRCREV = "DEV.MCSDK-03.06.06.07"
uh ... correct me if i'm wrong but isn't it in unspeakably bad taste
to rebase commits that have already been published?
in any event, can it be considered bad form to set SRCREV to git tag
names? thoughts?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
next prev parent reply other threads:[~2013-01-30 20:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 9:08 BB_NO_NETWORK = "1" causes fetch to fail for unnecessary u-boot parsing Robert P. J. Day
2013-01-29 9:44 ` Martin Jansa
2013-01-29 9:54 ` Robert P. J. Day
2013-01-29 11:24 ` Martin Jansa
2013-01-30 20:27 ` Robert P. J. Day [this message]
2013-01-30 20:34 ` Chris Larson
2013-01-30 20:34 ` Chris Larson
2013-01-30 20:49 ` Harvey Chapman
2013-01-30 20:53 ` Robert P. J. Day
2013-01-30 20:57 ` Chris Larson
2013-01-30 20:37 ` Robert P. J. Day
2013-01-30 20:44 ` Chris Larson
2013-01-30 21:31 ` Robert P. J. Day
2013-01-30 21:03 ` Martin Jansa
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=alpine.DEB.2.02.1301301520430.3650@oneiric \
--to=rpjday@crashcourse.ca \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/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