All of lore.kernel.org
 help / color / mirror / Atom feed
* objections to replacing git SRCREV tag names with actual hash IDs?
@ 2013-01-31 11:58 Robert P. J. Day
  2013-02-05  5:05 ` Denys Dmytriyenko
  0 siblings, 1 reply; 3+ messages in thread
From: Robert P. J. Day @ 2013-01-31 11:58 UTC (permalink / raw)
  To: meta-ti mailing list


  surely, some of you saw this discussion on the oe-core list last
night, but would there be any objection to replacing the small number
of git SRCREV settings of tag names with their actual hash IDs?  the
motivation should be obvious -- avoid network traffic to parse those
tag names, even when that recipe isn't even being used in the image
being built.

  here's the entire list of SRCREV assignments in all of meta-ti, so
you can see there are only four related to git tag names:

recipes-bsp/boot-monitor/boot-monitor_git.bb:SRCREV = "DEV.MCSDK-03.00.00.07"
recipes-bsp/u-boot/u-boot_2011.09.bb:SRCREV = "fdbe8b9a2d1858ba35dd6214315563ad44d4a0e3"
recipes-bsp/u-boot/u-boot_2011.10rc.bb:SRCREV = "dc52533ccff00a12761f793d66b39e4f6a4a3bba"
recipes-bsp/u-boot/u-boot_2011.09-psp04.06.00.08.bb:SRCREV = "1e4626f0d5f3bb04ec974e76a5d9029875269d31"
recipes-bsp/u-boot/u-boot_2011.06.bb:SRCREV = "b1af6f532e0d348b153d5c148369229d24af361a"
recipes-bsp/u-boot/u-boot_2011.12.bb:SRCREV = "cba9a894fdb1cb49b60fcd1d1d6919cbd7995dd5"
recipes-bsp/u-boot/u-boot_2013.01.bb:SRCREV = "DEV.MCSDK-03.00.00.07"
recipes-bsp/ti/am33x-cm3_git.bb:SRCREV = "cf07b841d6e8c5e026eecb259d143f3dff412c8e"
recipes-bsp/ti/am-sysinfo_svn.bb:SRCREV = "5"
recipes-connectivity/uim/uim_git.bb:SRCREV = "c73894456df5def97111cb33d2106b684b8b7959"
recipes-graphics/omapfbplay/omapfbplay.inc:SRCREV = "34293052c5a2ae328eac6903512e6b4ce19b5639"
recipes-kernel/linux/linux-omap_2.6.37.bb:SRCREV = "fa3b4e23ec20cfc944db7cc2b30b0d82c20e4472"
recipes-kernel/linux/linux-ti33x-psp_3.1.bb:SRCREV = "1d84d8853fa30cf3db2571a5aec572accca4e29d"
recipes-kernel/linux/linux-ti81xx-psp_2.6.37.bb:SRCREV = "745a06cb913ad7a9ab44855aa36d8c012cd5793b"
recipes-kernel/linux/linux-am335x_3.2.0-psp04.06.00.08.bb:SRCREV = "d7e124e8074cccf9958290e773c88a4b2b36412b"
recipes-kernel/linux/linux-omapl138-psp_2.6.37.bb:SRCREV = "v2.6.37_DAVINCIPSP_03.21.00.04"
recipes-kernel/linux/linux-keystone_3.6.6.bb:SRCREV = "DEV.MCSDK-03.06.06.07"
recipes-kernel/linux/linux-omap4_3.4.bb:SRCREV = "c34a43ec74168b892a948b45695486f1a3d700af"
recipes-kernel/linux/linux-omap-psp_2.6.32.bb:SRCREV = "5fc29e7b2a76a64a739f857858ef0b98294aa155"
recipes-kernel/linux/linux-ti33x-psp_3.2.bb:SRCREV = "720e07b4c1f687b61b147b31c698cb6816d72f01"
recipes-kernel/linux/linux-omap4_3.1.0.bb:SRCREV = "a5c60c099296fcfc0c8fa8085c40883971486512"
recipes-misc/payload/beaglebone-getting-started.bb:SRCREV = "6c548a307c948b28a99d48fd17d9790b56182196"
recipes-ti/beagleboard/beaglebone-tester.bb:SRCREV = "487a13e2e4faaafa40ba5430600e6aeecf9581a8"
recipes-ti/gstreamer-ti/gstreamer-ti_svn.bb:SRCREV = "962"
recipes-ti/codec-engine/ti-codecs-omap3530_4.00.00.00.bb:SRCREV = "8393c892b09e0ac42b19ff1531e232478c3b1a6c"

  i'm currently spending some time at a site that doesn't allow git
access so those tag names are fatal for doing any sort of OE building.
and only one of those appears to *prefer* to use the tag name --

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"

  but, really, you shouldn't be rebasing published commits, anyway.
so ... thoughts?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: objections to replacing git SRCREV tag names with actual hash IDs?
  2013-01-31 11:58 objections to replacing git SRCREV tag names with actual hash IDs? Robert P. J. Day
@ 2013-02-05  5:05 ` Denys Dmytriyenko
  2013-02-05  9:27   ` Robert P. J. Day
  0 siblings, 1 reply; 3+ messages in thread
From: Denys Dmytriyenko @ 2013-02-05  5:05 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: meta-ti mailing list

On Thu, Jan 31, 2013 at 06:58:37AM -0500, Robert P. J. Day wrote:
> 
>   surely, some of you saw this discussion on the oe-core list last
> night, but would there be any objection to replacing the small number
> of git SRCREV settings of tag names with their actual hash IDs?  the
> motivation should be obvious -- avoid network traffic to parse those
> tag names, even when that recipe isn't even being used in the image
> being built.

Yes, I've had occasional issues with "git ls-remote" during parse time on 
resolving those tags into commit IDs and was planning on eventually replacing 
them.


>   here's the entire list of SRCREV assignments in all of meta-ti, so
> you can see there are only four related to git tag names:
> 
>   i'm currently spending some time at a site that doesn't allow git
> access so those tag names are fatal for doing any sort of OE building.
> and only one of those appears to *prefer* to use the tag name --
> 
> 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"

And that's what mainly was stopping me from doing it already...


>   but, really, you shouldn't be rebasing published commits, anyway.
> so ... thoughts?

And _we_ are not rebasing published commits, but there are some things _we_ 
cannot control, unfortunately. I can talk to other teams to ask them to stop 
rebasing their trees, but in some cases the tree is specifically meant to be 
staging and is supposed to rebase from release to release. There are ways to 
do it differently, so I'll talk to those teams and see what we can do...

-- 
Denys


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: objections to replacing git SRCREV tag names with actual hash IDs?
  2013-02-05  5:05 ` Denys Dmytriyenko
@ 2013-02-05  9:27   ` Robert P. J. Day
  0 siblings, 0 replies; 3+ messages in thread
From: Robert P. J. Day @ 2013-02-05  9:27 UTC (permalink / raw)
  To: Denys Dmytriyenko; +Cc: meta-ti mailing list

On Tue, 5 Feb 2013, Denys Dmytriyenko wrote:

> On Thu, Jan 31, 2013 at 06:58:37AM -0500, Robert P. J. Day wrote:
> >
> >   surely, some of you saw this discussion on the oe-core list last
> > night, but would there be any objection to replacing the small
> > number of git SRCREV settings of tag names with their actual hash
> > IDs?  the motivation should be obvious -- avoid network traffic to
> > parse those tag names, even when that recipe isn't even being used
> > in the image being built.
>
> Yes, I've had occasional issues with "git ls-remote" during parse
> time on resolving those tags into commit IDs and was planning on
> eventually replacing them.

  ... snip ...

  thanks, i realize that, in the grand scheme of things, this isn't a
high priority but it definitely has an annoyance factor :-).  so i'll
leave this with folks higher up the food chain than me.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-02-05  9:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-31 11:58 objections to replacing git SRCREV tag names with actual hash IDs? Robert P. J. Day
2013-02-05  5:05 ` Denys Dmytriyenko
2013-02-05  9:27   ` Robert P. J. Day

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.