On Sun, 2011-06-19 at 12:48 +0200, KP Kirchdoerfer wrote: > The FRS is the File Release System of SF; the place where you can download > the > images.
Everyone, Release Files for Download (FRS) http://sourceforge.net/apps/trac/sourceforge/wiki/Release%20files%20for%20download The FRS supports sub-directories now, however it isn't setup for easy download scripting. http://sourceforge.net/apps/trac/sourceforge/ticket/18740 http://sourceforge.net/apps/ideatorrent/sourceforge/?keywords=&tags=download > 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. See sub-directory support: > 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. At least git understands binaries, unlike cvs. > > 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. We could make a separate git repository for binaries as a temporary fix. Creating Multiple Repositories http://sourceforge.net/apps/trac/sourceforge/wiki/Git#CreatingMultipleRepositories > 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. -- Mike Noyes http://sourceforge.net/users/mhnoyes http://www.google.com/profiles/mhnoyes ------------------------------------------------------------------------------ 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
