Changes between Version 1 and Version 2 of AddingPackages/Rationale

09/17/09 19:31:58 (8 years ago)
duncan (IP:

Adjust the anchor names now that the rationale is a separate page


  • AddingPackages/Rationale

    v1 v2  
    77Each section of the policy is cross-linked to the explanation on this page and vice-versa. 
    9 == Procedure == #RationaleProcedure 
     9== Procedure == #Procedure 
    1111[[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. 
    22 == Reviewers == #RationaleReviewers 
     22== Reviewers == #Reviewers 
    2424[[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). 
    29 == Updating the proposal == #RationaleUpdatingProposal 
     29== Updating the proposal == #UpdatingProposal 
    3131[[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. 
    40 == Deadlines == #RationaleDeadlines 
     40== Deadlines == #Deadlines 
    4242[[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). 
    49 == Acceptance == #RationaleAcceptance 
     49== Acceptance == #Acceptance 
    5151[[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. 
    64 == Rejection == #RationaleRejection 
     64== Rejection == #Rejection 
    6666[[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. 
    73 == Proposal content == #RationaleProposalContent 
     73== Proposal content == #ProposalContent 
    7575[[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. 
    88 == Package requirements == #RationalePackageRequirements 
     88== Package requirements == #PackageRequirements 
    9090[[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.