2020-06-12 15:36 UTC+02:00, Gary Gregory <garydgreg...@gmail.com>: > On Fri, Jun 12, 2020 at 9:07 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > >> 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). >> > > Not quite. SVN should be considered read-only. A new work should be done in > Git.
Hopefully we mean the same thing, but this is not true: Only those components for which a git repository was set up have their SVN set as read-only (by INFRA). See also my recent post asking how to finalize the move (to the "read-only area") of [Graph]. Regards, Gilles > > Gary > > >> >> 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
