2011/2/8 Gema Ramírez-Sánchez <grami...@gmail.com>: > So, correct if wrong... >
Oh. Yeah. I guess we both forgot when we came to a compromise[1] that we should update the status... [1] If Fran and I can compromise on something, there's hope for Palestine and Israel. > 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? > In this new model, yes, but the [Alpha|Pre]-releases thing is a separate matter. I would also add the caveats that the move from incubator to staging/nursery will only be done: 1) at the request of the maintainer *or* 2) if development has lapsed for a period of not less than two months. (I'm thinking specifically of trying to not cause problems for eo-fr, which should probably just transition straight from incubator to trunk). > 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. > The basic requirements are that it should build without any external effort, contain all basic elements (rule files, modes) even if they're 'dummies', and function, for a very relaxed meaning of 'function' (word to word, generation marks allowed). We want to have a 'safe' area, in which to solicit lexical contributions. Potential contributors should be able to add words, and have those words translate, but they should also be aware that we expect some help in building the rules. > INCUBATOR: would contain pairs with pieces of translators > Well, just pieces. We have some things that are just analysers, with no bilingual component. Hopefully, this will also give a set of clear milestones, so new contributors will have a better idea of the status of their pair, and we'll know when a pat on the back is called for. > 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 >> > -- <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
