ron minnich wrote:
That sounds like upstream has failed completely.
there is a delta in time between when it is working in the chromium repo and it makes it to upstream.
..
We've always had this situation. It's not new.
That just means that we haven't improved in a very long time. :\
It's just plain wrong to characterize this as a failure.
I disagree. I do think it means that the project isn't fitting its contributors so well. Note that I am explicitly not saying and not thinking that it is a failure of any contributor.
If the project could change to work somehow differently and that would help contributors then I think that's something we should consider identifying and doing.
It's a natural consequence of the fact that companies can't always immediately push all their work upstream.
What's the difference from Linux kernel development again?
Expecting anything else is unrealistic.
I don't think expectations are too usefule but I think it's what we should strive towards?
//Peter
On Saturday, February 08, 2014 05:30:38 PM Peter Stuge wrote:
If the project could change to work somehow differently and that would help contributors then I think that's something we should consider identifying and doing.
Allow git merging. Forced cherry-picking is a PITA for almost everybody.
The patches would still go through the same review process, but once the branch is go, the entire branch gets merged at once.
Objections?
It's a natural consequence of the fact that companies can't always immediately push all their work upstream.
What's the difference from Linux kernel development again?
See @above.
Alex
Am Samstag, den 08.02.2014, 13:23 -0600 schrieb mrnuke:
Allow git merging. Forced cherry-picking is a PITA for almost everybody.
The patches would still go through the same review process, but once the branch is go, the entire branch gets merged at once.
Objections?
cherry-pick was chosen because it's the only mode where gerrit adds review information to the commit message.
merges could potentially provide the same (in the merge commit), but they currently don't.
Patrick
On Sat, Feb 8, 2014 at 8:30 AM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
I disagree. I do think it means that the project isn't fitting its contributors so well. Note that I am explicitly not saying and not thinking that it is a failure of any contributor.
If you have some idea, then propose it. Best to propose something then just say "this is wrong".
If the project could change to work somehow differently and that would help contributors then I think that's something we should consider identifying and doing.
who is the "we" here? Who identifies, and what do they do? And how do you manage the fact that companies may do development that for a number of reasons can not be released immediately?
It's a natural consequence of the fact that companies can't always immediately push all their work upstream.
What's the difference from Linux kernel development again?
Nothing. Most companies I know of that use Linux, and contribute to upstream, deal with the issue of upstream vs. what is done in the company and the time delay involved. They have the same time delta issue with their internal patches vs. upstream. So we're not different.
ron
-
mrnuke -
Patrick Georgi -
Peter Stuge -
ron minnich