Am Montag, 20. Juni 2011, 01:38:59 schrieb Mike Noyes: > On Mon, 2011-06-20 at 00:23 +0200, Erich Titl wrote: > > Hi KP > > > > on 19.06.2011 20:48, KP Kirchdoerfer wrote: > > ... > > > > > - the current leaf/leaf repository consists now only of the > > > "buildtool", the environment (buildtool, sources and build helpers) > > > for Bering-uClibc4. > > > > > > Andrews proposal is to (once again and hopefully finally) move all the > > > current "buildtool" content to a more speaking name: bering-uclibc4 > > > directory. That way we may add more directories for development under > > > leaf/leaf, like bering-uclibc5, bering-uclibc-mips, > > > bering-uclibc-experimental..., developement trees, which may be added > > > if branching gets too complicated, or to give other LEAF variants a > > > place to live. > > > > > > > > > Is that we can all agree with? > > > Erich? > > > > As long as bering-uclibc4 is not the parent of bering-uclibc5 as > > mentioned above. I woudl use something more neutral as the top level and > > use GIT as the branch manager. > > Everyone, > I'd prefer us to move bering-uclibc to its own repository, and retain > leaf for common packages (cvs examples: sourceforge, doc, etc.). Does > this sound like a reasonable/logical split that will avoid > confusion/future-problems? > > http://leaf.git.sourceforge.net/ > > leaf leaf > leaf packages > leaf bering-uclbic
Andrew wrote: > I mean repository for each new project that is slightly differ from > other, or that will require different access rights, or that shouldn't > take advantage from 'git rebase' due to very different > versioning/software. Or for new version if old one becomes unsupported. > In two words - this is for projects/versions that can't/shouldn't > interact with other branches by any reason. > I think that BuC5 may become one of such projects (major version IMHO > will be changed only due to heavy modification of toolchain/software > that'll cause incompatibility with old manuals/packages). For ex., if > we'll move building code from buildtool to makefiles, or different > building system. and Erich wrote: > As long as bering-uclibc4 is not the parent of bering-uclibc5 as > mentioned above. I woudl use something more neutral as the top level and > use GIT as the branch manager. Ok; Mikes proposal sounds reasoanble and I think a repository each leaf project is a way to go. In the repository we can one or more directories := different major versions of a project. In the past Bering-uClibc major version changed mostly when uClibc changed significantly and broke binary compatibility, the second version number was reserved for major updates, esp. kernel updates, the third for fixes. The last two can be handled with branching in the directory. I read the man page for "git rebase" and it talks about branches Bering-Uclibc 5 will introduce maor changes (uClibc, buildtool), but as long as it's an evolutionary process and the developers agree to build together a new version while maintaining the old. *If* there will be disagreement about the future, Bering-uClibc5 may be forked and put into a new repository as a completly different project. Like Bering-uClibc was a fork of Bering, and therefor a new LEAF project. So we'll have the repositories: leaf/leaf leaf/Bering (if there would be further development) leaf/Bering-uClibc leaf/packages (for binaries) ... in the repository leaf/bering-uclibc we could have the directories bering-uclibc4 (today buildtool) bering-uclibc5 bering-uclibc-mips ... as I said as long as the developers agree to work together and therefor should be interested to push and pull also from new directories. In the leaf/bering-uclibc/bering-uclibc4 directory we can have two or three remote branches master with the latest development tree leading to 4.1 or whatever 4_0_1 with fixes and security updates for 4.0 later 4_1_1 with fixes for 4.1 I'm not shure about remote branches (how to tag, when to delete...), what be in the end the stable versions (4.0 or 4.0.1) once we stop working on 4.0.x...? But I guess this can be figured out and learned in the process. If we do agree, I'm creating the new bering-uclibc repository and everyone should have a clean local git so moving from leaf/leaf/buildtool to leaf/bering-uclibc/bering-uclibc4 does not harm too much. (Though I'm not shure if this works as seamless as I hope.) kp ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
