>> 8. What should we do when we have a pr delayed for a long time? And how >> long is thought to be an unusual long time for waiting? 3 days.1 week,or 1 >> month?
> They might have been forgotten, or there may other issues. > Examples? for 1 year example: https://github.com/apache/commons-lang/pull/428 for half year example: https://github.com/apache/commons-vfs/pull/78 (I have no idea whether it is already resolved, as I have not received any report about it being resolved, and the pr is still not closed or marked resolved by someone.) for two weeks example: too many. As I said above, I have no better way for detecting whether a repo is "active", so I send some "trying minor prs" to every repo (nearly). Most of them have no response. No approving, no rejection, no modification suggestions. If you really wanna details, I will try to make a list for you. Xeno Amess <xenoam...@gmail.com> 于2020年6月12日周五 下午9:36写道： > >> Are they under a same (or at least > >> similar) management mechanism? Or just sharing a common prefix? > > > Do you mean the development tools (maven, git)? > > There some measure of "standardization" through the parent POM > > file, but nothing is really enforced. The code style depends on the > > regular contributors (and how old the codebase was when it was > > considered "mature"). > > So...if we treat a repo as a city, there should be some regular > contributors like Mayor or something, and PMCs are more like Special Envoy > from the King, correct? > And in usual cases the "some regular contributors" are people who review > prs. > But what will happen if the "some regular contributors" all become busy > and nobody be willing to review? > Is there a mechanism for this situation? > > Xeno Amess <xenoam...@gmail.com> 于2020年6月12日周五 下午9:29写道： > >> Hi. >> >> >> 2. How are commons projects related? >> >> > They are not necessarily related. Usually it is considered >> > a feature if a component has zero dependency (as it is was >> > easier to avoid "JAR hell"). >> > However, there are also drawbacks, e.g. duplicating functionality >> > (and work) needed by several components. >> >> Something was not quite right about this. >> For example, in commons-vfs, we just use commons-lang3 as a dependency. >> But in commons-email, we fork some of utility functions in commons-lang3 >> as a java class in commons-email. >> Which is the right way, or a more commonly accepted way in commons >> projects? >> >> >> Gilles Sadowski <gillese...@gmail.com> 于2020年6月12日周五 下午9:07写道： >> >>> Hello. >>> >>> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xenoam...@gmail.com> a écrit : >>> > >>> > 1. How can a project *** becomes commons-***, or how did a commons-*** >>> > project started? What is the actual procedural? >>> >>> For new components, this list would be the place to make the >>> proposal. A discussion would decide if "Apache Commons" is >>> the right place (given the interest/capacity of the current team). >>> >>> > 2. How are commons projects related? >>> >>> They are not necessarily related. Usually it is considered >>> a feature if a component has zero dependency (as it is was >>> easier to avoid "JAR hell"). >>> However, there are also drawbacks, e.g. duplicating functionality >>> (and work) needed by several components. >>> >>> > Are they under a same (or at least >>> > similar) management mechanism? Or just sharing a common prefix? >>> >>> Do you mean the development tools (maven, git)? >>> There some measure of "standardization" through the parent POM >>> file, but nothing is really enforced. The code style depends on the >>> regular contributors (and how old the codebase was when it was >>> considered "mature"). >>> >>> > 3. How is commons projects' version control, based on function or >>> based on >>> > time? >>> >>> A backward-compatible release has its minor version number >>> increased; otherwise both the major number and the base package >>> are changed. >>> >>> > 4. Why some projects are on svn, some on gitbox, and some on github? >>> >>> All actively developed components were (will be) moved to "gitbox" >>> (decision made a few years ago, cf. "dev" M archive). >>> Those remaining on SVN are probably mainly "dormant" (except >>> perhaps for some security fix). >>> >>> IIUC, a "GitHub" mirror is automatically created for every new >>> "gitbox" Apache project. >>> >>> > 5. What problems shall be put on mailing list, and what problems shall >>> be >>> > put on Jira? >>> >>> ML: proposal, discussion on design, ... >>> JIRA: identified bugs (with references and/or unit test), accepted >>> feature, discussion on implementation details, ... >>> >>> > 6. Is there quite some dead projects in commons? And how to detect/mark >>> > them? >>> >>> Depends on the definition of "dead". >>> None of the components in "proper" are considered dead, even if >>> they are not actively developed anymore (whether this is "good" >>> or "bad" is another question). >>> I haven't seen anything in "sandbox" being developed for a long >>> time (until the last few days where "Commons Graph" seems it >>> may be revived). >>> Unless I'm mistaken, a project in "dormant" has been subject to >>> decision for stopping its development. >>> >>> > 7. What is the general waiting time for a pr to be reviewed(and >>> rejected or >>> > accepted)? In my own observation the waiting time is between [1 days, >>> 1.5 >>> > years) , is it a little...large? >>> >>> It boils down to the level of involvement of a committer for the >>> component being the target of the PR. >>> Developers being volunteers, it certainly also depends on the >>> balance between the usefulness of the PR and the work required >>> from the reviewer. >>> >>> > 8. What should we do when we have a pr delayed for a long time? And how >>> > long is thought to be an unusual long time for waiting? 3 days.1 >>> week,or 1 >>> > month? >>> >>> They might have been forgotten, or there may other issues. >>> Examples? >>> >>> > >>> > Sorry for having so many questions, but I'm just very curious. >>> >>> Hope the above answers have helped. >>> >>> Regards, >>> Gilles >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>>
