> Being on the PMC means that your VOTE is _binding_ > I think you are assuming that there is a lot of hierarchy, structure, and > formalities that are just not here ;-) Yep, indeed.
Gary Gregory <garydgreg...@gmail.com> 于2020年6月12日周五 下午10:34写道： > On Fri, Jun 12, 2020 at 10:22 AM Xeno Amess <xenoam...@gmail.com> wrote: > > > >> 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 > > ;-) > > > I never doubt this. I know you are busy and put a lot of effort on > > commons. And your helps/suggestions are actually really helpful in most > of > > the times. Thank you. > > > I'm just, kind of curious about how things works here normally. > > > Thanks. > > I have a strange feeling as most of my prs are reviewed by you, a PMC, > but > > not a normal committer. > > Is it a normal state? Or what wrongs/mistakes did I make? > > Because I think normal committers should be the group who review most of > > the prs, and PMC committers shall struggle for some more important > things, > > maybe I mis-understand somethings(again)? > > > > Being on the PMC means that your VOTE is _binding_ > I think you are assuming that there is a lot of hierarchy, structure, and > formalities that are just not here ;-) > > Gary > > Gary > > > > > > Xeno Amess <xenoam...@gmail.com> 于2020年6月12日周五 下午10:01写道： > > > > > > 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 > > > ;-) > > > I never doubt this. I know you are busy and put a lot of effort on > > > commons. And your helps/suggestions are actually really helpful in most > > of > > > the times. Thank you. > > > I'm just, kind of curious about how things works here normally. > > > Thanks. > > > > > > Gary Gregory <garydgreg...@gmail.com> 于2020年6月12日周五 下午9:56写道： > > > > > >> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess <xenoam...@gmail.com> > 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 <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 > > >> > >>> > > >> > >>> > > >> > > > >> > > > > > >
