[U-Boot] U-Boot ARM merge strategy

[Wolfgang Denk]

Dear David,

In message <200904251153.51380.david-b at pacbell.net> you wrote:
> 
> > Just type "u-boot merge window" at google and 
> > click on the very first link.
> 
> Several other key infrastructure projects make it easy to
> find that info even without using a search engine.

Come on and be reasonable. Yes, the current release state is not on the
front page. But it is just one click away.

And my reference to google was just because of the argument "difficult
to find".

> As a developer, I'd be more likely to look at the GIT summary
> for status of the GIT tree; its normally the first place to
> look for such things.

I agree fully with this statement. But at the same time I have to
point out that this is exactly where our opinions differ:

- You expect that the U-Boot git repository mirrors the current state
  in the release process, ideally in the same way as Linux handles
  this.

- For me, the current phase of the release process is not necessarily
  reflected by a specific tag on the git tree.

This is a (as I think unavoidable) consequence of the existing
differences in the prcedures:

* In Linux, top-level maintainers will collect patches in their trees
  and send pull requests to Linus as soon as the merge window opens.

  So far, most U-Boot custodians do not work like that; they send
  pull requests only at (or even after) the end of the merge window.

* In Linux, the closing of the merge window is maked by
  the release of the next ="-rc1"

  In U-Boot, "-rc1" will only be released after all (or at least most
  of the) patches that were submitted during the merge window have
  been applied.


> > Well, yes, I know. The tiome when I get the pull requests from the
> > custodians is another one - being a major contribution to the former.
> 
> And Linux has had years to develop -- and motivate! -- its
> merge procedures ... it's a different team and process.
> 
> Processes need constant tweaking though.  And your process
> page strongly suggests you're using the Linux processes.
> Hence surprise and confusion when you aren't quite doing so,
> from folk who use those processes daily.

Well, it's exactly my intention to do things differnetly or to cause
confusion :-(

But the thing is, that we (the custodians and me) are not working
(yet?) as the Linux maintainers do. I hope we can improve.


I am really thankful for this discussion - IIRC this is the first time
ever that suchtopics have been discussed here.


> Easily addressed though ... that web page can point out some
> differences.  Make a few small things *obviously* different,
> and people will assume that other things may also differ.

I tried to make things a bit clearer. Please have a look at
http://www.denx.de/wiki/U-Boot/ReleaseCycle  and
http://www.denx.de/wiki/U-Boot/DevelopmentProcess   and let me know
what's unclear or missing or needs improvement (or, even better, edit
it yourself -it's a wiki after all, where everybody can contribute).

> 
> > > When the RC label just means "we only integrate bugfixes now",
> > > that communicates such status with very little work.  If folk
> > > miss some webpage, or mailing list post, they'll still know.
> > 
> > Please allow me to stick with RC = release candidate, i. e. something
> > that is at least reasonably compile  tested  and  has  at  least  the
> > majority of patches included.
> 
> I couldn't stop you, of course.  All I'm doing is pointing out
> what others have also pointed out:  that the current process
> is a bit opaque about some key points.  And I'm trying to help
> with some small suggestions.

I've tried to explain the reasons for the differences on the web page.

> Since you don't want to use an "rc" tag -- even "rc0"? -- maybe
> some other git tag could be used to flag "merge window ended".

Please see above - I feel it would be wrong, as the "merge window
closed" state is nothing that has a direct representation in our git
tree.

> A "-pre", maybe.  If there's some obvious indicator there, you
> wouldn't need to update the wiki except maybe to summarize key
> points of the process you want to publicize.  And contributors
> wouldn't be scratching their heads, or starting long discussions
> on the list.  ;)

But this discussion is/was a good thing to have!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Open the pod bay doors, HAL."                    - Dave Bowman, 2001