On 8 February 2011 15:02, Francis Tyers <fty...@prompsit.com> wrote: > El dt 08 de 02 de 2011 a les 14:53 +0000, en/na Jimmy O'Regan va > escriure: >> That's the problem, though. If we want feedback, saying 'get it from >> SVN' really reduces the amount of people who /can/ give us feedback. > > Hmm, I hadn't thought about that. Are there people who are capable of > installing/compiling Apertium etc. from source .tar.gz, but not from > source in SVN ? >
'Capable of' is a matter of argument. Certainly, the vast majority of casual SVN users would balk at following the stock instructions on sourceforge to find that they'd just pulled down 5 gigs. >> > To be eligible for inclusion I would say that aside from the 'PROBLEMS >> > file, it should also include an preliminary evaluation of translation >> > quality (af-nl, ca-sc, pl-cs, sme-nob) have this. >> >> IMO, that defeats the purpose. It would make sense to have this >> restriction on 'alpha' releases, though. > > I don't think it defeats the purpose so much. Doing a preliminary > evaluation is less than a day's work, where finishing a testvoc might be > a couple of weeks. I think things in staging should have some kind of > eval. Even if it is just 30 sentences -- and even if it is automatic > (from a parallel corpus or something). If you've got time to write a > 'PROBLEMS' file, you've got time to do that. > >> The primary motivation I had in proposing this was that we have a >> current need to distinguish between the modules that can be checked >> out, built, and which can provide a basic word to word translation >> (i.e., which a newcomer can add vocabulary to and expect to see that >> vocabulary translate in some manner, regardless of correctness), and >> those that can't. > > Agree. But there are several pairs that fall into this that I wouldn't > call "staging". You can get basic word-for-word translations with > no-en, but it isn't something that I would put in staging yet -- far too > much testvoquing left to do. And fo-is too, but that lacks coverage. > Those are exactly the things I want to consider. >> I don't want to go quite to that extreme, but there >> should be a happy medium between that extreme and yours. > > Agree. Overall, I think "staging" should be for things that have the > prospect of being released after say, a few weeks (rather than a few > monts) of concerted effort by a newcomer. Still not close enough to be worth the effort, IMO, but as we never agree on any set of details[1], ever, rather than derail the discussion, we should probably consider either: 1) You write a counter-proposal, and we'll handle this like a proper bur^H^H^Hdemocracy 2) We prepare a 'scale of preparedness' and get... somebody else's input. [1] Ok, not quite true: Beer, metal, Free Software FTW!, Macs are pretty but the OS sucks. Have I missed anything? -- <Leftmost> jimregan, that's because deep inside you, you are evil. <Leftmost> Also not-so-deep inside you. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
