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. I think your previous proposal with the branches master next maint is worth to think about. Maintenance shall happen in maint/4.3-fixes, only with bugfixes and security updates. 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. next is somewhat experimental and includes features/fixes/updates that may break master and commits target to a new major release. Opinions? 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
