* Q: Pushing code to 2.4.x
@ 2003-01-29 21:32 Eric W. Biederman
2003-01-29 21:44 ` David Woodhouse
2003-01-31 14:19 ` David Woodhouse
0 siblings, 2 replies; 4+ messages in thread
From: Eric W. Biederman @ 2003-01-29 21:32 UTC (permalink / raw)
To: linux-mtd; +Cc: David Woodhouse
What is the plan for keeping the kernel and the CVS tree more or less in sync?
There are currently some large divergences, to the point there are some
chips that I can use the cfi_cmdset_0002.c from the stable 2.4.x kernel mtd tree
but not from the recent CVS tree.
In addition on the boards I support LinuxBIOS on I ensure there are kernel
mtd drivers that allow people to flash their BIOS rom. And my customers would
like to see those drivers in the stock kernel.
For the short term I can release and maintain patch where everything works,
the question is what should my long term strategy be.
A) Push to the MTD cvs repository and let David Woodhouse push to Marcelo.
B) Push to the MTD cvs repository and push directly to Marcelo.
C) Some more involved coordination of the MTD drivers.
With LinuxBIOS becoming a fully supported product I expect to continually
have more board and more little rom chips that I am making certain work.
Eric
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Q: Pushing code to 2.4.x
2003-01-29 21:32 Q: Pushing code to 2.4.x Eric W. Biederman
@ 2003-01-29 21:44 ` David Woodhouse
2003-01-29 22:34 ` Eric W. Biederman
2003-01-31 14:19 ` David Woodhouse
1 sibling, 1 reply; 4+ messages in thread
From: David Woodhouse @ 2003-01-29 21:44 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-mtd
On 29 Jan 2003, Eric W. Biederman wrote:
> What is the plan for keeping the kernel and the CVS tree more or less in
> sync?
It goes in cycles...
1. I sync to Marcelo/Linus
2. People commit changes.
3. Those changes stabilise and I become happy with them.
4. I plan to find time to sync to Marcelo/Linus again.
5. People bitch at me because it's out of sync.
6. I say "I'll find some time soon, honest".
7. Red Hat finds me more 'real work' to do just when I thought
I'd got some slack some in the Engineering Schedule.
8. People bitch at me some more.
9. I eventually get round to it.
> There are currently some large divergences, to the point there are some
> chips that I can use the cfi_cmdset_0002.c from the stable 2.4.x kernel
> mtd tree but not from the recent CVS tree.
That's a bit of a bugger -- because I sent the CVS code to Marcelo this
week :) Care to enlighten us on the problems you've seen?
> For the short term I can release and maintain patch where everything works,
> the question is what should my long term strategy be.
>
> A) Push to the MTD cvs repository and let David Woodhouse push to Marcelo.
As you've observed, there's a lag involved with this. If you're willing to
help reduce that I'm happy.
> B) Push to the MTD cvs repository and push directly to Marcelo.
This is fine by me assuming the following:
1. You commit to CVS first and then send to Marcelo, including
the appropriate $Id$ changes so I know which version
Marcelo was last sync'd with.
2. You Cc me.
3. Your changes are correct for both 2.4 and 2.5. I don't care
if they're tested, as long as they're correct :)
4. You merge changes from Marcelo's tree into CVS too, before
sending it back to him.
> With LinuxBIOS becoming a fully supported product I expect to continually
> have more board and more little rom chips that I am making certain work.
For new map drivers, and new IDs for the chip drivers, please do commit to
CVS and send to Marcelo simultaneously. I'm perfectly happy with that.
--
dwmw2
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Q: Pushing code to 2.4.x
2003-01-29 21:44 ` David Woodhouse
@ 2003-01-29 22:34 ` Eric W. Biederman
0 siblings, 0 replies; 4+ messages in thread
From: Eric W. Biederman @ 2003-01-29 22:34 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
David Woodhouse <dwmw2@infradead.org> writes:
> On 29 Jan 2003, Eric W. Biederman wrote:
>
> > What is the plan for keeping the kernel and the CVS tree more or less in
> > sync?
>
> It goes in cycles...
> 1. I sync to Marcelo/Linus
> 2. People commit changes.
> 3. Those changes stabilise and I become happy with them.
> 4. I plan to find time to sync to Marcelo/Linus again.
> 5. People bitch at me because it's out of sync.
> 6. I say "I'll find some time soon, honest".
> 7. Red Hat finds me more 'real work' to do just when I thought
> I'd got some slack some in the Engineering Schedule.
> 8. People bitch at me some more.
> 9. I eventually get round to it.
That sounds about right. Things similar things tend to happen here
but as the mtd stuff becomes more real work, and the volume goes
up it is easier to find the time...
> > There are currently some large divergences, to the point there are some
> > chips that I can use the cfi_cmdset_0002.c from the stable 2.4.x kernel
> > mtd tree but not from the recent CVS tree.
>
> That's a bit of a bugger -- because I sent the CVS code to Marcelo this
> week :) Care to enlighten us on the problems you've seen?
Primarily these are the chips from SST. In particular the Roms used
on the old tyan s2466 motherboards. Currently we are working on
a port to PMC flash chips, which is what that board is using now. I didn't
look closely at the time, but we should be able to retest and figure
out what is going on.
> > For the short term I can release and maintain patch where everything works,
> > the question is what should my long term strategy be.
> >
> > A) Push to the MTD cvs repository and let David Woodhouse push to Marcelo.
>
> As you've observed, there's a lag involved with this. If you're willing to
> help reduce that I'm happy.
I am certainly willing to look at that.
> > B) Push to the MTD cvs repository and push directly to Marcelo.
>
> This is fine by me assuming the following:
>
> 1. You commit to CVS first and then send to Marcelo, including
> the appropriate $Id$ changes so I know which version
> Marcelo was last sync'd with.
> 2. You Cc me.
> 3. Your changes are correct for both 2.4 and 2.5. I don't care
> if they're tested, as long as they're correct :)
> 4. You merge changes from Marcelo's tree into CVS too, before
> sending it back to him.
>
> > With LinuxBIOS becoming a fully supported product I expect to continually
> > have more board and more little rom chips that I am making certain work.
>
> For new map drivers, and new IDs for the chip drivers, please do commit to
> CVS and send to Marcelo simultaneously. I'm perfectly happy with
> that.
O.k. Then I will do that. It sounds like a reasonable procedure.
It might be someone else doing the legwork but it that will definitely
be the plan.
Eric
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Q: Pushing code to 2.4.x
2003-01-29 21:32 Q: Pushing code to 2.4.x Eric W. Biederman
2003-01-29 21:44 ` David Woodhouse
@ 2003-01-31 14:19 ` David Woodhouse
1 sibling, 0 replies; 4+ messages in thread
From: David Woodhouse @ 2003-01-31 14:19 UTC (permalink / raw)
To: Christian Hohnstädt; +Cc: linux-mtd
On 29 Jan 2003, Eric W. Biederman wrote:
> What is the plan for keeping the kernel and the CVS tree more or less in
> sync?
It goes in cycles...
1. I sync to Marcelo/Linus
2. People commit changes.
3. Those changes stabilise and I become happy with them.
4. I plan to find time to sync to Marcelo/Linus again.
5. People bitch at me because it's out of sync.
6. I say "I'll find some time soon, honest".
7. Red Hat finds me more 'real work' to do just when I thought
I'd got some slack some in the Engineering Schedule.
8. People bitch at me some more.
9. I eventually get round to it.
> There are currently some large divergences, to the point there are some
> chips that I can use the cfi_cmdset_0002.c from the stable 2.4.x kernel
> mtd tree but not from the recent CVS tree.
That's a bit of a bugger -- because I sent the CVS code to Marcelo this
week :) Care to enlighten us on the problems you've seen?
> For the short term I can release and maintain patch where everything works,
> the question is what should my long term strategy be.
>
> A) Push to the MTD cvs repository and let David Woodhouse push to Marcelo.
As you've observed, there's a lag involved with this. If you're willing to
help reduce that I'm happy.
> B) Push to the MTD cvs repository and push directly to Marcelo.
This is fine by me assuming the following:
1. You commit to CVS first and then send to Marcelo, including
the appropriate $Id$ changes so I know which version
Marcelo was last sync'd with.
2. You Cc me.
3. Your changes are correct for both 2.4 and 2.5. I don't care
if they're tested, as long as they're correct :)
4. You merge changes from Marcelo's tree into CVS too, before
sending it back to him.
> With LinuxBIOS becoming a fully supported product I expect to continually
> have more board and more little rom chips that I am making certain work.
For new map drivers, and new IDs for the chip drivers, please do commit to
CVS and send to Marcelo simultaneously. I'm perfectly happy with that.
--
dwmw2
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-01-31 14:06 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-29 21:32 Q: Pushing code to 2.4.x Eric W. Biederman
2003-01-29 21:44 ` David Woodhouse
2003-01-29 22:34 ` Eric W. Biederman
2003-01-31 14:19 ` David Woodhouse
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox