Am Mittwoch, 30. Juli 2014, 23:47:16 schrieb Yves Blusseau: > Le 30 juil. 2014 à 17:48, kp kirchdoerfer <kap...@users.sourceforge.net> a écrit : > > Am Dienstag, 29. Juli 2014, 18:17:56 schrieb Yves Blusseau: > >> Hi all, > >> > >> i think you are misusing the next branch. > >> The next branch is not use to be the next branch for the next release. As > >> the git workflow guide said (http://goo.gl/BOzkap) the next branch is > >> intended as a testing branch for topics being tested for stability for > >> master. So the next branch is used to test topic/features branch for the > >> next release. > >> > >> In our case i see this commits that are in next but not in master: > >> $ git log origin/master..origin/next --no-merges > >> commit 01bd68d1c78dd3695bf841449e9876932e6d5c84 > >> Author: Andrew Denisenko <nitr0...@users.sourceforge.net> > >> Date: Tue Jul 29 10:40:55 2014 > >> > >> linux: disable RPI patch > >> > >> it fails on 3.14.13 > >> > >> commit 78cd8b09fdc563366d36aa5aff962c6d0bc655fb > >> Author: Andrew Denisenko <nitr0...@users.sourceforge.net> > >> Date: Tue Jul 29 10:40:24 2014 > >> > >> linux: update connmark patch > >> > >> commit ec13e4f0fdba26b9ef5a7bbda339b689fdd26b49 > >> Author: Andrew Denisenko <nitr0...@users.sourceforge.net> > >> Date: Tue Jul 29 10:35:07 2014 > >> > >> iptables: fix ipt_netflow > >> > >> commit e17d2ee03de21a945f3d8b47a5df85f854752572 > >> Author: Andrew Denisenko <nitr0...@users.sourceforge.net> > >> Date: Mon Jul 28 22:04:18 2014 > >> > >> Revert "iptables remove ipt_netflow" > >> > >> This reverts commit 0e53bbadb540bf3a00a73524b4d48d64c977446b. > >> > >> commit 0e53bbadb540bf3a00a73524b4d48d64c977446b > >> Author: kapeka <kap...@users.sourceforge.net> > >> Date: Mon Jul 28 20:53:06 2014 > >> > >> iptables remove ipt_netflow > >> > >> - it fails to compile and therefor iptables does not build, and > >> > >> consequently kmodules will not packaged. - the latest sources on SF > >> claims > >> that it is only supported until kernel 3.11 > >> > >> So remove it for now. > >> > >> commit 140ee0a0bcb280b1a07d98460125cd1523a603ba > >> Author: kapeka <kap...@users.sourceforge.net> > >> Date: Mon Jul 28 20:47:19 2014 > >> > >> update kernel to 3.14.13 > >> > >> kernel 3.14 is the latest longtermn stable kernel, so it might be a > >> good > >> > >> base for 5.2 > >> > >> - PLEASE review the kernel configs! > >> > >> Note: only the i486, i686 and geode kernel has been updated, x86_64 > >> and > >> > >> arm* toolchain will fail because the patches are still on 3.10. > >> > >> Anyway I have up and running a 3.14.13 router (geode) for a while, so > >> > >> those updated seems looking fine. > >> > >> commit 27cafd2bbefef872a730d5321664d417be5beb19 > >> Author: kapeka <kap...@users.sourceforge.net> > >> Date: Sun Jul 27 18:36:48 2014 > >> > >> toolchain add modified buildfiles > >> > >> commit 2c1e59762c62396e9a7f22c54e39c15e71abcac7 > >> Author: kapeka <kap...@users.sourceforge.net> > >> Date: Sun Jul 27 18:30:35 2014 > >> > >> clean toolchain from unnesseray patches > >> > >> add linux-headers in xz format to save some space > >> > >> Note: this are the headers from kernel 3.14.13 > >> > >> commit 0db9f10fda5c357e168f9ce06d86447011a5b4af > >> Author: kapeka <kap...@users.sourceforge.net> > >> Date: Sat Aug 3 14:53:30 2013 > >> > >> copy uuid/uuid.h into staging > >> > >> Most of this commits are for the new kernel 3.14.13. > >> So i think we must create a new topic branch: kernel-3.14.13 (rewriting > >> history to squash the commits about the ipt_netflow) For the commit > >> 0db9f10fda5c357e168f9ce06d86447011a5b4af perhaps it can be cherry-pick on > >> master ? > >> > >> Is it's ok for you i can made the job. > > > > Hi Yves, hi all, > > > > it was me who started the confusion... > > > > After Andrews revert and running > > `git reset --hard origin/next` on next branch > > > > > > I still have a "mixed setup" - next still has a 3.14 kernel.... > > So if you can clean it up for me, pls do! > > > > Anyway, I have been misleaded by the workflow description: > > > > " maint tracks the commits that should go into the next "maintenance > > release", i.e., update of the last released stable version; > > > > master tracks the commits that should go into the next release; > > > > next is intended as a testing branch for topics being tested for stability > > for master." > > > > - "maint tracks the commits that should go into the next "maintenance > > release", i.e., update of the last released stable version;" > > > > This one seems clear to me - it's where we maintain last stable release, > > the one we've put in maintenance mode until master becomes stable > > > > - "master tracks the commits that should go into the next release;" > > > > Again clear to me - stuff we are working on for the next release (:= the > > successor of maint, once it's stable) - it may be companied by topic > > branches > > > > "next is intended as a testing branch for topics being tested for > > stability > > for master" > > > > This is confusing - I thought that is a testbed for the next major > > step/version and could be pretty unstable. > > > > Maybe at the time, where "master" is almost stable and a version and few > > days away of becoming "maint", "next" can be in a state, where it differs > > from "master" significantly... And this the point in time, where we are > > now IMHO. > > > > I haven't used "next" for that stuff in the past, and I dn't know where it > > should be going instead - if "master" more or less ready, but not released > > already, but if so the changes in "next" will go into master, once they > > are > > tested "a testing branch for topics for master"... > > > > > > Ok, stop nitpicking - the correct decision would have been to fork from > > master a 3.14 branch as Andrew did, and once "master" is stable and moved > > to "maint" to merge into the then new master branch, correct? > > Yes it's that KP. > > > Yves, pls try to clean up next from my commits as well - I'll restart > > working with Andrews 3.14 branch, which should have my previous changes > > and his following work? > > > > thx and sorry kp > > No problem KP. Git is a great tool and can easily correct mistakes. > Actually the next branch is clean and is equal to master branch. > > Perhaps is your local next branch that is not clean. Point your local next > branch to the origin/next branch. Like andrew said do: git checkout next > git reset --hard origin/next > > Now you can merge the kernel-3.14 branch into next to continue the tests for > the futur next branch. But never develop directly on the next branch. Use > the topic branches and merge to next branch. When the futur master branch > will be ready, we will merge the topic branches (like kernel-3.14) into the > new master branch.
I'm pretty shure that I followed the steps above, but I'm under the impressions something went wrong and I accidently again committed "sources misusing next" - can anybody confirm, repair and help to avoid the pb in a future update? > PS: about the commit : > commit 0db9f10fda5c357e168f9ce06d86447011a5b4af > Author: kapeka <kap...@users.sourceforge.net> > Date: Sat Aug 3 14:53:30 2013 > > copy uuid/uuid.h into staging > > What can we do with it ? Since it's 1 year old, perhaps it has been merge in > another commit ? I really have no idea anymore - but I'll come across the underlying problem in the future for shure :) Seems I have to add more to the commit messages for later reuse... kp ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
