Re: [leaf-devel] git branches
Le 27 juil. 2013 à 20:08, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Am 27.07.2013 19:31, schrieb Yves Blusseau: Le 27 juil. 2013 à 11:11, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Well, seems a problem is that we have developed two different concepts and naming schemes over time, which are not in sync. See: http://leaf.sourceforge.net/bering-uclibc/index.php?module=pagemasterPAGE_user_op=view_pagePAGE_id=8MMN_position=8:8 Not really a problem. We must have a branch for the next release (it's the master branch). The old branch has been released so only bugfix must be done in it. You're right. So in our case 5.0.0 is release, it's now a maintenance branch. So we must release only bug fix in it). The 5.0.1 or 5.1.0 or 6.0.0 is the new master branch that will be the next release. Also where do we draw the line between feature and maintenance? Moving from libnl to libnl3 is rather a feature than a bugfix. But what about package updates, like shorewall, dnsmasq etc where fixes are provided as well as new features? This must be in the master branch. For example updating shorewall must be made between 5.0.1 and 5.0.2. 5.0.1 is the master branch. We update it with shore wall update. When 5.0.2 is released, 5.0.2 will be the new master branch and 5.0.1 the new maintenance branch. You mean when 5.0.*1* is released? Yes sorry Everything you update is for the NEXT release, so it must be done in the master branch. The maint branch is only to correct bug for people using the last released version. But maint branch must not be update with new version of package, etc… only if it fix a big bug. (so as a consequence, IF we'd have a real bug in 5.0.0 we'll be able to create 5.0.0.1. If so the page linked above should note that.) Yes it's that. What we can do also is that the master stay in the major release and rename master branch only on new major release (change in one of the first two digits). So 5.0.1 stay master and 4.0.3 stay as maint When 5.1 or 6.0 will be released 5.1 we will change the master branch to the next version. 5.0.1 is only a minor release so we don't need to maintain 5.0 branch. Perhaps it's more easier like this. We only have to tag version in git when we release the tarball. Yves -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] repalcing syslinux.dpy with our new logo
Hi Andrew; Am 27.07.2013 21:37, schrieb Andrew: 27.07.2013 22:31, KP Kirchdoerfer пишет: Am 27.07.2013 20:21, schrieb Andrew: Main question is compatibility with VGA-less systems. AFAIK grub 0.97 has some troubles with graphical splash on systems w/o VGA adapter. Any idea how to test in a virtual environment? I ran qemu qith option -curses and it worked, but I think more is needed. IMHO it's simplier to run image on some old PC. Or even on ALIX w/o VGA. Also ALIX should show in console what's really happens on boot. It should be a lot easier than I thought yesterday. We already have the variants vga and serial when building images and different syslinux.cfg files. So the vga variant for syslinux.cfg/isoliunx.cfg can be modified to start a graphical bootmenu, while the serial ones can stay as-is, or updated to a text based menu. The drawback will be the addition of unnecessesary jpg and vesamenu.c32 (sums up to 200kb) for the serial variants. If no troubles will be noticed - IMHO 1-2 seconds splash screen delay isn't a showstopper. I think about 3-5sec so the user has some time to press any key. We'll win a second or two, if we add the kernel option quiet - I did for 4.0, but forgot for 5.0 :( kp 3-5 seconds - I'm not sure that it's actually needed, at least - on default syslinux image (CD may have bigger delay). Any keypress stops timer. IMHO 2 seconds for syslinux will be enough. You're faster than I am :) kp -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] repalcing syslinux.dpy with our new logo
28.07.2013 13:35, KP Kirchdoerfer пишет: Hi Andrew; Am 27.07.2013 21:37, schrieb Andrew: 27.07.2013 22:31, KP Kirchdoerfer пишет: Am 27.07.2013 20:21, schrieb Andrew: Main question is compatibility with VGA-less systems. AFAIK grub 0.97 has some troubles with graphical splash on systems w/o VGA adapter. Any idea how to test in a virtual environment? I ran qemu qith option -curses and it worked, but I think more is needed. IMHO it's simplier to run image on some old PC. Or even on ALIX w/o VGA. Also ALIX should show in console what's really happens on boot. It should be a lot easier than I thought yesterday. We already have the variants vga and serial when building images and different syslinux.cfg files. So the vga variant for syslinux.cfg/isoliunx.cfg can be modified to start a graphical bootmenu, while the serial ones can stay as-is, or updated to a text based menu. The drawback will be the addition of unnecessesary jpg and vesamenu.c32 (sums up to 200kb) for the serial variants. In any case, syslinux-vga image with graphic screen should be tested without vga card. And, if troubles were notified, they should be mentioned in wiki at least. If no troubles will be noticed - IMHO 1-2 seconds splash screen delay isn't a showstopper. I think about 3-5sec so the user has some time to press any key. We'll win a second or two, if we add the kernel option quiet - I did for 4.0, but forgot for 5.0 :( kp 3-5 seconds - I'm not sure that it's actually needed, at least - on default syslinux image (CD may have bigger delay). Any keypress stops timer. IMHO 2 seconds for syslinux will be enough. You're faster than I am :) kp -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git branches
Am 28.07.2013 10:47, schrieb Yves Blusseau: Le 27 juil. 2013 à 20:08, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Am 27.07.2013 19:31, schrieb Yves Blusseau: Le 27 juil. 2013 à 11:11, KP Kirchdoerfer kap...@users.sourceforge.net a écrit : Well, seems a problem is that we have developed two different concepts and naming schemes over time, which are not in sync. See: http://leaf.sourceforge.net/bering-uclibc/index.php?module=pagemasterPAGE_user_op=view_pagePAGE_id=8MMN_position=8:8 Not really a problem. We must have a branch for the next release (it's the master branch). The old branch has been released so only bugfix must be done in it. You're right. So in our case 5.0.0 is release, it's now a maintenance branch. So we must release only bug fix in it). The 5.0.1 or 5.1.0 or 6.0.0 is the new master branch that will be the next release. Also where do we draw the line between feature and maintenance? Moving from libnl to libnl3 is rather a feature than a bugfix. But what about package updates, like shorewall, dnsmasq etc where fixes are provided as well as new features? This must be in the master branch. For example updating shorewall must be made between 5.0.1 and 5.0.2. 5.0.1 is the master branch. We update it with shore wall update. When 5.0.2 is released, 5.0.2 will be the new master branch and 5.0.1 the new maintenance branch. You mean when 5.0.*1* is released? Yes sorry Everything you update is for the NEXT release, so it must be done in the master branch. The maint branch is only to correct bug for people using the last released version. But maint branch must not be update with new version of package, etc… only if it fix a big bug. (so as a consequence, IF we'd have a real bug in 5.0.0 we'll be able to create 5.0.0.1. If so the page linked above should note that.) Yes it's that. What we can do also is that the master stay in the major release and rename master branch only on new major release (change in one of the first two digits). So 5.0.1 stay master and 4.0.3 stay as maint When 5.1 or 6.0 will be released 5.1 we will change the master branch to the next version. 5.0.1 is only a minor release so we don't need to maintain 5.0 branch. Perhaps it's more easier like this. We only have to tag version in git when we release the tarball. Yves Yes, sounds easier and more towards how we do releases. I'm keen to tag versions when doing a new release, so that won't be a problem. A question, possibly asked before, how do we keep branches like next in sync with master/maint? E.g. I'd like to publish my work on new boot menu into something else than master so it's available for testing, but don't harm master if something is wrong. Branch next would be a good place, but I assume it's that outdated that doing a test within this branch may not give results I expect; the same is true for pu, and will happen with other branches. In the wiki docs you've written that updating branches like next habitually is not recommended. So whats the recommended way to keep branches in sync? kp -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
