请选择 进入手机版 | 继续访问电脑版

risc-v中文社区

 找回密码
 立即注册
查看: 597|回复: 2

[原创] telnet for java

  [复制链接]

345

主题

561

帖子

2045

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2045
发表于 2022-10-18 08:57:49 | 显示全部楼层 |阅读模式
Project Guidelines
Note
These project guidelines have been adapted from the Jakarta Project Guidelines (as well as their working proposal), which you can find at:
http://jakarta.apache.org/site/guidelines.html
http://jakarta.apache.org/site/proposal.html

Modifications were required to adapt the wording to a single non-Jakarta project (i.e. not subproject, and not subject of supervision by the PMC).
The material is copyright by the jakarta project of the Apache Foundation and is published with permission from the PMC.
Overview
This document defines the guidelines of the project. It includes definitions of the various categories of membership, who is able to vote, how conflicts are resolved by voting and the procedures to follow for proposing and making changes to the codebases of the project.

Roles and Responsibilities
The roles and responsibilities that people can assume in the project are based on merit. Everybody can help no matter what their role. Those who have been long term or valuable contributors to the project obtain the right to vote and commit directly to the source repository.
Users
Users are the people who use the products of this project. People in this role aren't contributing code, but they are using the products, reporting bugs, making feature requests, helping other users, extending an online FAQ and such. This is by far the most important category of people as, without users, there is no reason for the project.
When users start to contribute code or documentation patches, they become contributors.

Contributors
Contributors are the people who write code or documentation patches or contribute positively to the project in other ways. A volunteer's contribution is always recognized. In source code, all volunteers who contribute to a source file may add their name to the list of authors for that file.

Committers
Contributors who give frequent and valuable contributions to the project can have their status promoted to that of a "Committer". A committer has write access to the source code repository and gains voting rights allowing them to affect the future of the project.
In order for a Contributor to become a Committer, another Committer can nominate that Contributor or the Contributor can ask for it. Once a Contributor is nominated, all of the Committers of this project will vote. If there are at least 3 positive votes and no negative votes, the Contributor is converted into a Committer and given write access to the source code repository for the project.
Before receiving write access, a Committer must also affirm that they have read and understood these guidelines, and agree to abide by their terms, as they may be revised from time to time.
At times, Committers may go inactive for a variety of reasons. A Committer that has been inactive for 6 months or more may lose his or her status as a Committer.
A list of some of our current Committers can be found in our project credits.

Release Manager
Product releases will be managed by a selected committer. A release manager should actively manage the release process, watch the deadlines, release and make announcements.


Communications
The project obtains its strength from the communication of its members. In order for members to easily communicate with each other, the project has mailing lists as well as discussion fora.
These lists, with the exception of the announcement lists, are not moderated and anybody is more than welcome to join them. However, you must be subscribed to post to a list. To reduce the bandwidth demands on everyone, mail should not contain attachments. It is recommended that you place interesting material (such as patches) either within the body of the message or provide a URL for retrieval.
To join the mailing lists, see our Mailing List page.
The project's list fall into the following categories:

Announcement Lists
Announcement lists are very low traffic designed to communicate important information, such as releases of a product of this project, to a wide audience.


User Lists
User lists are for users of a product to converse about such things as configuration and operating of the products of the project.


Developer Lists
Developer lists are for the contributors to the project. On these lists suggestions and comments for code changes are discussed and action items are raised and voted on. For the developer community, these lists are the very center of the project where all the "action" is.


Commit Lists
The commit lists are where all CVS code commit messages are sent. All committers are required to subscribe to this list so that they can stay aware of changes to the repository.



Decision Making
All Contributors are encouraged to participate in decisions, but the decision itself is made by those that have Committer status in the project.
In other words, the project is a "Minimum Threshold Meritocracy".
Action Items
All decisions revolve around "action items". Most action items require a vote to be approved. Votes can either be by majority or by consensus.
Action items include the following:
Long Term Plans
Long term plans are simply announcements that group members are working on particular issues related to the Project. These are not voted on, but Committers who do not agree with a particular plan, or think that an alternative plan would be better, are obligated to inform the group of their feelings.


Short Term Plans
Short term plans are announcements that a volunteer is working on a particular set of documentation or code files with the implication that other volunteers should avoid them or try to coordinate their changes.


Release Plan
A release plan is used to keep all volunteers aware of when a release is desired, who will be the Release Manager, when the repository will be frozen to create a release, and other assorted information to keep volunteers from tripping over each other. Lazy majority decides each issue in a release plan, or lazy consensus if the issue involves a product change.


Release Testing
After a new release is built, it must be tested before being released to the public. After the release plan is approved, the Release Manager will announce that a product is ready for testing.


Public Release
Once the Release Manager determines that testing is complete, and all showstoppers for the release have been resolved, the Release Manager shall call for a vote on the public release. Majority approval is required before the public release can be made. The Committers who approve a public release (vote +1) are expected to provide ongoing support for that release while it is current. The Release Manager must summarize the outcome of the vote before the public release becomes final.


Showstoppers
Showstoppers are issues that require a fix be in place before the next public release. They are listed in the status file in order to focus special attention on these problems. An issue becomes a showstopper when it is listed as such in the status file and remains so by lazy consensus.


Product Changes
Changes to the products of the project, including code and documentation, will appear as action items in the status file. All product changes to the currently active repository are subject to lazy consensus.



VotingAction Item Votes
The act of voting on an action item carries certain obligations. Voting members are not only stating their opinion, they are also agreeing to help do the work.
Any Contributor or Committer ("member") may call for an action-item vote on the Developer mailing list. It is preferred that a vote be preceded by a formal proposal offered for discussion purposes. The message announcing a vote should contain a Subject beginning with "[VOTE]", and a distinctive one-line summary corresponding to the action item for the vote.
Each vote on an action item can be made in one of four flavors:

+1"The action should be performed, and I will help."
+0"Abstain", "I support the action but I can't help."
-0"Abstain", "I don't support the action but I can't help with an alternative."
-1"The action should not be performed and I am offering an explanation or alternative."


Votes cast by the project's committers are considered "binding". When needed, at least 3 binding +1 votes are required for approval of an action item.
An action item may need one of two types of approval:
  • Consensus approval:
    An action requiring consensus approval must receive at least 3 binding +1 votes and no binding vetos.
  • Majority approval:
    An action requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes.
Except for a public release, all action items are considered to have lazy approval until somebody votes -1, at which point the action item is converted to a formal consensus or majority vote, depending on the type of action item .
Note
"Lazy" means the action item has immediate tactic approval, and it is not necessary to tally the vote until a -1 reply is posted. Once a -1 reply is posted, the vote must be tallied and reported before the action item is considered approved.
All action-item votes are lazy except for a public release vote.
Any member may vote on any action item or related issue. When voting on an action item, the project's committers may also include the word "binding" next to their vote, to simplify a tally if it is needed. All binding vetos must also contain an explanation of why the veto is appropriate.
Voting Caveats
  • A +1 vote regarding product code can only be made binding if the voter has tested the action on their own equipment.
  • A binding +1 vote on a public release means the project's committer agrees to provide ongoing support for that release while it is current.
  • An abstention may have detrimental effects if too many people abstain.
  • Vetos with no explanation are void. If you disagree with the veto, you should lobby the person who cast the veto. Voters intending to veto an action item should make their opinions known to the group immediately so that the problem can be remedied as early as possible.
  • If a committer believes the explanation for a veto is invalid, an affirmation of the veto can be requested. If some other committer does not affirm that the explanation for the veto is valid, the veto shall be void.
  • Members who wish to discuss a vote before replying, may open another thread to help avoid premature vetos. Any +/-1's or +/-0's posted to an alternate thread, or any other thread not labeled "[VOTE]", are considered conversational, and do not qualify as an valid action-item vote. A "lazy item" remains subject to lazy approval until a valid -1 reply is posted to the "[VOTE]" thread.
Vote Results
Most action items are subject to lazy approval, and do not require the posting of a formal result. However, any other majority item that receives any -1 reply (later rescinded or not) must be followed by a "[VOTE-RESULT]" message before the action item is considered approved.
Likewise, any consensus item that receives any binding veto must post a "[VOTE-RESULT]" message summarizing the result, and show that each veto was rescinded, before it is considered approved. In either case, the member who requested the vote should also post the result within 120 hours (5 days).
A Public Release is not considered approved until the Release Manager posts a followup message with the legend "[VOTE-RESULT]" summarizing the replies.
Proposals (and plans)
Proposals are not a formal action item; however, the message offering a proposal should contain a Subject beginning with "[PROPOSAL]".
It is strongly recommended that a proposal be circulated before calling for a formal vote. Often, once members have had the chance to critique a proposal, an updated copy of a proposal can be reposted as the vote document.
Most other messages posted to the Developer's List usually involve either short-term or long-term plans. Often, a long-term plan will be made in the form of a "[PROPOSAL]". If appropriate, the proposed change or feature may then be entered to the project's STATUS file or TODO list.
Voting on other matters
There are other matters upon which members will vote that do not involve action items. The same general voting structure is used in these cases, except that the "flavors" are taken to mean:

+1"Yes", "I agree."
+0"Abstain", "No opinion."
-0"Abstain", "Unsure."
-1"No", "I disagree."



Branches
In any software development project there is a natural tension between revolution and evolution. Many software development teams, open or closed, have a team leader who can declare whether the code base is in evolutionary or revolutionary mode. In a volunteer meritocracy, this type of decision is difficult to make and impossible to enforce. Our meritocracy is fueled by voluntary contributions, and so we must allow everyone to contribute and then base our final product decisions on the contributions we actually receive.
Accordingly, as a matter of project policy, these principles are adopted:
  • Every committer has the right to revolution. Anyone can establish a branch or seperate whiteboard directory in which to experiment with new code seperate from the main trunk. The only responsibility a committer has when they do this is to announce their short and long term plans and allow others who want to help to do so. Committers working on a revolutionary branch have the right to develop their approach free of interference.
  • When a revolution is considered ready for prime time, the committer(s) shall propose a merge to the developers list. At that time, the overall community evaluates whether or not the code is ready to become part of, or to potentially replace, the trunk. Suggestions may be made, changes may be required. Once all issues have been taken care of and the merge is approved, the new code may become the trunk.
  • All development branches should be unversioned. No branch, evolutionary or revolutionary, should have any official version standing. This allows several parallel tracks of development to occur with the final authority of what eventually becomes the trunk resting with the entire community of committers.
  • The trunk is the official versioned line of the project. All evolutionary minded people are welcome to work on it to improve it. Evolutionary work is important and should not stop as it is always unclear when any particular revolution will be ready for prime time or whether it will be officially accepted.


Source Repository
The project's codebase is maintained in a shared information repository using CVS. Only Committers have write access to this repository. Everyone has read access via anonymous CVS. All Java Language source code in the repository must be written in conformance to the "Code Conventions for the Java Programming Language" as published by Sun.
License
All source code committed to the Project's repositories must be covered by the project license or contain a copyright and license that allows redistribution under the same conditions as the project license.

Status
The project's active source code repository contains a file named STATUS.xml which is used to keep track of the agenda and plans for work within the repository. The status file includes information about release plans, a summary of code changes committed since the last release, a list of proposed changes that are under discussion, brief notes about items that individual volunteers are working on or want discussion about, and anything else that may be useful to help the group track progress.

Branches
It is allowed to create a branch for each release cycle, etc. They are expected to merge completely back with the main branch as soon as their release cycle is complete.
A branch is considered "evolutionary" by lazy consensus. Upon any dispute (binding veto), a branch must be converted to "revolutionary" status, and must be assigned a working name that does not imply it will be the next version of the product. Once a release plan for the branch has been approved, and the proposed release is ready for testing, it may be assigned a version name reflecting it is a product release candidate, and merged back with the main branch, as appropriate to the circumstances. Any branch, "evolutionary" or "revolutionary", shall meet the same standard for release approval.

Changes
Simple patches to fix bugs can be committed then reviewed. With a commit-then-review process, the committer is trusted to have a high degree of confidence in the change. Doubtful changes, new features, and large scale overhauls need to be discussed before committing them into the repository. Any change that affects the semantics of an existing API function, the size of the program, configuration data formats, or other major areas must receive consensus approval before being committed.
Related changes should be committed as a group, or very closely together. Half complete changes should never be committed to the main branch of a development repository. All code changes must be successfully compiled on the contributor's platform before being committed. The current source code tree for the project should be capable of complete compilation at all times. However, it is sometimes impossible for a contributor on one platform to avoid breaking some other platform when a change is committed. If it is anticipated that a given change will break the build on some other platform, the committer must indicate that in the commit message.
A committed change must be reversed if it is vetoed by one of the voting members and the veto conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The veto must be rescinded before the change can be included in any public release.

Patches
When a specific change to a product is proposed for discussion or voting on the appropriate development mailing list, it should be presented in the form of input to the patch command. When sent to the mailing list, the message should contain a Subject beginning with [PATCH] and a distinctive one-line summary corresponding to the action item for that patch.
Related changes should be committed as a group, or very closely together. Half complete changes should never be committed to the main branch of a development repository. All code changes must be successfully compiled on the contributor's platform before being committed. The current source code tree for the project should be capable of complete compilation at all times. However, it is sometimes impossible for a contributor on one platform to avoid breaking some other platform when a change is committed. If it is anticipated that a given change will break the build on some other platform, the committer must indicate that in the commit message.
The patch should be created by using the diff -u command from the original software file(s) to the modified software file(s). For example:
diff -u Main.java.orig Main.java >> patchfile.txt
or
cvs diff -u Main.java >> patchfile.txt
On Win32 you can use WinCVSfor a nice GUI or you can install Cygwin which will enable you to use the bash shell and also installs a lot of other utilities (such as diff and patch) that will turn your PC into a virtual Unix machine.
All patches necessary to address an action item should be concatenated within a single patch message. If later modification to the patch proves necessary, the entire new patch should be posted and not just the difference between the two patches.


[size=-2]by Ted Husted, modified by Dieter Wimberger


回复

使用道具 举报

345

主题

561

帖子

2045

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2045
 楼主| 发表于 2022-10-18 08:58:45 | 显示全部楼层
项目指南
注意
[tr]这些项目指南是根据雅加达项目指南(及其工作建议)改编的,您可以在以下网址找到:
[tr]http://jakarta.apache.org/site/guidelines.html
[tr]http://jakarta.apache.org/site/proposal.html

[tr]需要对措辞进行修改,以使其适用于单一的非雅加达项目(即不是子项目,也不是PMC的监督对象)。
[tr]这些材料的版权归Apache基金会雅加达项目所有,并经PMC许可发布。
[tr]概述
[tr]本文件定义了项目的指导方针。它包括各类成员的定义,谁有权投票,如何通过投票解决冲突,以及提议和修改项目代码库所需遵循的程序。

[tr]角色和责任
[tr]人们在项目中可以承担的角色和责任都是基于优点的。不管他们扮演什么角色,每个人都能提供帮助。那些长期或有价值的项目贡献者获得了投票权并直接提交到源存储库。
[tr]用户
[tr]用户是使用本项目产品的人。担任此角色的人不提供代码,但他们在使用产品、报告错误、提出功能请求、帮助其他用户、扩展联机常见问题解答等等。这是迄今为止最重要的一类人,因为没有用户,项目就没有任何理由。
[tr]当用户开始贡献代码或文档补丁时,他们就成了贡献者。

[tr]贡献者
[tr]贡献者是编写代码或文档补丁或以其他方式对项目做出积极贡献的人。志愿者的贡献总是被认可的。在源代码中,所有为源文件投稿的志愿者都可以将他们的名字添加到该文件的作者列表中。

[tr]提交者
[tr]经常为项目做出有价值贡献的贡献者可以被提升为“提交者”。提交者拥有对源代码存储库的写访问权,并获得投票权,从而可以影响项目的未来。
[tr]为了让一个贡献者成为提交者,另一个提交者可以指定该贡献者,或者该贡献者可以请求它。一旦一个贡献者被提名,这个项目的所有提交者都将投票。如果至少有3个赞成票,没有反对票,那么贡献者将被转换为提交者,并被授予对项目源代码存储库的写访问权。
[tr]在获得写访问权限之前,提交者还必须确认他们已经阅读并理解这些指南,并同意遵守这些指南的条款,因为这些条款可能会不时修订。
[tr]有时,提交者可能会因为各种原因而变得不活跃。一个提交者已经不活跃了6个月或更长时间,可能会失去提交者的身份。
[tr]我们现在的一些提交者的列表可以在[tr]项目学分[tr] .

[tr]发布管理器
[tr]产品发布将由选定的提交者管理。发布经理应该积极管理发布过程,注意截止日期,发布和发布公告。


[tr]通信
[tr]这个项目的力量来自于成员之间的交流。为了方便成员之间的沟通,项目有[tr]邮件列表[tr]以及[tr]讨论论坛[tr] .
[tr]这些名单,除了公告名单,不被管理,非常欢迎任何人加入其中。但是,您必须订阅发布到列表。为了减少每个人的带宽需求,邮件不应该包含附件。建议您将感兴趣的材料(如修补程序)放在邮件正文中,或提供用于检索的URL。
[tr]要加入邮件列表,请参阅[tr]邮件列表[tr]第页
[tr]项目列表分为以下几类:

公告列表
[tr]发布列表是一种非常低的流量,旨在向广大受众传达重要信息,如本项目产品的发布。


用户列表
[tr]用户列表用于产品用户就项目产品的配置和操作等问题进行对话。


开发人员列表
[tr]开发人员列表是为项目的贡献者准备的。在这些列表中,讨论对代码更改的建议和注释,提出并投票决定操作项。对于开发人员社区来说,这些列表是项目的中心,所有“操作”都在其中。


提交列表
[tr]提交列表是发送所有CVS代码提交消息的地方。所有提交者都需要订阅这个列表,这样他们就可以随时了解存储库的更改。



[tr]决策
[tr]全部[tr]贡献者[tr]被鼓励参与决策,但决策本身是由那些[tr]提交者[tr]项目中的状态
[tr]换句话说,这个项目是“最低门槛精英管理”[tr] .
[tr]行动项目
[tr]所有的决定都围绕着“行动项目”[tr]。大多数行动项目需要[tr]投票[tr]待批准。投票可以通过[tr]大多数[tr]或者[tr]共识[tr] .
[tr]行动项目包括:
长期计划
[tr]长期计划只是宣布小组成员正在处理与项目有关的特定问题。这些都不是投票决定的,但是那些不同意某个特定计划,或者认为另一个计划更好的提交者有义务将他们的感受告知小组。


短期计划
[tr]短期计划是指一个志愿者正在处理一组特定的文档或代码文件,并暗示其他志愿者应该避免这些文档或代码文件或试图协调它们的更改。


放行计划
[tr]发布计划用于让所有志愿者知道何时需要发布,谁将是发布经理,何时冻结存储库以创建发布,以及其他各种信息,以防止志愿者互相绊倒。懒惰的多数决定发布计划中的每一个问题,或者如果问题涉及到产品变更,则懒共识。


释放测试
[tr]新的发布之前必须经过测试。发布计划获得批准后,发布经理将宣布产品已准备好进行测试。


公开发行
[tr]一旦发行经理确定测试已完成,并且发行版的所有演示文稿都已解决,发行经理应要求对公开发行进行投票。在公开发布之前,需要获得多数人的批准。批准公开发布(投票)的提交者 one[tr])预计将在当前版本期间为该版本提供持续支持。发布经理必须在公开发布成为最终结果之前总结投票结果。


作秀者
[tr]Showstoppers是需要在下一次公开发行之前进行修复的问题。它们列在状态文件中,以便特别注意这些问题。当一个问题在状态文件中被列出来时,它就变成了一个阻碍因素,并且在惰性共识下仍然如此。


产品变更
[tr]对项目产品(包括代码和文档)的更改将作为操作项出现在状态文件中。所有产品[tr]对当前活动存储库的更改[tr]受制于懒惰的共识



[tr]投票[tr]行动项目投票
[tr]对某一行动项目进行表决的行为带有一定的义务。有投票权的成员不仅陈述了他们的意见,而且还同意帮助他们完成这项工作。
[tr]任何投稿人或提交人(“成员”)可要求就[tr]开发者邮件列表[tr]。建议在表决前提交一份供讨论之用的正式提案。宣布投票的消息应包含以“[投票]”开头的主题,以及与[tr]行动项目[tr]为了投票
[tr]对一个行动项目的每一次投票可以有以下四种方式之一:

one[tr]“应该采取行动,我会帮忙的。”
zero[tr]“弃权”,“我支持这个行动,但我无能为力。”
-0[tr]“弃权”,“我不支持这一行动,但我不能帮助你选择一个替代方案。”
-1[tr]“不应执行该操作,我将提供解释或替代方案。”


[tr]项目提交人的投票被认为是“有约束力的”。需要时,至少3个绑定 one[tr]批准一项行动项目需要投票。
[tr]行动项目可能需要两种类型的批准之一:
  • 一致同意:
    [tr]需要协商一致批准的行动必须至少得到3装订1[tr]投票和没有约束性的否决[tr] .
  • 多数通过:
    [tr]要求多数通过的行动必须至少得到3装订1[tr]投票和更多 one[tr]投票比 -1[tr]投票
[tr]除了公开发布,所有的行动项目都被认为是懒散的批准,直到有人投票 -1[tr],此时根据行动项目的类型,行动项目转化为正式协商一致或多数票。
注意
“懒惰”[tr]意味着行动项目立即获得战术批准,并且在 -1[tr]回复已发布。一次 -1[tr]答复被张贴,投票必须被计票和报告之前,行动项目被视为批准。
除了公开发布投票,所有的行动项目投票都是懒惰的。
[tr]任何成员均可就任何行动项目或有关问题进行表决。当对一个行动项目进行投票时,项目的提交人也可以在他们的投票旁边加上“绑定”一词,以便在需要时简化计票。所有有约束力的维托必须[tr]还包括对否决权为何适当的解释。
[tr]投票注意事项
  • [tr]A one[tr]只有投票人在自己的设备上测试了产品代码,才能使投票具有约束力。
  • [tr]装订 one[tr]对一个公开发布的投票意味着项目的提交者同意在发布当前版本时为其提供持续的支持。
  • [tr]如果太多人弃权,弃权可能会产生有害影响。
  • [tr]没有解释的否决是无效的。如果你不同意否决权,你应该游说投否决票的人。投票人应尽早采取行动解决他们的意见。
  • [tr]如果提交人认为否决权的解释无效,可以要求确认否决权。如果其他提交人不确认否决权的解释是有效的,否决权无效。
  • [tr]希望在答复前讨论投票的成员可以打开另一个线程,以避免过早否决。任何 /-1[tr]的或 /-0[tr]发布到备用线程或任何其他未标记为“[投票]”的线程被视为会话,并且不要[tr]作为有效的行动项目投票。一个“懒惰的项目”仍然要经过延迟批准,直到 -1[tr]回复被发布到“[投票]”线程。
[tr]投票结果
[tr]大多数行动项目都要经过懒散的批准,而且不需要发布正式的结果。但是,收到任何 -1[tr]在行动项目被视为批准之前,回复(稍后是否撤销)后必须加上“[投票结果]”消息。
[tr]同样,获得任何具有约束力否决权的任何协商一致项目都必须张贴一条“[投票结果]”的信息,总结结果,并表明每个否决权在被视为获得批准之前已被撤销。在任何一种情况下,要求投票的成员也应在120小时(5天)内公布投票结果。
[tr]A[tr]公开发行[tr]直到发布管理器发布一条带有图例“[VOTE-RESULT]”总结回复的后续消息时,才被视为已批准。
[tr]建议(和计划)
[tr]提案不是正式的行动项目;但是,提供建议的消息应包含以“[建议]”开头的主题。
[tr]强烈建议在要求正式表决之前分发一项提案。通常,一旦成员有机会对提案提出批评,提案的更新副本可以作为投票文件重新发布。
[tr]发布到开发人员列表中的大多数其他消息通常涉及短期或长期计划。长期计划通常以“[提案]的形式制定。如果合适,建议的变更或特性可以输入到项目的状态文件或TODO列表中。
[tr]其他事项表决
[tr]还有一些其他事项将由成员国投票,但不涉及行动项目。在这些情况下使用相同的一般投票结构,除了“口味”被认为是指:

one[tr]“是的”,“我同意。”
zero[tr]“弃权”,“没有意见。”
-0[tr]“弃权”,“不确定。”
-1[tr]“不”,“我不同意。”



[tr]分支机构
[tr]在任何软件开发项目中,革命和进化之间都存在着一种自然的紧张关系。许多软件开发团队,无论是开放的还是封闭的,都有一个团队负责人,他可以声明代码库是处于进化模式还是革命性模式。在一个自愿性的精英体制中,这种决定很难做出,也不可能实施。我们的精英管理是由自愿捐款推动的,因此我们必须允许每个人都作出贡献,然后根据我们实际收到的捐款来决定我们的最终产品。
[tr]因此,作为项目政策,采用以下原则:
  • [tr]每个共产党人都有革命的权利。任何人都可以建立一个分支或独立的白板目录,在这个目录中试验与主干分离的新代码。当提交者这样做时,他们唯一的责任就是宣布他们的短期和长期计划,并允许其他愿意帮助的人这样做。在革命分支机构工作的提交者有权在不受干扰的情况下发展他们的方法。
  • [tr]当一次革命被认为是黄金时代,提交者应向开发者列表提出合并。那时,整个社区会评估代码是否准备好成为主干的一部分,或者是否准备好替换主干。可能会提出建议,可能需要改变。一旦所有问题都处理好了,合并得到批准,新代码就可能成为主干。
  • [tr]所有的开发分支都应该是非版本化的。任何一个分支,无论是进化的还是革命的,都不应该有任何官方版本。这使得开发的几个平行轨道得以发生,最终成为主干的最终权威将由整个提交者社区承担。
  • [tr]主干线是该项目的官方版本。欢迎所有有进化思想的人来改进它。进化的工作是重要的,不应停止,因为它总是不清楚什么时候任何特定的革命将准备好的黄金时期或它是否会被正式接受。


[tr]源码库信息
[tr=transparent]项目的代码库使用CVS在共享信息存储库中维护。只有提交者才有此存储库的写访问权限。每个人都可以通过匿名简历进行读取。存储库中的所有Java语言源代码都必须按照[tr]“Java编程语言的代码约定”[tr]由Sun出版
[tr]许可证
[tr=transparent]提交给项目存储库的所有源代码都必须由[tr]项目许可证[tr]或者包含允许在与项目许可相同的条件下重新分发的版权和许可。

[tr]状态
[tr]项目的活动源代码存储库包含一个名为状态.xml[tr]它用于跟踪存储库中的议程和工作计划。状态文件包括有关发布计划的信息、自上次发布以来提交的代码更改摘要、正在讨论的建议更改列表、关于单个志愿者正在处理或希望讨论的项目的简要说明,以及任何可能有助于小组跟踪进展的信息。

[tr]分支机构
[tr=transparent]它允许为每个发布周期创建一个分支,等等。一旦它们的发布周期完成,它们将与主分支完全合并。
[tr]一个分支被懒惰的共识认为是“进化的”。任何争议([tr]有约束力的否决权[tr=transparent]),分支必须转换为“革命性”状态,并且必须分配一个工作名称,该名称不意味着它将是产品的下一个版本。一旦分支机构的发布计划被批准,并且提议的发布已经准备好进行测试,就可以为它分配一个版本名,反映它是一个产品发布候选版本,并根据情况与主分支合并。任何分支机构,“进化”或“革命”应满足相同的发布批准标准。

[tr]变化
[tr=transparent]可以提交修复bug的简单修补程序,然后进行复查。通过提交然后评审的过程,提交者被信任对变更有高度的信心。在将可疑的更改、新特性和大规模大修提交到存储库之前,需要对它们进行讨论。任何影响现有API函数语义、程序大小、配置数据格式或其他主要方面的更改都必须在提交之前获得一致同意。
[tr]相关的变更应该作为一个团队,或者非常紧密地结合在一起。不应将半完成的更改提交到开发存储库的主分支。所有代码更改必须在提交之前在参与者的平台上成功编译。项目的当前源代码树应该能够随时完成编译。然而,当一个平台上的贡献者提交了一个变更时,它有时不可能避免破坏另一个平台。如果预期某个给定的更改会破坏其他平台上的构建,提交者必须在提交消息中指出这一点。
[tr=transparent]如果提交的更改被某个投票成员否决,并且否决条件不能通过相当于“错误修复”提交立即得到满足,则必须撤销该更改。否决权必须被取消,然后才能在任何公开发布中包括修改。

[tr]补丁
[tr]当产品的特定变更被提议在适当的开发邮件列表上进行讨论或投票时,它应该以输入patch命令的形式呈现出来。当发送到邮件列表时,邮件应包含以[PATCH]开头的主题和与[tr]行动项目[tr]为了那个补丁
[tr]相关的变更应该作为一个团队,或者非常紧密地结合在一起。不应将半完成的更改提交到开发存储库的主分支。所有代码更改必须在提交之前在参与者的平台上成功编译。项目的当前源代码树应该能够随时完成编译。然而,当一个平台上的贡献者提交了一个变更时,它有时不可能避免破坏另一个平台。如果预期某个给定的更改会破坏其他平台上的构建,提交者必须在提交消息中指出这一点。
[tr]修补程序应该使用diff-u命令从原始软件文件创建到修改后的软件文件。例如:
diff -u Main.java.orig Main.java >> patchfile.txt
[tr]或
cvs diff -u Main.java >> patchfile.txt
[tr]在Win32上,您可以使用[tr] WinCVS公司[tr]或者你可以安装[tr] 小天鹅[tr=transparent]这将使您能够使用bashshell并安装许多其他实用程序(如diff和patch),这些实用程序将把您的PC变成一个虚拟的Unix机器。
[tr]解决操作项所需的所有修补程序都应在单个修补程序消息中串联。如果后来证明有必要对补丁进行修改,那么应该发布整个新补丁,而不仅仅是两个补丁之间的差异。


[size=-2]作者:Ted Husted,Dieter Wimberger修改


回复

使用道具 举报

345

主题

561

帖子

2045

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
2045
 楼主| 发表于 2022-10-18 09:00:43 | 显示全部楼层
Startup How-To
About
Basics
Using the existing main()
Bootstrapping from within your application
Starting through ant (build script)
About
This document describes how to start the telnetd with the given main() or from within your own application.

Basics
For starting up the telnetd and the required number of listeners, you have two choices:

using the existing main() in the TelnetD class
instantiating and activating the daemon from within your application.
Either way you will have to provide the appropiate configuration properties as well as shell implementations (see deployment and configuration index).

Using the existing main()
Assemble/prepare the properties that resemble your desired configuration and issue:

java -classpath telnetd.jar:commons-logging.jar:log4j.jar net.wimpi.telnetd.TelnetD -D -Dlog4j.configuration=<your URL for log4j.properties> <your URL for telnetd.properties>
Logically you will need a JRE/JDK installed (1 and above should work) and the java VM binary in your PATH.

Bootstrapping from within your application
It will be required to take the following steps:

Assemble/prepare the properties that resemble your desired configuration.
Create a TelnetD instance using one of the given factory methods in the TelnetD class (see API docs).
Start the daemon calling start()
An example is given below, props represents a single Properties instance containing all properties for your desired configuration:

//1. create singleton instance
TelnetD daemon = TelnetD.createTelnetD(props);
//2.start serving
daemon.start();
Starting through ant (build script)
You can as well use ant to start the daemon invoking ant with the runit target.
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则



Archiver|手机版|小黑屋|risc-v中文社区

GMT+8, 2022-12-4 02:21 , Processed in 0.019484 second(s), 17 queries .

risc-v中文社区论坛 官方网站

Copyright © 2018-2021, risc-v open source

快速回复 返回顶部 返回列表