[U-Boot] u-boot-socfpga repository

[Tom Rini <trini@ti.com>]

On Sun, Sep 14, 2014 at 11:02:08AM -0500, Dinh Nguyen wrote:
> Hi Wolfgang,
> 
> On 9/12/14, 5:51 PM, Wolfgang Denk wrote:
> > Dear Dinh,
> > 
> > In message <541373AD.4020902@opensource.altera.com> you wrote:
> >>
> >> Then I vote for myself as the custodian for u-boot-socfpga. By the way,
> > 
> > May I ask what made you change your mind like that?  First you wrote
> > that Vince was assigned to to that, and now it's suddenly you?  As far
> > as I can see, you have not participated in any SoCPGA related code
> > reviews or discussions in 2014 at all, so what would be the
> > difference?
> 
> Touche...
> 
> > 
> >> what is the difference between a Maintainer and a custodian? I don't
> >> understand why if Chin-Liang and myself are listed as Maintainer(s) for
> >> SOCFPGA, we would have to rely on Marek to pull in our patches for SOCFPGA?
> > 
> > A maintainer is someone who developed some piece of code and feels
> > responsible for it - who is available as contact person for questions,
> > or who will be asked to fix any bugs in that code.
> > 
> > A Custodian is "one that guards and protects or maintains" [1], i. e.
> > he is responsible for maintaining the design principles of U-Boot and
> > the code quality even for code he did not work on himself, and for
> > patches submitted by others.  This is a job that carries a much higher
> > responsibility than just maintaining your own code.  He will interface
> > to the actual maintainers of the respective code, negotiatiate
> > solutions and decide in case of conflicts.
> > 
> > [1] http://www.merriam-webster.com/dictionary/custodian
> > 
> >> Yes, this is the repo will be the one that we will use. I have a couple
> >> of other things on my plate at the moment and will populate this repo
> >> shortly.
> > 
> > Thats great, as it means you will not lose any efforts when we start
> > with u-boot-socfpga now, as you then can start with synchronized
> > repositories right from the beginning.
> 
> FWIW, I strongly oppose assigning an external person to be the custodian
> for socfpga. Marek is fantastic developer, and my only issue is that he
> is not an Altera employee. I contend that an in-house custodian for
> socfpga is the best choice. I know that my voice carries little weight
> here, but I would, at least, think I have Altera's best interest in mind
> here.

I don't think it's a bad thing for the custodian for a given SoC to be
an employee of the vendor as they're likely to have more insight into
how things really work and be able to get questions answered about
how/why a magic bit needs to be set.

> Also, I went back and look at the "flurry" of patches for socfpga, and I
> must commend Tom Rini on a fantastic job for applying the patches. I was
> only able to find 1 patch that needed addressing:
> 
> [socfpga: generic board for socfpga] from Pavel Machek

Can you test it, and Reviewed-by/Acked-by/Tested-by or something the
patch?  patchwork collects these and that is a big part of our review
and merge process here.

> For now, I have it applied to
> 
> git://git.rocketboards.org/u-boot-socfpga-next.git for_next  branch.

Here's a difference from the Linux kernel community.  We really do want
to use a git tree hosted on git.denx.de for pulls.

> There are a few patches that needs to be addressed in the mailing list,
> but I don't see any other patches that needs to be applied at this
> moment. Please correct me if I'm wrong.
> 
> To summarize, have we failed as maintainers of socfpga that you would
> need to assign somebody else to be the custodian for socfpga? If
> so, I apologize and would like for you to reconsider your position and
> let us try to do a better job.

Just like in the kernel community, it's a position that has to be
earned.  I understand there should be big round of patches posted soon,
which will be a good place to see follow-through.  There's also the
denali NAND patches which are blocking another SoC from going in as well
which I'm hoping to see v10 of posted sometime in the coming week.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140914/045ea1dc/attachment.pgp>