Re: [leaf-devel] Misused of next branch
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
Re: [leaf-devel] Misused of next branch
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
