So, correct if wrong... TRUNK: would contain pairs in "release" and "[alpha|pre]-release" status an no pair without a release.
STAGING: would contain pairs that builds and have an advanced status of all modules (dictionaries with closed cathegories and a decent coverage, an "ad hoc" PoS tagset and .prob, good coverage of main contrastive phenomena, testvoc clean, and a post-generator if needed). There should be a "PROBLEMS" file saying, IMO, status and major problems found while reading translations done with this pair (so, not a complete evaluation but a general compilation of big problems detected at the output). That could be a middle solution between Fran and Jim point of view. Would [Alpha|Pre]-releases also be allowed for pairs in staging? NURSERY: would contain pairs that build but that have not been developed deeply or maybe data copied from other pairs that needs work or very poor data on some modules, etc. INCUBATOR: would contain pairs with pieces of translators I like the idea in general, how should we go ahead? making a proposal and submitting it to the PMC? r. Gema. On Tue, Feb 8, 2011 at 4:47 PM, Francis Tyers <fty...@prompsit.com> wrote: > El dt 08 de 02 de 2011 a les 15:30 +0000, en/na Jimmy O'Regan va > escriure: >> 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. > > True. > >> >> 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. > > I think (2) is a good option. :) > >> [1] Ok, not quite true: Beer, metal, Free Software FTW!, Macs are >> pretty but the OS sucks. Have I missed anything? > > :D > > Fran > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
