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