From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8886B3BA8E for ; Wed, 29 Nov 2017 12:58:04 -0500 (EST) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 2DD9A21367; Wed, 29 Nov 2017 17:58:03 +0000 (UTC) From: Dave Taht To: Sebastian Moeller Cc: Kevin Darbyshire-Bryant , Cake List References: <700AAEDF-6D34-4F0B-8B48-E34A554F5B6D@darbyshire-bryant.me.uk> <87a7z6p7cz.fsf@nemesis.taht.net> <0A71A7BA-0FD6-4F1C-97F2-2024626FC561@darbyshire-bryant.me.uk> <87k1yaxc65.fsf@nemesis.taht.net> Date: Wed, 29 Nov 2017 09:58:01 -0800 In-Reply-To: (Sebastian Moeller's message of "Wed, 29 Nov 2017 13:39:19 +0100") Message-ID: <87y3mpvufq.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Cake tree unreadable X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 17:58:04 -0000 Sebastian Moeller writes: > Hi All, > > >> On Nov 28, 2017, at 23:37, Dave Taht wrote: >>=20 >>=20 >> A flag day here is feasible. I will fiddle along the lines you describe. >>=20 >> As for other flag days... >>=20 >> I'm toying with the idea of fixing xstats in a separate branch. I really >> hate the idea of breaking backward compatability here, but I do suspect >> it will be a barrier to upstreaming, and it is, quite inefficient. > > > So if we go and change the statistics could we rename max_len to > maxpacket so that fq_codel and cake report the same information under the= same > name. Sure the qdisc statistics are not terribly well coordinated naming-= wise, > but maybe cake could show to be a good citizen here? The justification for that change was that it's 7 characters. I really do want to open up the discussion of other stuff worth breaking along the way. > > Best Regards >>=20 >>=20 >> Kevin Darbyshire-Bryant writes: >>=20 >>>> On 28 Nov 2017, at 18:48, Dave Taht wrote: >>>>=20 >>>>=20 >>>>=20 >>>> It sounds like your git-foo is stronger than ours! I'm not even trying >>>> to get head to work, tho my intent would be to promote cobalt to it. >>>=20 >>> git checkout master >>> git pull (does the equivalent of git fetch origin; git merge origin/m= aster) >>> git merge cobalt (this will produce a minor merge conflict in sch_cak= e.c) >>>=20 >>> fix merge conflict >>>=20 >>> git add sch_cake.c >>> git commit (complete the merge - and create a merge commit in process) >>>=20 >>> git diff cobalt - should return nothing=E2=80=A6content of master & cob= alt are the same. >>>=20 >>> git push (send this to github assuming above is true!) >>>=20 >>> If it were me I=E2=80=99d now restart the cobalt =E2=80=98feature=E2=80= =99 branch from this new =E2=80=98master=E2=80=99 point. >>>=20 >>> git checkout cobalt >>> git reset =E2=80=94hard master (resets =E2=80=98cobalts=E2=80=99 commi= t pointer and the current tree on disc to where master is) >>> git push -f (send that to github -f means force) >>>=20 >>> You=E2=80=99ve just created a =E2=80=98new=E2=80=99 history for the =E2= =80=98cobalt=E2=80=99 feature branch, so all >>> =E2=80=98clients=E2=80=99 of that branch will see a =E2=80=98forced upd= ate=E2=80=99 message=E2=80=A6.you=E2=80=99ve broken the >>> linear git history for that branch, so they=E2=80=99d have to do someth= ing like =E2=80=98git >>> checkout cobalt; git reset =E2=80=94hard origin/cobalt=E2=80=99 >>>=20 >>> I used to be terrified of =E2=80=98git reset=E2=80=99 until I read http= s://git-scm.com/blog/2011/07/11/reset.html - at that point I realised all i= t (and the whole of git) is about moving pointers contained in branch name= s. >>>=20 >>> Of course I=E2=80=99d advise checking things carefully before doing for= ce pushes=E2=80=A6.but then I=E2=80=99d imagine many on this list have fork= s and hence clones of the git repo in various places so it=E2=80=99s all re= coverable. >>>=20 >>>=20 >>>>=20 >>>> I didn't know about the cherry-pick option til now, either. I was doing >>>> a git format-patch thenewcommit, then a git am on my other branch. >>> I=E2=80=99ve just sped up your workflow then :-) >>>>=20 >>>> For example, with this config, git fetch --all doesn't do anything. >>> git fetch =E2=80=94all goes and gets all the branches/commits etc from = all configured >>> remotes. You=E2=80=99ve only 1 remote (origin=E2=80=A6which points at = github) and it=E2=80=99s likely >>> that since it=E2=80=99s not very active that you=E2=80=99ve all the com= mits etc already in your >>> local git database. >>>=20 >>> I have several remotes e.g. >>>=20 >>> [remote "origin"] >>> url =3D git@github.com:ldir-EDB0/sch_cake.git >>> fetch =3D +refs/heads/*:refs/remotes/origin/* >>> [remote "upstream"] >>> url =3D git@github.com:dtaht/sch_cake.git >>> fetch =3D +refs/heads/*:refs/remotes/upstream/* >>> [remote "teg"] >>> url =3D git@github.com:tegularius/sch_cake.git >>> fetch =3D +refs/heads/*:refs/remotes/teg/* >>> [remote "rmounce"] >>> url =3D git@github.com:rmounce/sch_cake.git >>> fetch =3D +refs/heads/*:refs/remotes/rmounce/* >>>=20 >>> so my =E2=80=98git fetch =E2=80=94all=E2=80=99 will go and look in all = those places for things I=E2=80=99m >>> missing. Origin is my own github base cake repo (a clone/fork of yours= ), >>> =E2=80=98upstream=E2=80=99 is a pointer directly to your github repo, = =E2=80=98teg=E2=80=99 & =E2=80=98rmounce=E2=80=99 are >>> pointers to their forks/clones. >>>=20 >>> So to bring my master up to date with yours: >>>=20 >>> git checkout master >>> git fetch =E2=80=94all >>> git merge upstream/master. (which should do a =E2=80=98fast-forward=E2= =80=99 to where you are since I intentionally don=E2=80=99t do any of my ow= n work in master) >>> git push (update my own fork with all the latest stuff) >>>=20 >>>=20 >>> My own stuff (not that there is any anymore =E2=80=98cos it=E2=80=99s a= ll in cobalt) would then be rebased on top of the stable (but moving) maste= r e.g: >>>=20 >>> git checkout worldpeace (my WIP mega solution branch) >>> edit edit edit, commit commit commit >>> git rebase master. - replay all of my stuff on top of the updated master >>> edit - fixup any conflicts >>> git push -f (force update my worldpeace branch on github) >>>=20 >>>=20 >>> I like git, but I=E2=80=99m by no means a guru on it=E2=80=A6.and it to= ok me about 2 years to go from =E2=80=98I hate it=E2=80=99 to =E2=80=98ahhh= I get it - sort of=E2=80=99. The git reset article helped. Also having = =E2=80=98git prompt=E2=80=99 enabled was a godsend. >>>=20 >>>>=20 >>>> [core] >>>> repositoryformatversion =3D 0 >>>> filemode =3D true >>>> bare =3D false >>>> logallrefupdates =3D true >>>> [remote "origin"] >>>> url =3D git@github.com:dtaht/sch_cake.git >>>> fetch =3D +refs/heads/*:refs/remotes/origin/* >>>> [branch "master"] >>>> remote =3D origin >>>> merge =3D refs/heads/master >>>> [branch "for_upstream_4.16"] >>>> remote =3D origin >>>> merge =3D refs/heads/for_upstream_4.16 >>>> [branch "cobalt"] >>>> remote =3D origin >>>> merge =3D refs/heads/cobalt >>>>=20 >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake