Apertium has moved from SourceForge to GitHub.
If you have any questions, please come and talk to us on #apertium on irc.freenode.net or contact the GitHub migration team.

PMC proposals/Repository reorganisation

From Apertium
Jump to: navigation, search

Contents


[edit] 2011/02/08 #1: Repository reorganisation

Proposal passed.


[edit] Summary

The incubator module in SVN has been quite successful in encouraging the contribution of less developed material; however, the range of development statuses is problematic. In this proposal, we propose to split incubator into incubator, nursery and staging.

The discussion leading to this proposal may be read in this thread.

Proposed by: Jimregan

Seconded by: Francis Tyers

[edit] In detail

trunk would contain pairs in "release" and "[alpha|pre]-release" status, and would exclude unreleased language pairs/software.

staging would contain pairs that build, and have an advanced status in all modules (dictionaries with closed categories 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 an "ISSUES" file which gives an overview of the status of the module, and outlines specific known issues.

nursery would contain pairs that build but that have not been developed to an advanced stage.

incubator would contain pairs with pieces of translators or analysers.

[edit] Caveats

  • This will not operate retroactively: existing pairs under development will not be moved, unless with with the agreement of the developers, or if the pair is deemed to be 'abandoned' (that is, has not been developed for a continuous period of no less than two months).
  • We do not propose to formalise transition between modules: we consider that a matter for separate, later consideration, if it should prove necessary.

[edit] Comments

Comments on the proposal are welcome. Please sign your comments using ~~~~

  • As moving SVN location can be challenging for some (they might have pending commits and non-SVN stuff, such as half-baken stuff, corpa and work files which must be moved), we should make sure that old (even if non-active) developers are aware of the translocation of pairs they have been involved in Jacob Nordfalk 14:33, 9 February 2011 (UTC)
    • Sure. We've had a mass reorganisation before, and made reasonable attempts to inform everyone, IIRC. Jimregan 15:29, 9 February 2011 (UTC)
  • I think that the name "staging" is not descriptive enough (that might be because I am not a native English speaker). I would like to have a more descriptive name to make it easier for newcomers to know what to expect on those language pairs in staging. What about "healthy"? Just to continue with medical slang: incubator, nursery, healthy, trunk --fsanchez 15:04, 9 February 2011 (UTC)
    • 'Staging' is one of those more obscure words, generally. It's a metaphor from the theatre world: it's where the scenery for the next act is assembled, so it can be quickly moved on-stage. It's used in the Linux kernel for drivers that basically work, but are not ready for inclusion in the kernel proper. In that sense, it was the most easily explainable thing I could think of. I'm not sold on the name, just the concept. 'healthy' is a little too positive: it might seem like it's better than 'trunk'. I don't think there is a proper next stage in the incubator/nursery analogy. In a hospital, the incubator is where (usually) premature babies (who can't survive unassisted) are kept, and the nursery is where babies who are almost ready to leave the hospital are kept. Usually, the next stage is 'home'... Maybe 'checkups'? -- Jimregan 15:29, 9 February 2011 (UTC)
    • What about "pre-trunk"? --fsanchez 15:47, 9 February 2011 (UTC)
      • I prefer the term 'release candidate' Jacob Nordfalk 08:53, 10 February 2011 (UTC)
        • With a _space_ in it? - Francis Tyers 11:21, 10 February 2011 (UTC)
        • I should have pasted this comment here too: "I'm going to stay neutral on the matter of the name, but I've already had one 'no, I don't like it'. Changing the name changes the proposal, so those who have voted will have to vote again. How about I change it so that we vote on provisional names, with sub-proposals for the names? If the change doesn't pass in principle, there's no need to decide on a name, but if it does, then we could think about it. We could make the choice of name multiple choice: sign under your preferred option." I think it would probably make a good lesson for future proposals (to omit names entirely, and to concentrate on the concept) but as it stands, for better or for worse, this proposal includes the names, so if you really dislike the name, I suggest you vote against the proposal, and/or submit a counter-proposal. -- Jimregan 11:46, 10 February 2011 (UTC)

[edit] Voting

Please note that voting is only open to PMC members. Please vote by signing (~~~) in the relevant section.

[edit] Agree

[edit] Disagree

[edit] Abstain

Personal tools