search for: downstream

...ot;Section","starttime","startdate","tot.c" "Upstream",0,04/09/09,0.17 "Upstream",0,04/09/09,0.19 "Upstream",0,04/09/09,0.14 "Middle",0,04/09/09,0.2 "Middle",0,04/09/09,0.13 "Middle",0,04/09/09,0.11 "Downstream",0,04/09/09,0.16 "Downstream",0,04/09/09,0.17 "Downstream",0,04/09/09,0.17 "Upstream",25,04/09/09,0.17 "Upstream",25,04/09/09,0.19 "Upstream",25,04/09/09,0.14 "Middle",25,04/09/09,0.2 "Middle",25,04/09/09,0.13 "Middle&q...

Building on the great work that James Knight did on migrate-downstream-fork.py (Thanks, James!) [1], I've created a simple tool to take migrated downstream fork branches and zip them into a single history given a history containing submodule updates of subprojects [2]. With migrate-downstream-fork.py, one is left with a set of unrelated histories, one per subproj...

On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > We're going to be doing the same probing process in nouveau for > determining downstream DP port capabilities, so let's deduplicate the > work by moving i915's code for handling this into a shared helper: > drm_dp_downstream_read_info(). > > Note that when we do this, we also do make some functional changes while > we're at it: > * We always clear the dow...

...interested to know about > this, comments down below) > > On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote: > > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > > > We're going to be doing the same probing process in nouveau for > > > determining downstream DP port capabilities, so let's deduplicate the > > > work by moving i915's code for handling this into a shared helper: > > > drm_dp_downstream_read_info(). > > > > > > Note that when we do this, we also do make some functional changes while > > &g...

...10 } set timeout { other.first 60, other.single 30, other.multiple 60 } set limit { states 10000, frags 5000 } set optimization normal #set block-policy drop #set require-order yes ############ SHAPING goes here ############################### altq on $intif cbq bandwidth 100Mb queue {etherdown, downstream} queue etherdown bandwidth 96% cbq(default) queue downstream bandwidth 4% cbq altq on $extif cbq bandwidth 100Mb queue { etherup, upstream} queue etherup bandwidth 99Mb cbq(default) queue upstream bandwidth 386Kb cbq pass in quick on $intif from 172.16.0.0/16 to 172.16.0.0/16 queue etherdown...

...just a "hey, let's see what we can do in the future". -eric On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Valentin, > > You are proposing to change existing policy. Current policy is that we > don't consider downstream *at all*. Your proposal may seem reasonable - it > may even *be* reasonable - but it is definitely a change from historical > practice and must be considered as such. > > Philip > On 2/18/20 3:03 PM, Valentin Churavy wrote: > > I don't think anyone is arguing to change lon...

I don't think anyone is arguing to change longstanding policy. From a downstream perspective many small renaming changes do increase overhead for us. One thing that happens to downstream projects is that they support more than one LLVM version, we (JuliaLang) currently try to support latest stable + master. So for me the question is more, are renaming changes worth downstream...

...e suggestion/discussion than is actually there. * I do not want upstream developers "trying to be polite" if that delays otherwise worthwhile work. Nobody suggested that. It’s perfectly possible to “be polite” and still not delay worthwhile work. * The current policy is "downstream is on their own". Nobody disputes that. * There was nothing even remotely unreasonable done in the patch series which triggered this discussion and I don't want any upstream contributor coming to believe there was. I disagree with you about “nothing even remotely unreasonable” in tha...

...to the cc here, they might be interested to know about this, comments down below) On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote: > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > > We're going to be doing the same probing process in nouveau for > > determining downstream DP port capabilities, so let's deduplicate the > > work by moving i915's code for handling this into a shared helper: > > drm_dp_downstream_read_info(). > > > > Note that when we do this, we also do make some functional changes while > > we're at it: >...

...al or not at all. An issue that wasn't really resolved I think. I had the impression that the efforts fizzled out a bit, and I thought this renaming was maybe related to that, but I'm neutral on if we should do variable renaming. All I'm asking as a kindness if we could be kind on poor downstream maintainers not on the issue of variable renaming at large, but on the micro level of not pushing 5/6 patches of this kind covering closely related functionality in two days but collating them in 1. I don't think that would slow down development, and I wanted to highlight the issue, as people m...

...> this, comments down below) > > > > On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote: > > > On Tue, Aug 11, 2020 at 04:04:50PM -0400, Lyude Paul wrote: > > > > We're going to be doing the same probing process in nouveau for > > > > determining downstream DP port capabilities, so let's deduplicate the > > > > work by moving i915's code for handling this into a shared helper: > > > > drm_dp_downstream_read_info(). > > > > > > > > Note that when we do this, we also do make some functional change...

...: Robinson, Paul <paul.robinson at sony.com> Cc: Philip Reames <listmail at philipreames.com>; Eric Christopher <echristo at gmail.com>; llvm-dev at lists.llvm.org; Valentin Churavy <v.churavy at gmail.com> Subject: Re: [llvm-dev] amount of camelCase refactoring causing some downstream overhead On Wed, Feb 19, 2020 at 12:10 PM Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi Philip, I think you might be reading more into the suggestion/discussion than is actually there. * I do not want upstream developers...

> On 29 Jul 2016, at 19:19, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 29 Jul 2016, at 05:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> What I meant by “different problem" is that “downstream users” for instance don’t need to commit, that makes their problem/workflow quite different from an upstream developer (for instance it is fairly easy to maintain a read-only view of the existing individual git repo currently on llvm.org). > > I’m not convinced by this distinction. A lot of...

On 29 Jul 2016, at 05:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > What I meant by “different problem" is that “downstream users” for instance don’t need to commit, that makes their problem/workflow quite different from an upstream developer (for instance it is fairly easy to maintain a read-only view of the existing individual git repo currently on llvm.org). I’m not convinced by this distinction. A lot of downstrea...

Folks, There has been enough discussion about keeping development downstream and how painful that is. Even more so, I think we all agree, is having downstream releases while tracking upstream releases, trunk and other branches (ex. Android). I have proposed "en passant" a few times already, but now I'm going to do it to a wider audience: Shall we sync our up...

We're going to be doing the same probing process in nouveau for determining downstream DP port capabilities, so let's deduplicate the work by moving i915's code for handling this into a shared helper: drm_dp_downstream_read_info(). Note that when we do this, we also do make some functional changes while we're at it: * We always clear the downstream port info before tryin...

...s.llvm.org/rG549b436beb4129854e729a3e1398f03429149691 - https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b - https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956 Unfortunately all these individual commits trigger the same merge conflicts over and over again with our downstream repo, which takes us some manual intervention every time. I understand uniformity is a nice to have, but: 1 - is it worth it to do this work right now? I can remember the casing debate a few months back, which seems unrelated to this work which seems manual, but I'm unsure of the outcome. 2 -...

We're going to be doing the same probing process in nouveau for determining downstream DP port capabilities, so let's deduplicate the work by moving i915's code for handling this into a shared helper: drm_dp_read_downstream_info(). Note that when we do this, we also do make some functional changes while we're at it: * We always clear the downstream port info before tryin...

He all, I've updated the downstream fork zipping tool that I posted about last November [1]. It is much improved in every way. The most important enhancements are: - Does a better job of simplifying history - Handles nested submodules - Will put non-submodule-update content in a subdirectory of the monorepo - Updates tags In...

...some comments inline, but I'll > summarize my thoughts here: > > - I like to think that the major releases have been shipped on a > pretty reliable six-month schedule lately. So we have that going for > us :-) > > - It seems hard to align our upstream schedule to various downstream > preferences. One way would be to release much more often, but I don't > know if that's really desirable. I’d like to also point out that it’s not only about the schedule, but also a lot about the release strategy. For example, we branch a very long time before we release externally...