>> 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 >> >>
