19.06.2011 14:51, KP Kirchdoerfer пишет: > Andrew; > > Am Sonntag, 19. Juni 2011, 13:16:35 schrieb Andrew: >> 19.06.2011 13:48, KP Kirchdoerfer пишет: >>> Hi Erich; >>> >>> Am Sonntag, 19. Juni 2011, 12:09:36 schrieb Erich Titl: >>>> Hi KP >>>> >>>> on 18.06.2011 23:50, KP Kirchdoerfer wrote: >>>>> Am Samstag, 18. Juni 2011, 22:51:41 schrieb Erich Titl: >>>>>>>>> P.S. Should we store compiled packages into git? Maybe there are >>>>>>>>> more useful places for them (file archive/FTP/etc)? Git is more >>>>>>>>> oriented for source distribution/versioning... >>>>>> IMHO we should leave compiled packages out git, at least out of the >>>>>> main tree, they are a nuisance there, even though it may brake the >>>>>> current release process. >>>>> I'd like to have it in git for at least two reasons: >>>>> >>>>> Using FRS (and probably other upload methods) is a pain. >>>>> The packages page content and the changelog section is created from >>>>> buildtoolcfg files the commit logs (of the binaries) - I don't know a >>>>> way how this can be done with the binaries lying somewhere in the FRS >>>>> and the log files in git. >>>> I have no clue what FRS stands for, but a versioning system is for >>>> things that change, like source, header and config files and, of course, >>>> documentation. It is a nuisance that the binaries are a part of the >>>> development system and show up in the commit info. >>> The FRS is the File Release System of SF; the place where you can >>> download the images. >>> >>> Yes we "abused" the version systems (in the past cvs, today git) to store >>> our binary packages. Adding the binaries into FRS will clutter it even >>> more than it is today. Note that the versions system is the place that >>> we can mostly control ourself - it's just a plain service from SF and we >>> can do almost whatever we like to, mainly a black box for SF. Whereas >>> the FRS and other file related services are under the control of SF and >>> the way they can be accessed, the interfaces etc. change from time to >>> time. Sometimes they are slow, sometimes defunct and every change needs >>> a rework of our processes. "Ab'-using the versions systems has been >>> pretty stable over the years. >>> >>>> One solution might be to put the packages out of the git tree, so no >>>> packages directory under buildtool. It should not disturb the underlying >>>> make structure or whatever is used to build the packages. >>> The binaries are not under buildtool, they are on the same level as >>> buildtool. >>> >>> In the past, and once we are used to work with branches I'll like to see >>> that again, we had put the binaries into cvs. With genpage.pl it was >>> possible to create automatically a "packages page" that had relevant >>> information about packages (from buildtool.cfg), package date, packager, >>> Changelog from binary commits, and a link to the package. >>> Thus it was possible to fetch and download an updated package after it >>> was committed (shorewall with the fast and minor fixes was a good >>> candidate) and before we had build new images. It was a quick and proven >>> method to provide fixes. >>> And while having full control, we could even manage more or less >>> fine-grained upload permissions. Every leaf developer can add binaries >>> and sources (previously in the contrib sections, nowadays more open) >>> uploading via FRS requires admin, or part of, permissions, not easy to >>> deal with and I'd like to avoid. >>> >>> I agree, in theory it does look bad. But then, what are you're real >>> problems having binaries in git? >>> I'm working on LEAF for a few years, used cvs and now git, had binaries >>> side by side with the sources and build system all the time and it never >>> caused any harm for me. >>> >>> kp >> Possible, we should make separate git repository for binaries? :) For >> ex., leaf/binary? > I believe I've already mentioned that before and will give it a try, if you > create the repository and give a short note what I have to do :) > But please don't touch existing bin yet. > This is described on sourceforge: https://sourceforge.net/apps/trac/sourceforge/wiki/Git It requires shell access. >> In that case we 1) will have smaller development repository ( = faster >> time to checkout at first time for developers), and 2) we also can >> reduce directory depth again by removing 'buildtool' level. >> >> Also I think that we should move BuC4 project from default repository >> leaf/leaf to new, for ex., leaf/buc4, for more clear development process >> in case when new LEAF projects (BuC5, or BuC-MIPS with root on squashfs >> for embedded routers, or some thing else) will be started. Of course we >> can do this some later, when it'll be comfortable for other developers, >> but IMHO it should be done before preparing to next release. > Now im getting confused and start to agree with Erich :) > > You've moved everything from bering-uclibc4 to buildtool and bering-uclibc4 is > now empty. Now ask for - what? > It's empty and should be removed (empty dirs aren't present in git). > Please explain your idea a bit more; what is buildtool for? What should be in > bering-uclibc4 and bering-uclibc-foo??? > > As Erich I'd like to have something that stays for more than a few days. > > kp I just removed ine unneeded directory level in path, If we will move binary packages out of the current repository - additional directory 'buildtool' will become unneeded. I want to combine this with moving sources into new repo (with meaning name) in mean that it'll be better if all changes in SCM/buildtool environment should be done at once.
I think that we shouldn't add unnecessary directory levels into path, and we should have internal directory structure level count as small as possible til it toesn't affect anything. ------------------------------------------------------------------------------ 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
