On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess <[email protected]> wrote:
> >> 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. > Speaking for myself, as a volunteer here, I do what I can, when I can, with a eye toward using my time wisely while balancing many other responsibilities. Commons has over 20 components, some I use at work, some I used at play, some I do not use. I do my best to pick low hanging fruits, fix bugs that could be troublesome, and implement new features I feel would clearly benefit a component's community, or that I simply need. All of this takes time; thow in this mailing list, JIRAs, PRs from GitHub, and that's a lot to chew on. IOW, be patient, manage your expectations ;-) HTH, Gary > > > Xeno Amess <[email protected]> 于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 <[email protected]> 于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 <[email protected]> 于2020年6月12日周五 下午9:07写道： > >> > >>> Hello. > >>> > >>> Le ven. 12 juin 2020 à 13:51, Xeno Amess <[email protected]> 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: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> >
