
Dear David,
In message 200904251153.51380.david-b@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