⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 helping.fml.svn-base

📁 portal越来越流行了
💻 SVN-BASE
📖 第 1 页 / 共 2 页
字号:
                    Feedback from developers regarding a proposed patch is                    really quite                    helpful.                    Don't hesitate to add a "works for me" note to a ticket                    if you've tried the patch yourself and found it useful.                </p>                <p>                    Feature suggestions are also maintained in the                    <a href="#issues">JIRA issue                    tracker.</a>                </p>            </answer>        </faq>        <faq id="contribute">            <question>How can I contribute to the Pluto source                code?</question>            <answer>                <p>                    A very good place to start is by                    <strong>reviewing the list of open issues</strong>                    and pending feature suggestions in the                    <a href="#issues">issue tracker.</a>                    If you see an issue that needs a patch you can write,                    feel free to annex your patch.                    If you seen an issue that needs a unit test to prove its                    fixed,                    feel free to annex your test case.                    If someone has posted a patch to an issue you'd like to                    see resolved,                    apply the patch to your local development copy of Pluto.                    Then let us know if it works for you, and if it does,                    cast your vote for the issue and its patch.                </p>                <p>                    If none of the pending issues scratch your itch,                    another good place to start is by                    <strong>contributing unit tests</strong>                    for existing features (even those that still work).                </p>                <p>                    You can upload a proposed                    <a href="#patches">patch</a>                    to either the code or documentation by creating a feature                    suggestion                    in the                    <a href="#issues">issue tracker.</a>                    <strong>After creating the ticket.</strong>                    you can go back and upload a                    file containing your patch.                </p>            </answer>        </faq>        <faq id="documentation">            <question>How can I contribute to the                documentation?</question>            <answer>            	<p>            	    The same way you contribute to the source code.  All                documentation is generated using maven.              </p>            </answer>        </faq>        <faq id="release">            <question>So when is the next release coming out?</question>            <answer>                <p>                    Here is the truth regarding releases:                </p>                <p>                    Apache products are released on the basis of merit,                    and ~not~ according to a strict timetable.                    The volunteers devote whatever time they can to work                    on                    the product.                    But all volunteers have real jobs and real lives, that                    do                    take precedence.                    Since Pluto does not have paid personnel working on                    the                    project,                    we simply cannot make date-oriented commitments.                </p>                <p>                    The bottom line is that Apache takes releases very                    seriously.                    We do not compromise the quality of our software by                    watching the calendar                    (and then ship something ready or not).                    A release is ready when it is ready.                </p>                <p>                    That may sound flip, but it ~is~ the truth.                    The delivery of production-quality, leading-edge                    software                    is                    not something anyone can prognosticate.                    If anyone tries, they are lying to you.                    That, we won't do ;-)                </p>                <p>                    What we ~will~ do is release all of our development                    software as soon as                    it is developed.                    This way you can judge for yourself how quickly the                    development is                    proceeding, and whether what is being developed will                    meet                    your needs.                    If you need a feature right now, you can use the                    nightly                    build, or roll                    your own patch.                    There are no internal code repositories, private                    development lists,                    secret chat rooms, or conference calls.                    What you see is what we got.                    If you are following the DEV list, then you know                    everything the                    developers know.                    Really, you do.                </p>                <p>                    <em>So, what do you tell your team?</em>                    If you can ship your application based on the nightly                    build of your choice,                    then consider that an option.                    You can still ship yours, even if we don't ship ours,                    and you will have access to all the latest patches or                    enhancements.                    (Just like we were working down the hall.)                    If you can only ship your application based on a                    release                    build of Pluto,                    then you should base your development on the release                    build                    of Pluto,                    and keep an eye on what is coming down the pipeline.                    This way you are at least forewarned and forearmed.                </p>            </answer>        </faq>        <faq id="decides_help">            <question>How can I help make the decisions?</question>            <answer>                <p>                    A guiding principle of the Apache Software Foundation is                    "them that do the work, make the decisions".                    This phrase is actually a double-entendre.                    A project will make some decisions by voting (very few),                    but the real decisions are made when a volunteer actually                    does the                    work.                    Unless someone volunteers to do the work,                    other decisions are meaningless.                </p>                <p>                    In an ASF project, like Pluto,                    volunteers who make sustained contributions to the project                    are invited to become "Committers".                    In due course, Committers are invited to join the Project                    Management                    Committee (PMC).                    A goal of the ASF is for all Committers to be on the PMC.                </p>                <p>                    By "sustained", we mean that an individual has been active                    in the project for at least six months.                    The contributions should come in the form of both patches                    (to code or documentation), and posts to the mailing                    lists.                    Patches must be competent and accepted into the                    repository.                    Posts must be consistently helpful, friendly, and                    collaborative.                    The most important characteristic in a prospective                    Committer is an                    amicable demeanor that fosters goodwill.                </p>                <p>                    As PMC members take note of Portals developers who meet our                    qualifications, one of us will call for a vote on the                    internal                    PMC mailing list.                    (This usually happens when someone gets tired of applying                    the volunteer's patches!)                    The internal list is rarely used, and it is never used for                    development discussions.                    If the PMC vote passes, we will send the developer a                    invitation                    privately, to give the individual a chance to accept or                    discretely                    decline.                    If the candidate is able to accept,                    the PMC will announce the new member on the dev list.                </p>                <p>                    For more about decision-making, see                    <a href="http://apache.org/foundation/how-it-works.html">                        "How the ASF Works"</a>                    and the                </p>            </answer>        </faq>    </part></faqs>

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -