Difference between revisions of "PMC proposals/Repository reorganisation"
(→Agree) |
|||
Line 1: | Line 1: | ||
{{TOCD}} |
{{TOCD}} |
||
=2011/02/08 #1: Repository reorganisation= |
=2011/02/08 #1: Repository reorganisation= |
||
<div style="background-color: #eee0e6; margin: 4px; padding: 4px; border: 1px dotted black"> |
|||
'''Proposal passed.''' |
|||
==Summary== |
==Summary== |
||
Line 61: | Line 66: | ||
===Abstain=== |
===Abstain=== |
||
</div> |
Revision as of 19:50, 10 February 2011
2011/02/08 #1: Repository reorganisation
Proposal passed.
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
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.
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.
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)
- I prefer the term 'release candidate' Jacob Nordfalk 08:53, 10 February 2011 (UTC)
Voting
Please note that voting is only open to PMC members. Please vote by signing (~~~) in the relevant section.
Agree
- Agree - Francis Tyers
- Agree - Jimregan
- Agree - Japerez
- Agree - Jacob Nordfalk
- Agree - mlforcada
- Agree - fsanchez
- Agree - sortiz