> 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]. And maybe this is kind of off topic, but I once saw some svn links in some of the repos' pages, and be ineffective, last month. And I don't know whether it happened in other repos. Gilles Sadowski <gillese...@gmail.com> 于2020年6月12日周五 下午9:50写道： > 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 > >
