* [RFC] Overlay hosting and mirroring on git.oe.net
@ 2009-01-15 12:25 Koen Kooi
2009-01-15 12:57 ` Ken Gilmer
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Koen Kooi @ 2009-01-15 12:25 UTC (permalink / raw)
To: openembedded-devel
Hi,
There are a lot of OE based projects around that use an overlay to
manage their tweaks (e.g. gumstix, openpandora, arago), which has pros
and cons. A while ago I was talking to John Willis (of open2x and
openpandora fame) and he liked the idea of mirroring the pandora overlay
on git.oe.net to make it more visible and to make it easier for OE
developers to work on making pieces of it upstream safe.
I think a git mirror of poky would fall in this category as well.
What do you think of this?
regards,
Koen
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFC] Overlay hosting and mirroring on git.oe.net
2009-01-15 12:25 [RFC] Overlay hosting and mirroring on git.oe.net Koen Kooi
@ 2009-01-15 12:57 ` Ken Gilmer
2009-01-15 14:45 ` John Willis
2009-01-15 17:25 ` Denys Dmytriyenko
2 siblings, 0 replies; 6+ messages in thread
From: Ken Gilmer @ 2009-01-15 12:57 UTC (permalink / raw)
To: openembedded-devel; +Cc: openembedded-devel
I'm writing some OE tools and there seems to be some variance in
hardware and distro specific overlays that may not be entirely
necessary. Additionally I have hesitated to submit most of what I work
on upstream due to the amount of effort to test against stock OE-dev
from Poky-Bug. So, yes, +1 for this if it reduces unnecessary variance
and making it easier to test packages cross-distro and cross-machine.
thx
ken
On Thu, 2009-01-15 at 13:25 +0100, Koen Kooi wrote:
> Hi,
>
> There are a lot of OE based projects around that use an overlay to
> manage their tweaks (e.g. gumstix, openpandora, arago), which has pros
> and cons. A while ago I was talking to John Willis (of open2x and
> openpandora fame) and he liked the idea of mirroring the pandora overlay
> on git.oe.net to make it more visible and to make it easier for OE
> developers to work on making pieces of it upstream safe.
> I think a git mirror of poky would fall in this category as well.
>
> What do you think of this?
>
> regards,
>
> Koen
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Overlay hosting and mirroring on git.oe.net
2009-01-15 12:25 [RFC] Overlay hosting and mirroring on git.oe.net Koen Kooi
2009-01-15 12:57 ` Ken Gilmer
@ 2009-01-15 14:45 ` John Willis
2009-01-15 15:24 ` Denys Dmytriyenko
2009-01-15 17:25 ` Denys Dmytriyenko
2 siblings, 1 reply; 6+ messages in thread
From: John Willis @ 2009-01-15 14:45 UTC (permalink / raw)
To: openembedded-devel
Hi,
> There are a lot of OE based projects around that use an overlay to
> manage their tweaks (e.g. gumstix, openpandora, arago), which has pros
> and cons. A while ago I was talking to John Willis (of open2x and
> openpandora fame) and he liked the idea of mirroring the pandora overlay
> on git.oe.net to make it more visible and to make it easier for OE
> developers to work on making pieces of it upstream safe.
> I think a git mirror of poky would fall in this category as well.
Get's my vote. As I mentioned on IRC the current OpenPandora model uses 3
overlays. With the 3rd one being a simple user.collection that local Pandora
specific recipes go into before working there way upwards.
In time I would love to get to a model for Pandora specific stuff where
hacks go user.collection > openpandora.dev > (hopefully)
openembedded.dev/stable. Mirroring the GIT for openpandora.dev (or whatever
the final name we settle on is) on git.oe.net seems very sensible to me.
This also fits with possible ideas such as a 'for-upstream' branch to manage
upwards movement.
I am in the progress of moving/consolidating all the OpenPandora GIT stuff
onto one server (git.openpandora.org) so as soon as that is done then I can
see no reason not to start the mirroring even if we are still loading stuff
in and tweaking.
Regards,
John Willis
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Overlay hosting and mirroring on git.oe.net
2009-01-15 14:45 ` John Willis
@ 2009-01-15 15:24 ` Denys Dmytriyenko
0 siblings, 0 replies; 6+ messages in thread
From: Denys Dmytriyenko @ 2009-01-15 15:24 UTC (permalink / raw)
To: openembedded-devel
On Thu, Jan 15, 2009 at 02:45:23PM -0000, John Willis wrote:
> Hi,
>
> > There are a lot of OE based projects around that use an overlay to
> > manage their tweaks (e.g. gumstix, openpandora, arago), which has pros
> > and cons. A while ago I was talking to John Willis (of open2x and
> > openpandora fame) and he liked the idea of mirroring the pandora overlay
> > on git.oe.net to make it more visible and to make it easier for OE
> > developers to work on making pieces of it upstream safe.
> > I think a git mirror of poky would fall in this category as well.
>
> Get's my vote. As I mentioned on IRC the current OpenPandora model uses 3
> overlays. With the 3rd one being a simple user.collection that local Pandora
> specific recipes go into before working there way upwards.
From Arago perspective I'm in favor of this proposal as well. Thanks.
--
Denys
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Overlay hosting and mirroring on git.oe.net
2009-01-15 12:25 [RFC] Overlay hosting and mirroring on git.oe.net Koen Kooi
2009-01-15 12:57 ` Ken Gilmer
2009-01-15 14:45 ` John Willis
@ 2009-01-15 17:25 ` Denys Dmytriyenko
2009-01-15 18:58 ` Koen Kooi
2 siblings, 1 reply; 6+ messages in thread
From: Denys Dmytriyenko @ 2009-01-15 17:25 UTC (permalink / raw)
To: openembedded-devel
On Thu, Jan 15, 2009 at 01:25:27PM +0100, Koen Kooi wrote:
> Hi,
>
> There are a lot of OE based projects around that use an overlay to manage
> their tweaks (e.g. gumstix, openpandora, arago), which has pros and cons. A
> while ago I was talking to John Willis (of open2x and openpandora fame) and
> he liked the idea of mirroring the pandora overlay on git.oe.net to make it
> more visible and to make it easier for OE developers to work on making
> pieces of it upstream safe.
> I think a git mirror of poky would fall in this category as well.
>
> What do you think of this?
Will those be read-only mirrors or read-writeable branches/forks?
--
Denys
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] Overlay hosting and mirroring on git.oe.net
2009-01-15 17:25 ` Denys Dmytriyenko
@ 2009-01-15 18:58 ` Koen Kooi
0 siblings, 0 replies; 6+ messages in thread
From: Koen Kooi @ 2009-01-15 18:58 UTC (permalink / raw)
To: openembedded-devel
On 15-01-09 18:25, Denys Dmytriyenko wrote:
> On Thu, Jan 15, 2009 at 01:25:27PM +0100, Koen Kooi wrote:
>> Hi,
>>
>> There are a lot of OE based projects around that use an overlay to manage
>> their tweaks (e.g. gumstix, openpandora, arago), which has pros and cons. A
>> while ago I was talking to John Willis (of open2x and openpandora fame) and
>> he liked the idea of mirroring the pandora overlay on git.oe.net to make it
>> more visible and to make it easier for OE developers to work on making
>> pieces of it upstream safe.
>> I think a git mirror of poky would fall in this category as well.
>>
>> What do you think of this?
>
> Will those be read-only mirrors or read-writeable branches/forks?
That'd be for the overlay owner(s) to decide.
regards,
Koen
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-01-15 19:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-15 12:25 [RFC] Overlay hosting and mirroring on git.oe.net Koen Kooi
2009-01-15 12:57 ` Ken Gilmer
2009-01-15 14:45 ` John Willis
2009-01-15 15:24 ` Denys Dmytriyenko
2009-01-15 17:25 ` Denys Dmytriyenko
2009-01-15 18:58 ` Koen Kooi
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.