Changes between Version 1 and Version 2 of AddingPackages/Rationale
- Timestamp:
- 09/17/09 19:31:58 (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AddingPackages/Rationale
v1 v2 7 7 Each section of the policy is cross-linked to the explanation on this page and vice-versa. 8 8 9 == Procedure == # RationaleProcedure9 == Procedure == #Procedure 10 10 11 11 [[wiki:AddingPackages#Procedure rationale-1.1]] There is inevitably some ongoing maintenance work for each package. The platform release team cannot be expected to pick up maintenance of platform packages; it is not their job and it would not scale. We therefore require that each package has a commitment from its own maintainer(s). Dedicated maintainers are also in a better position to address bug reports and make improvements to the package. It is fine for the maintainer(s) to get help with the proposal process but they must support the proposal and by implication be prepared to maintain the package once it is in the platform. … … 20 20 21 21 22 == Reviewers == #R ationaleReviewers22 == Reviewers == #Reviewers 23 23 24 24 [[wiki:AddingPackages#Reviewers rationale-2.1]] A disadvantage of having the review process be open to everyone is that we cannot require anyone to actually spend the effort to do any review. One way to encourage review is to raise its status by giving prominent credit to reviewers. This simple idea has been tried with limited success in other open source communities (such as the Linux kernel developer community). … … 27 27 28 28 29 == Updating the proposal == # RationaleUpdatingProposal29 == Updating the proposal == #UpdatingProposal 30 30 31 31 [[wiki:AddingPackages#Updatingtheproposal rationale-3.1]] A problem with mailing list discussions about a document is that it can sometimes be hard to get a clear view about which changes have been accepted, especially for people who are late to join the discussion. By keeping the latest version in a wiki page this problem can be avoided. On the other hand a wiki is not suited to conversations. By using a combination of a mailing list discussion for detailed review and a wiki page to record the latest version, it is hoped to get the best of both mediums. … … 38 38 39 39 40 == Deadlines == # RationaleDeadlines40 == Deadlines == #Deadlines 41 41 42 42 [[wiki:AddingPackages#Deadlines rationale-4.1]] Reviewers need a reasonable amount of time to properly review packages. Since there is a cut-off for when decisions must be made, there must also be a cut-off for when proposals must be submitted otherwise there would not be enough time to review packages properly. On the other hand there is no earliest point when proposals can be submitted, this allows for an extended review period at the discretion of the proposer(s). … … 47 47 48 48 49 == Acceptance == # RationaleAcceptance49 == Acceptance == #Acceptance 50 50 51 51 [[wiki:AddingPackages#Acceptance rationale-5.1]] The package must be accepted before the deadline to give the release team enough time to integrate the package into the platform. … … 62 62 63 63 64 == Rejection == #R ationaleRejection64 == Rejection == #Rejection 65 65 66 66 [[wiki:AddingPackages#Rejection rationale-6.1]] Packages should not be accepted until the reviewers have reached consensus to make sure issues are addressed and that the package has the general support of the community. … … 71 71 72 72 73 == Proposal content == # RationaleProposalContent73 == Proposal content == #ProposalContent 74 74 75 75 [[wiki:AddingPackages#Proposalcontent rationale-7.1]] Listing the author and maintainer is useful simply as contact information for the release team or future readers. The maintainer should be listed as an indication that they are signing up to support the package and its inclusion in the platform. The latter is particularly relevant when they are not one of the authors of the proposal. The proposal author should also be listed to indicate that the document does indeed have an author who will take responsibility for updating it. Also, the proposal author deserves credit for the effort they put in. … … 86 86 87 87 88 == Package requirements == # RationalePackageRequirements88 == Package requirements == #PackageRequirements 89 89 90 90 [[wiki:AddingPackages#Packagerequirements rationale-8.1]] As a matter of practicality all packages need to use the Cabal package format. This is because the release team use automated tools to manage the platform release. Similarly most distro packaging people use similar tools to automate the translation of Cabal packages to native distro packages. The release team and the distro packaging teams can only manage reasonable numbers of packages by using these automation tools.
