> > We need to pick a method for accepting new chips and go with it. If you want whole files that are finished, that's fine with me. If you want to force the development to be done elsewhere, I'm fine with that too.
>
> I'm not sure if I understand this correctly. You seem to
> say that pushing whole files implies that you have to first
> finish the whole development and then break it apart again?
> Is that it?
>
> I guess that might be true for a small, core part of the
> code, but most likely not for the whole 11k LOC. Maybe
> I'm wrong here but the code looks too well organized to
> be hard to break apart, or rather to pick one topic after
> another from it.

We've already been working on the project for a bit while we've been waiting for permission to start upstreaming it. Because of that we've got a backlog of changes to push. It's not a large backlog at this point, but it's not insignificant. That work's just been done on individual machines so far - I've got to go through that code and break it into small cohesive bits.

So I could just push the changed files, which include changes from various different topics, but that would make it hard to review.

While I do work at Google, I'm a part of the coreboot community. I'm working at Google BECAUSE i'm a part of the community. I understand the issues. I don't like the blobs and lack of documentation either. Although it may still be going in the wrong direction I'm actively working to try to improve things.

Um, I'm confused that you bring your employment and blobs
into this. Did sb. (I?) bring that up somewhere and forgot?
Or is there an argument? If you wouldn't be a part of the
community (which is great that you are btw.) and working
for Google, this discussion would be less unexpected? I'm
really puzzled here.

No, you didn't say anything, but you can't deny that there's a lot of resentment about large companies (such as Google) in some sectors of the community. I'm trying to say (Not specifically to you) that I'm working as a part of the community, not just as a representative for Google. I feel the same frustration with the blob situation, and I'm sorry. My opinion is that it's best to work with the companies to show why it's better to publish. Other people feel like it's better to boycott and badmouth the companies. (Nico, I'm not pointing at you in saying this. We've all seen the discussions on IRC.) I get it - people feel strongly. We've both put countless hours into the project, far more than most people who want to sit on the sidelines and criticize.

If I were entering the community for the first time, trying to commit a new SOC, it would look insurmountable. I'm saying that we should have a defined method of how to push and maintain these things that we can agree upon as a community.

• Do we start with an existing codebase so that the changes can easily be seen? There are people in the community who feel strongly about both methods.
• If a file already exists and you're pushing it, how does it need to be broken up for review? If so, how?
• What's the requirement for going back and refactoring old code when you're adding new code? Can it be copied initially and then refactored as the project progresses, or do you have to refactor it into a common location before you'll be allowed to push in your chip?
• What's required in terms of long-term-maintenance when a new SOC is pushed? Does the requirement to maintain it end when the project ends, or is there an implied agreement to continue maintaining it? If so, how long?
• What's expected when someone points out a problem in the code?
• What sort of documentation is required on the SOC?
• Is the expectation different if an individual is trying to add a new chip than if a company is pushing it. If so, why?

View Change

To view, visit change 32407. To unsubscribe, or for help writing mail filters, visit settings.