Hi Yves; took some time to respond, cause I've updated my router to latest changes, and esp. splitting initrd into initrd and initmod needed some precautions before I lose connection at all (mainly because I had to update syslinux, which was easy in the end).
Am 02.08.2012 22:23, schrieb Yves Blusseau: > > Le 2 août 2012 à 19:01, KP Kirchdoerfer a écrit : > >> Am 31.07.2012 19:33, schrieb Yves Blusseau: >>> >>> Le 31 juil. 2012 à 17:35, KP Kirchdoerfer a écrit : >>> >>>> Hi Yves; >>>> >>>> I've looked into the links you've send and start to get it. Though I >>>> dislike the graphs that try to explain something which is IMHO pretty >>>> clear, *once* one understood it, and less helpful before. (Not your fault!) >>>> >>>> Am 31.07.2012 09:36, schrieb Yves Blusseau: >>>>> Le 30/07/2012 19:46, KP Kirchdoerfer a écrit : >>>>>> Though a short note about what we have done over the weekend, maybe not >>>>>> in the best way. >>>>>> >>>>>> 4.3 has been tagged and released. A new branch for 4.3-fixes has been >>>>>> created. So 4.3 (and 4.x) has put into maintenance mode. >>>>>> The next branch has been merged into master, because master now is >>>>>> targeting to 5.0. The next branch is now obsolete and if possible could >>>>>> be even removed/deleted. >>>>>> >>>>>> kp >>>>> Hi kp and all developpers, >>>>> Perhaps it will better to have 4 branches like the git project has: >>>>> 'master', 'next', 'pu' (proposed updates) and 'maint' for maintenance >>>>> backports (see Large-Merging Workflows in >>>>> http://git-scm.com/book/ch5-3.html). >>>>> So we can merge (rebase) our contributions in 'next' branch (will be the >>>>> developpement branch). >>>> >>>> Which is inline with your proposal in the mail that started the thread? >>> Yes next branch is inline and we rebase our contributions on top of next >>> branch >>> >>>> >>>>> 'master' branch only move fast-forward and contain only current latest >>>>> tag version. >>>>> 'maint' branch is used to add bug fixes, security updates for last >>>>> stable version. >>>> >>>>> So for example, in our case, we would have: >>>>> master (tag: 5.0-beta1) >>>>> next (contributions above 5.0-beta1) >>>>> maint (tag: 4.3) >>>> >>>> So master is merged (or rebased?) from next while/when a release is >>>> prepared? >>> Yes next is rebase on top of master when a new release is prepared. >>> >>>> Will anything committed to master at all? And if so, what commits will >>>> go into master? >>>> >>> No we didn't commit directly on master. Master is always the last stable >>> version. >>> >>>> >>>> The three branches are now already there (though "maint" is currently >>>> called 4.3-fixes, which can be fixed at least with 5.0). >>>> As long as master is almost compatible with next (e.g. uClibc version is >>>> API compatible, etc) I can imagine this approach will work. >>>> >>>> Can you provide an example, how it looks like, if there are major >>>> changes in next, as in the past month, where we maintained the 4.x >>>> series in master and developed major changes in next? >>> >>> Here's how git project use theirs branches: >>> >>> There are four branches in git.git repository that track the source tree >>> of git: "master", "maint", "next", and "pu". >>> >>> The "master" branch is meant to contain what are very well tested and >>> ready to be used in a production setting. Every now and then, a "feature >>> release" is cut from the tip of this branch and they typically are named >>> with three dotted decimal digits. The last such release was 1.7.11 done on >>> Jun 17, 2012. You can expect that the tip of the "master" branch is always >>> more stable than any of the released versions. >>> >>> Whenever a feature release is made, "maint" branch is forked off from >>> "master" at that point. Obvious, safe and urgent fixes after a feature >>> release are applied to this branch and maintenance releases are cut from >>> it. The maintenance releases are named with four dotted decimal, named >>> after the feature release they are updates to; the last such release was >>> 1.7.11.1. New features never go to this branch. This branch is also >>> merged into "master" to propagate the fixes forward. >>> >>> A new development does not usually happen on "master". When you send a >>> series of patches, after review on the mailing list, a separate topic >>> branch is forked from the tip of "master" and your patches are queued >>> there, and kept out of "master" while people test it out. The quality of >>> topic branches are judged primarily by the mailing list discussions. >>> >>> Topic branches that are in good shape are merged to the "next" branch. In >>> general, the "next" branch always contains the tip of "master". It might >>> not be quite rock-solid, but is expected to work more or less without major >>> breakage. The "next" branch is where new and exciting things take place. A >>> topic that is in "next" is expected to be polished to perfection before it >>> is merged to "master". >>> >>> The "pu" (proposed updates) branch bundles all the remaining topic >>> branches. The topics on the branch are not complete, well tested, nor well >>> documented and need further work. When a topic that was in "pu" proves to >>> be in testable shape, it is merged to "next". >>> >>> You can run "git log --first-parent master..pu" to see what topics are >>> currently in flight. Sometimes, an idea that looked promising turns out >>> to be not so good and the topic can be dropped from "pu" in such a case. >>> >>> The two branches "master" and "maint" are never rewound, and "next" >>> usually will not be either. After a feature release is made from >>> "master", however, "next" will be rebuilt from the tip of "master" >>> using the topics that didn't make the cut in the feature release. >>> >>> Note that being in "next" is not a guarantee to appear in the next >>> release, nor even in any future release. There were cases that topics >>> needed reverting a few commits in them before graduating to "master", >>> or a topic that already was in "next" was reverted from "next" because >>> fatal flaws were found in it after it was merged. >>> >>> >>> In our case (BuC) we don't use mailing list to send and review patches. If >>> we think that our contributions are in good shape we can directly rebase >>> them on top of the 'next' branch. For experimentation it's better to rebase >>> on top of "pu" branch and when it's pretty good, rebase on top of the >>> 'next' branch. >>> >>> I hope this can help you to understand the process. >> >> Hi Yves; >> >> thx - I understand the process for git program, and it sounds well thought. >> But this is IMHO valid for source code only, that has less variables >> than our distribution based process. >> >> With "variables" I mean >> a) uclibc version, which breaks API compatibility - aka our first number >> in the versioning scheme >> b) the kernel version, which breaks kernel-dependent packages - aka our >> second number >> c) maintenance and new features for a version with a given uClibc and >> kernel version - aka the third number in our versioning scheme. >> >> So for example we can't simply rebase master to maint once a release is >> done. >> > > No master is never rebase into maint, but urgent safe fix can be apply to the > maint branch (that is the previous last major version of BuC (in our case > 4.3)). > So for example if a big security issue is found we can create and release a > 4.3.1 version to fix it. > This release will be tag in maint branch only. > After that we MUST merge the branch "maint" into the "master" branch to be in > sync with the old release (the branch "master" is a descendant of the "maint" > branch) That's something I do not understand (:= I still have not the ful picture how git works) maint is still 4.3, and master is something very different. Won't a merge from maint into master overwrite other changes, or generate a lot of errors - guess not, but it's still confusing. >> >> Maintenance shall happen in maint/4.3-fixes, only with bugfixes and >> security updates. >> > Yes. > So if an update is needed into the maint branch, commit all the patches in > it, update the version and tag the branch then merge the maint branch into > the master branch: > > git checkout maint > git pull --rebase -p > # apply fixes and commit them. check if the version can be released. > # increment the third number in the versioning scheme (like 4.3 -> 4.3.1) and > tag the branch maint with this number > git tag -a -m "Release of LEAF Bering-uClibc 4.3.1" v4.3.1 > # populate the "maint" branch to repository > git push > git push origin v4.3.1 > > # Now we MUST sync the maint branch into the master branch (so master branch > is ALWAYS a superset of the maint branch) > git checkout master > git pull --rebase -p > git merge maint -m "sync with 4.3.1" > # populate the "master" branch to the repository > git push > > >> master is the latest released version (identified by a tag) plus >> "stable" updates and fixes for the new version until it it is released a >> a final version. Then it can be rebased/merged into maint. >> > Yes, when a a new version is good to be release we tag it into the master > branch. > git checkout master > git pull --rebase -p > # bump the version number then create a commit for the new release > git commit -a -m "BuC 5.0-rc2" > git tag -a -m "Release of LEAF Bering-uClibc 5.0-rc2" v5.0-rc2 > git push > git push origin v5.0-rc2 > > When a major release (one of the 2 first number in the versioning scheme > change) is ready we tag the master (like a minor release above), but we merge > the latest stable release into the "maint" branch which should result in a > fast forward if we always merge new commits in maint into the master. > Example for a major release 5.0.3 -> 5.1: > > # First merge the old major stable release into the maint branch > git checkout maint > git pull --rebase -p > git merge --ff-only v5.0.3 # This should result in a fast forward ONLY if all > fixes on maint where merge into master > > # Now tag the new release in the master branch > git checkout master > git pull --rebase -p > # bump the version number then create a commit for the new release > git commit -a -m "BuC 5.1" > git tag -a -m "Release of LEAF Bering-uClibc 5.1" v5.1 > git push > git push origin v5.1 > >> next is somewhat experimental and includes features/fixes/updates that >> may break master and commits target to a new major release. > Exactly > And we need to regulary rebase the "next" branch from the "master" branch to > include new stable updates (from master) into the experimental branch ("next" > branch). > > If you think it's a good start i can write a workflow guideline. I think it sounds like it's a good start :) Let's see if other developers will join the discussion, esp Andrew who has more experience with git, and managed the move from cvs to git last year. A workflow guideline would be more than useful. Can you add it to wiki directly - David wrote http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_-_Developer_Guide_-_Hints_and_Tips_for_using_Git_SCM maybe that's a good place for the guildeline. kp ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
