[RFC] Coreboot Ports in Progress

[bari]

Is there anyway we can try keep track of what everyone may be doing as 
far as ports of coreboot to new boards or chipsets as well as utils?

I understand that sometimes projects are under contract and need to be 
kept quiet until after it's completed and released. But for others, it 
is not a problem to at least announce on the mail list what they may be 
up to, or if the project has stalled.

Case in point, the C7 + CN700 (epia-cn) port had several efforts going 
on in parallel with everyone going through the shared pain and 
duplicated issues.

My hope is to further the spirit of cooperation we already have and 
expedite the development of coreboot ports and utils in the future.

-Bari

[ron minnich]

On Mon, Jun 23, 2008 at 10:50 AM, bari  wrote:
> Is there anyway we can try keep track of what everyone may be doing as
> far as ports of coreboot to new boards or chipsets as well as utils?
>
> I understand that sometimes projects are under contract and need to be
> kept quiet until after it's completed and released. But for others, it
> is not a problem to at least announce on the mail list what they may be
> up to, or if the project has stalled.
>
> Case in point, the C7 + CN700 (epia-cn) port had several efforts going
> on in parallel with everyone going through the shared pain and
> duplicated issues.

great idea. sounds like another web page to me?

ron

[Rudolf Marek]

I'm doing:

K8M890/VT8237S

I have following datasheets under NDA:

VT8237R NDA
VT8237S NDA
VT8237A NDA
K8T890CE NDA
K8T890CF NDA
K8M890 NDA

Rudolf

[Corey Osgood]

On Mon, Jun 23, 2008 at 1:02 PM, ron minnich  wrote:
> On Mon, Jun 23, 2008 at 10:50 AM, bari  wrote:
> > Is there anyway we can try keep track of what everyone may be doing as
> > far as ports of coreboot to new boards or chipsets as well as utils?
> >
> > I understand that sometimes projects are under contract and need to be
> > kept quiet until after it's completed and released. But for others, it
> > is not a problem to at least announce on the mail list what they may be
> > up to, or if the project has stalled.
> >
> > Case in point, the C7 + CN700 (epia-cn) port had several efforts going
> > on in parallel with everyone going through the shared pain and
> > duplicated issues.
>
> great idea. sounds like another web page to me?
>
> ron

I'd like to see a shared "development" repo that just about anyone can
get commit rights to, or can be openly committed to (obviously with
some sort of backups). Then devs can commit whatever they've done
nightly, and new patches for the stable tree can be pulled from that.
Then again, my participation's been pretty non-existent lately, so I
guess my wants shouldn't count for much ;)

-Corey

[Stefan Reinauer]

Corey Osgood wrote:
> I'd like to see a shared "development" repo that just about anyone can
> get commit rights to, or can be openly committed to (obviously with
> some sort of backups). Then devs can commit whatever they've done
> nightly, and new patches for the stable tree can be pulled from that.

Just out of curiosity. What existing problem would that solve?

Stefan

[Paul Menzel]

Dear list,

Am Donnerstag, den 26.06.2008, 12:03 +0200 schrieb Stefan Reinauer:
> Corey Osgood wrote:
> > I'd like to see a shared "development" repo that just about anyone can
> > get commit rights to, or can be openly committed to (obviously with
> > some sort of backups). Then devs can commit whatever they've done
> > nightly, and new patches for the stable tree can be pulled from that.
>
> Just out of curiosity. What existing problem would that solve?

Problem: People do not know who is working on porting what board.

Solution from Corey:

Under the premise that every developer would do his development in that
“development” repository (I guess in his own branch) or would commit his
effort at the end of the day, people could track what they are working
on. So everybody would be up to date what ports are being worked on.

At least that is my interpretation.

Best regards,

Paul

[Stefan Reinauer]

Paul Menzel wrote:
> Problem: People do not know who is working on porting what board.
>
> Solution from Corey:
>
> Under the premise that every developer would do his development in that
> “development” repository (I guess in his own branch) or would commit his
> effort at the end of the day, people could track what they are working
> on. So everybody would be up to date what ports are being worked on.

we're running several internal coreboot repositories here at 
coresystems, but creating yet another open repository would not mean we 
can easily commit to those, as a lot of that code has to go through 
legal clearance first before we can make it publically available. I 
guess that issue applies for a lot of (all?) people working on modern 
(non-amd) chipsets these days

So I don't see how another repository would improve the situation more 
than just sending patches or URLs to trees to the list?

We can add new repositories if there is need for it, and we can also add 
a git bridge if people desire that. But the past showed that we did a 
lot of this stuff and it never got used really. So I'm trying to keep 
things simple. coreboot is a complex thing. Adding 5 more repositories 
(or just 1 more) will not make it easier for newcomers to get started.

Stefan

[Corey Osgood]

On Thu, Jun 26, 2008 at 10:31 AM, Stefan Reinauer  wrote:
> Paul Menzel wrote:
> > Problem: People do not know who is working on porting what board.
> >
> > Solution from Corey:
> >
> > Under the premise that every developer would do his development in that
> > "development" repository (I guess in his own branch) or would commit his
> > effort at the end of the day, people could track what they are working
> > on. So everybody would be up to date what ports are being worked on.

No, I was saying a single dev branch, strictly for new ports. In
theory, it would allow people to see what others are working on,
comments should let them know what needs to be done, and they could
work together without passing patches against patches or 50MB trees
back and forth. Also, incomplete ports could stick around without
cluttering the main tree, so we don't lose a half-finished port that
some dev got irritated with, or some company decided they didn't want.
> we're running several internal coreboot repositories here at
> coresystems, but creating yet another open repository would not mean we
> can easily commit to those, as a lot of that code has to go through
> legal clearance first before we can make it publically available. I
> guess that issue applies for a lot of (all?) people working on modern
> (non-amd) chipsets these days

True, but most amateur devs are working off public docs from Intel or,
if they can get their hands on them, Via, and might not have NDA
restrictions (but with that, they also have less info :( ).

-Corey