FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 06-20-2008, 02:35 PM
Tim Gardner
 
Default Understanding the "Upstream syncing" work flow

Dan Munckton wrote:
> Hi all
>
> I understand how I would rebase my local working tree to the upstream
> kernel. But am I right in presuming that when doing this for the main
> tree on kernel.ubuntu.com, it cannot be done in a local repository then
> pushed to the main repo? Surely this has to be done directly on the
> server? How do you guys manage to do this atomically so as not to
> disrupt folks who are pulling from the main repo?
>
> I have been reading up on the KernelTeam/Knowledgebase wiki pages to
> understand the processes and workflow the team uses to maintain the
> kernel. There's only a short section on "Upstream syncing" on the
> KernelMaintenance page and no notes on how it's done.
>
> Apologies if this has been covered here before, I did search the list
> archives but didn't find much detail on the process.
>
> Cheers
>
> Dan
>
>

Staying in sync with a stable Ubuntu repo isn't much different then
staying in sync with Linus' tree. However, during the development cycle
the development repo (which is Intrepid right now) is rebased against
Linus' tree which makes life difficult for developers. We'll stop
rebasing around kernel freeze time, which is about late September.
Thereafter everything is a cherry-pick or single commit.

--
Tim Gardner tim.gardner@ubuntu.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-20-2008, 03:15 PM
Ben Collins
 
Default Understanding the "Upstream syncing" work flow

On Fri, 2008-06-20 at 15:19 +0100, Dan Munckton wrote:
> Hi all
>
> I understand how I would rebase my local working tree to the upstream
> kernel. But am I right in presuming that when doing this for the main
> tree on kernel.ubuntu.com, it cannot be done in a local repository then
> pushed to the main repo? Surely this has to be done directly on the
> server? How do you guys manage to do this atomically so as not to
> disrupt folks who are pulling from the main repo?
>
> I have been reading up on the KernelTeam/Knowledgebase wiki pages to
> understand the processes and workflow the team uses to maintain the
> kernel. There's only a short section on "Upstream syncing" on the
> KernelMaintenance page and no notes on how it's done.
>
> Apologies if this has been covered here before, I did search the list
> archives but didn't find much detail on the process.
>
> Cheers

No, we don't do this on the server. We do it in a local tree, and then
git-push -f (after making sure there are no unsycned commits in the
server side). Basically just good communication keeps us from
overwriting each other.


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-20-2008, 03:25 PM
Dan Munckton
 
Default Understanding the "Upstream syncing" work flow

On Fri, 2008-06-20 at 11:15 -0400, Ben Collins wrote:
> On Fri, 2008-06-20 at 15:19 +0100, Dan Munckton wrote:
> > I understand how I would rebase my local working tree to the upstream
> > kernel. But am I right in presuming that when doing this for the main
> > tree on kernel.ubuntu.com, it cannot be done in a local repository then
> > pushed to the main repo? Surely this has to be done directly on the
> > server? How do you guys manage to do this atomically so as not to
> > disrupt folks who are pulling from the main repo?
> >
>
> No, we don't do this on the server. We do it in a local tree, and then
> git-push -f (after making sure there are no unsycned commits in the
> server side). Basically just good communication keeps us from
> overwriting each other.
>

Ben, Tim thanks for the info. I will rehearse this for the linux-ports
source so that when I get access to zinc I can update it to 2.6.25.7.


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-20-2008, 07:13 PM
Dan Munckton
 
Default Understanding the "Upstream syncing" work flow

On Fri, 2008-06-20 at 16:25 +0100, Dan Munckton wrote:
> On Fri, 2008-06-20 at 11:15 -0400, Ben Collins wrote:
> > On Fri, 2008-06-20 at 15:19 +0100, Dan Munckton wrote:
> > > I understand how I would rebase my local working tree to the upstream
> > > kernel. But am I right in presuming that when doing this for the main
> > > tree on kernel.ubuntu.com, it cannot be done in a local repository then
> > > pushed to the main repo? Surely this has to be done directly on the
> > > server? How do you guys manage to do this atomically so as not to
> > > disrupt folks who are pulling from the main repo?
> > >
> >
> > No, we don't do this on the server. We do it in a local tree, and then
> > git-push -f (after making sure there are no unsycned commits in the
> > server side). Basically just good communication keeps us from
> > overwriting each other.
> >
> 
> Ben, Tim thanks for the info. I will rehearse this for the linux-ports
> source so that when I get access to zinc I can update it to 2.6.25.7.

Ok so I have the following steps:

$ git remote add linux-2.6.25.y
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git

$ git fetch linux-2.6.25.y

See what's new upstream
$ git log HEAD..linux-2.6.25.y/master

See which commits will be rebased
$ git log linux-2.6.25.y/master..HEAD

Now rebase
$ git rebase linux-2.6.25.y/master

See what's the damage
$ gitk --all


Now, at this point I see all the old Ubuntu-* tags
(e.g. Ubuntu-2.6.25-1.1) are now gone. Do you recreate them or is there
a smart way to keep them?


If all is cool push back (warning other consumers first of course)
$ git push -f origin

As usual any feedback greatly appreciated.

Dan


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-20-2008, 07:28 PM
Tim Gardner
 
Default Understanding the "Upstream syncing" work flow

Dan Munckton wrote:
> On Fri, 2008-06-20 at 16:25 +0100, Dan Munckton wrote:
>> On Fri, 2008-06-20 at 11:15 -0400, Ben Collins wrote:
>>> On Fri, 2008-06-20 at 15:19 +0100, Dan Munckton wrote:
>>>> I understand how I would rebase my local working tree to the upstream
>>>> kernel. But am I right in presuming that when doing this for the main
>>>> tree on kernel.ubuntu.com, it cannot be done in a local repository then
>>>> pushed to the main repo? Surely this has to be done directly on the
>>>> server? How do you guys manage to do this atomically so as not to
>>>> disrupt folks who are pulling from the main repo?
>>>>
>>> No, we don't do this on the server. We do it in a local tree, and then
>>> git-push -f (after making sure there are no unsycned commits in the
>>> server side). Basically just good communication keeps us from
>>> overwriting each other.
>>>
>> 
>> Ben, Tim thanks for the info. I will rehearse this for the linux-ports
>> source so that when I get access to zinc I can update it to 2.6.25.7.
>
> Ok so I have the following steps:
>
> $ git remote add linux-2.6.25.y
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git
>
> $ git fetch linux-2.6.25.y
>
> See what's new upstream
> $ git log HEAD..linux-2.6.25.y/master
>
> See which commits will be rebased
> $ git log linux-2.6.25.y/master..HEAD
>
> Now rebase
> $ git rebase linux-2.6.25.y/master
>
> See what's the damage
> $ gitk --all
>
>
> Now, at this point I see all the old Ubuntu-* tags
> (e.g. Ubuntu-2.6.25-1.1) are now gone. Do you recreate them or is there
> a smart way to keep them?
>
>
> If all is cool push back (warning other consumers first of course)
> $ git push -f origin
>
> As usual any feedback greatly appreciated.
>
> Dan
>

After you've rebased the Ubuntu tags no longer make sense 'cause the
commits that they referenced are likely gone. We try to follow the
protocol of adding the tag name in the commit message atr the time the
tag was created, e.g., Ubuntu-2.6.25-7.1. That way if you ever want to
re-create the tag you can do it from the new commit SHA1.

rtg
--
Tim Gardner tim.gardner@ubuntu.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 08:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org