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. > 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? 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 ------------------------------------------------------------------------------ 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
