19.06.2011 22:49, Mike Noyes пишет: > On Sun, 2011-06-19 at 21:36 +0200, KP Kirchdoerfer wrote: >> Am Sonntag, 19. Juni 2011, 21:18:23 schrieb Mike Noyes: >>> On Sun, 2011-06-19 at 22:06 +0300, Andrew wrote: >>>> 19.06.2011 21:48, KP Kirchdoerfer пишет: >>>>> 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. >>>> No, I mean a new repository, not directory. For ex., leaf/BuC4, in >>>> future - leaf/BuC5 and so on. >>>> IMHO it'll be more adequate: one project - one repository. >>> Andrew, >>> Agreed. One repository for each LEAF branch/sub-project. This will allow >>> project lead developers and teams better control of repository content. >>> >>> Note: I'm not sure if there are limits on git repository >>> creation imposed by SF. >> Mike you talk about LEAF/sub-project like Bering-uClibc, lince, >> whatever? I do agree. > KP, > Correct. LEAF branches. > > Branch Derivation > http://leaf.sourceforge.net/images/pagemaster/release-branch-flow.png > > >> Andrew, why? >> >> We can branching with git (and I think a lot can be done that way), we >> can have seperate directories on top of branches (like bering-uclibc4, >> bering-uclibc5). Why should we create repositories? >> >> Directories and branches can be created by every developer. >> Repositories needs admin work. >> >> A Bering-uClibc developer pulling /leaf/leaf gets all of the >> Bering-uClibc directories, but then why should a Bering-uClibc >> developer be concerned to have those in his tree? >> >> Maybe the repository name "leaf" is misleading and should be renamed >> to Bering-uClibc, where the directories Bering-uClibc4, Bering-uClibc5 >> etc lives? 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.
------------------------------------------------------------------------------ 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
