Apropos the earlier discussion with dmalloc, I've been thinking about
some of the current hurdles for the submissions process and what we'd
want in a new submissions engine
1) Version control. Being able to generate diffs with prior versions
of a submission would be useful for both the submitter and the
developer-validator.
2) Larger file size limit. We could cut the time it takes me to
validate a package significantly if submitters uploaded their logs from
builds on a production Fink system. That way I often could just build
on a clean Fink tree. The SF.net tracker's size limit doesn't allow for
big logs.
3) Not mangling text files.
4) A structured submission form which is specific to our needs. Right
now things are too free-form. Sometimes there are .info and .patch
files, sometimes only a .info and the .patch has to be copied from the
existing Fink tree, somtimes a tarball (to avoid the aforementioned
mangling of text files, which messes with the MD5 sums of PatchFiles).
One of the current crop has the .info, .patch, and a build log all
concatenated into one file. It would be better if we had our own list
of files that had to be attached to every submission, e.g: .
.info
.patch or click a button to indicate that no .patch is needed
build log
(and others)
5) Easier remote access. If the .info and .patch files for current
submissions all went into a common directory that could be checked out,
that would definitely speed things up.
Anyway, that's the basics of what I think would give us a system that's
more usable for both submitters and validators.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
fink-core mailing list
fink-core@...
http://news.gmane.org/gmane.os.apple.fink.core
