[U-Boot] U-Boot ARM merge strategy

[David Brownell]

Hi Wolfgang,

On Saturday 25 April 2009, Wolfgang Denk wrote:
> in message <200904250555.17450.david-b at pacbell.net> you wrote:
> >
> > I think the questions on this topic reflect a reality that
> > such status updates aren't yet visible enough.  (The original
> > question was generic, not ARM-specific.)
> 
> I'm not going to push this information down people's throats. I  love
> living  free.  Those  who want that information can pick it up, those
> who don't will not get bothered.
> 
> Is it really too much to ask that people have a look at the U-Boot web
> page every now and then?

It's not on the front page, which is where for example you'll
see status for Linux (www.kernel.org) or GCC (gcc.gnu.org).
And it's not visible in the source tree either.


> Is it really so difficult to find our when 
> the merge window ends?

By observation:  yes.

But also, when you *do* find the Official Statment it does
so in reference to Linux processes ... which make that state
very easy to find, via the "rc1" git tags.


> 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.

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.


> > > Maybe I pout a little more meaning in the words "release candiate".
> > 
> > ISTR that Linus has said on occasion that "RC" doesn't
> > mean "release candidate"!
> 
> He. This is his interpretation, then. I take the freedom to use a
> different one :-)

You won't find SuSE, RedHat, or Canonical using an rc1 kernel
for even a beta distribution ... ;)

 
> > You're not actually running the "merge window" quite like
> > Linux does; that "backlog" is one differentiator.
> 
> 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.

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.


> > 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.

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".
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.  ;)

- Dave