Re: some questions about commons projects.
On 2020-06-12, Gilles Sadowski wrote: > 2020-06-12 15:52 UTC+02:00, Xeno Amess : >> But if Apache Commons is thought to be a whole project, I do think >> the relationship between each of its components should be enforced. The Commons project is the legal entity that binds people with similar interest in creating reusable components. This group of people involves some who work on lots of components and may strive for more standardization and others who are mostly interested in one component and don't see any benefit in changing the placement of braces in "their" component just because people who never worked on "their" component liked a different style better. Realistically there is far less cross polination between components than you may expect. Things lice BCEL or Weaver need people who are familiar with Java byte code. The Math components require a deeper understanding of certain mathematical concepts than many coders have. Crypto, Compress and others attract people with certain interests. > Some regular contributors (or ancient contributors for > old/mature components) will veto touching the code > just for the sake of standardization. That group likely includes me. Well, argue against not veto, actually. >> For example, we might start from trying to use a same code style >> formatter. If you really want to discuss this we should split out a different thread rather than polluting this one. It would probably lead to an exchange of arguments and an agreement to disagree. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: some questions about commons projects.
On 2020-06-12, Xeno Amess wrote: > 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? Neither is right or wrong in general, it all depends on the context. VFS has a bunch of dependencies anyway, so adding a dependency on commons-lang3 is no big deal. Email may have decided to copy a few classes in order to avoid a depencency. Another example I'm aware of is Compress which has copied code from commons-io (basically parts of IOUtils) in order to avoid a dependency. And it has copied classes developed in Comnpress to Codec (some of the more exotic hashes/checksums) because they seemed to fit there - but Compress didn't want to pay for this by adding a dependency. One thing that may not have become clear from Gilles' great answer: many decisions are made by the people who work on a concrete code base while people only active elsewhere get out of the way. There are some common grounds - rules that are common to all Apache projects mostly - but the components operate rather autonomously. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: some questions about commons projects.
2020-06-12 16:14 UTC+02:00, Xeno Amess : >> Well, you had quite a few responses from me, for PRs >> pertaining to "Commons Math" > Indeed. And I think I learned a lot from you too. Thanks. And I look forward to you staying around... :-) >> even though that one I >> qualify as a "zombie" project! [How it came to that >> state is told in the "dev" ML.] > Ah, I thought it be among the alive repos... > Sorry about that. Don't take me wrong: I very much hope that development continues on "Commons Math" (a.o. things, the modernization of the code base, to keep up with the Java language). Many issues were related to this component having become too large to evolve (again: more details in the ML archives). Hence my pushing to split functionality into more manageable components like "Commons RNG", "Commons Numbers", "Commons Statistics", "Commons Geometry". While doing so, many bugs, design flaws, and shortcomings were fixed; and functionality and performance improved. Now "Commons Math" depends on them. Additional components and/or modularization of "Commons Math" would be useful steps to take (IMO). You are most welcome to participate. >> help solving issues that would block the next release. > I'll try. > > Now my workflow is like: > > In playing/training mode: > 1.detect which repo is active. > 2.try to fix some minor things. (and kind of for debugging a toolchain > which I maintained.) > 3.try to rewrite somethings for better performance. (then run jmh.) > > In working mode: > 1. met a bug when I use some of commons repos (Yep I am your loyal user). > 2. try to locate the bug. > 3. try to fix it and report. > > I don't know whether it be a correct way, but I hope I will not make anyone > suffer.(or at least not that much suffer) > Sorry if I made any trouble. No, that seems fine (but note that if I am to interact, it will _not_ be through GitHub). Regards, Gilles >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: some questions about commons projects.
> 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 于2020年6月12日周五 下午10:34写道: > On Fri, Jun 12, 2020 at 10:22 AM Xeno Amess 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 于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 于2020年6月12日周五 下午9:56写道: > > > > > >> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess > 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 于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)?
Re: some questions about commons projects.
On Fri, Jun 12, 2020 at 10:22 AM Xeno Amess 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 于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 于2020年6月12日周五 下午9:56写道: > > > >> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess 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 于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? > >> > >
Re: some questions about commons projects.
>> 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)? Xeno Amess 于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 于2020年6月12日周五 下午9:56写道: > >> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess 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 于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 于2020年6月12日周五 下午9:29写道: >> > > >> > >> Hi. >> > >> >> > >> >> 2. How are commons projects related? >> > >> >> > >> > They are not necessarily related. Usually it is considered >> >
Re: some questions about commons projects.
Hi. 2020-06-12 15:52 UTC+02:00, Xeno Amess : >> Some terms: >> - Apache Commons is an Apache _project_. >> - Apache Commons Lang is a _component_ of the _project_. > >> Each component has its own level of functionality and granularity. Some > are >> lower level, like Commons Lang and Commons IO and do not depend on > anything >> at runtime. >> Others offer higher levels of functionality like Commons VFS, Commons >> Configuration, Commons Digester, and Commons Weaver. >> You'll notice that some of the lower-level components offer a single >> Maven >> module and jar, while others offer many. >> There is no uniform granularity to be expected. > > Get it, at least, kind of. > But if Apache Commons is thought to be a whole project, I do think the > relationship between each of its components should be enforced. It may be seen as an ideal, but given the different history lines of the components, it is not achievable: Some regular contributors (or ancient contributors for old/mature components) will veto touching the code just for the sake of standardization. > For example, we might start from trying to use a same code style formatter. I agree; someone must be suggesting this every 10 years or so; last time (IIRC) it was me; didn't work. :-} Gilles >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: some questions about commons projects.
> Well, you had quite a few responses from me, for PRs > pertaining to "Commons Math" Indeed. And I think I learned a lot from you too. Thanks. > even though that one I > qualify as a "zombie" project! [How it came to that > state is told in the "dev" ML.] Ah, I thought it be among the alive repos... Sorry about that. > help solving issues that would block the next release. I'll try. Now my workflow is like: In playing/training mode: 1.detect which repo is active. 2.try to fix some minor things. (and kind of for debugging a toolchain which I maintained.) 3.try to rewrite somethings for better performance. (then run jmh.) In working mode: 1. met a bug when I use some of commons repos (Yep I am your loyal user). 2. try to locate the bug. 3. try to fix it and report. I don't know whether it be a correct way, but I hope I will not make anyone suffer.(or at least not that much suffer) Sorry if I made any trouble. Gilles Sadowski 于2020年6月12日周五 下午10:04写道: > Hi. > > 2020-06-12 15:44 UTC+02:00, Xeno Amess : > >>> 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.) > > I can't really comment, as I seldom participate in > changes to those components. > > > 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. > > Well, you had quite a few responses from me, for PRs > pertaining to "Commons Math" even though that one I > qualify as a "zombie" project! [How it came to that > state is told in the "dev" ML.] > > > No approving, no rejection, no modification suggestions. > > If you really wanna details, I will try to make a list for you. > > Just guessing, but perhaps the issue is the one I outlined > in my previous reply (and on the JIRA report which you > created ): There are many issues to work on, big to small > down to nit-picks; but surely some have higher "added > value". > Personally I don't think that creating "nit-pick" PRs is the > right way for querying the "liveness" of a project. Better > ask the question directly on the "dev" ML and/or raise and > help solving issues that would block the next release. > > Regards, > Gilles > > >>> [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: some questions about commons projects.
Hi. 2020-06-12 15:44 UTC+02:00, Xeno Amess : >>> 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.) I can't really comment, as I seldom participate in changes to those components. > 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. Well, you had quite a few responses from me, for PRs pertaining to "Commons Math" even though that one I qualify as a "zombie" project! [How it came to that state is told in the "dev" ML.] > No approving, no rejection, no modification suggestions. > If you really wanna details, I will try to make a list for you. Just guessing, but perhaps the issue is the one I outlined in my previous reply (and on the JIRA report which you created ): There are many issues to work on, big to small down to nit-picks; but surely some have higher "added value". Personally I don't think that creating "nit-pick" PRs is the right way for querying the "liveness" of a project. Better ask the question directly on the "dev" ML and/or raise and help solving issues that would block the next release. Regards, Gilles >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: some questions about commons projects.
> 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 于2020年6月12日周五 下午9:56写道: > On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess 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 于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 于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 于2020年6月12日周五 下午9:07写道: > > >> > > >>> Hello. > > >>> > > >>> Le ven. 12 juin 2020 à 13:51, Xeno Amess 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,
Re: some questions about commons projects.
> 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 于2020年6月12日周五 下午9:50写道: > 2020-06-12 15:36 UTC+02:00, Gary Gregory : > > On Fri, Jun 12, 2020 at 9:07 AM Gilles Sadowski > > wrote: > > > >> Hello. > >> > >> Le ven. 12 juin 2020 à 13:51, Xeno Amess 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
Re: some questions about commons projects.
On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess 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 于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 于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 于2020年6月12日周五 下午9:07写道: > >> > >>> Hello. > >>> > >>> Le ven. 12 juin 2020 à 13:51, Xeno Amess 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 > >>>
Re: some questions about commons projects.
> Some terms: > - Apache Commons is an Apache _project_. > - Apache Commons Lang is a _component_ of the _project_. > Each component has its own level of functionality and granularity. Some are > lower level, like Commons Lang and Commons IO and do not depend on anything > at runtime. > Others offer higher levels of functionality like Commons VFS, Commons > Configuration, Commons Digester, and Commons Weaver. > You'll notice that some of the lower-level components offer a single Maven > module and jar, while others offer many. > There is no uniform granularity to be expected. Get it, at least, kind of. But if Apache Commons is thought to be a whole project, I do think the relationship between each of its components should be enforced. For example, we might start from trying to use a same code style formatter. Thanks. Gary Gregory 于2020年6月12日周五 下午9:42写道: > On Fri, Jun 12, 2020 at 9:30 AM Xeno Amess wrote: > > > 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? > > > > Some terms: > - Apache Commons is an Apache _project_. > - Apache Commons Lang is a _component_ of the _project_. > > Each component has its own level of functionality and granularity. Some are > lower level, like Commons Lang and Commons IO and do not depend on anything > at runtime. > Others offer higher levels of functionality like Commons VFS, Commons > Configuration, Commons Digester, and Commons Weaver. > You'll notice that some of the lower-level components offer a single Maven > module and jar, while others offer many. > There is no uniform granularity to be expected. > > HTH, > Gary > > > > > > Gilles Sadowski 于2020年6月12日周五 下午9:07写道: > > > > > Hello. > > > > > > Le ven. 12 juin 2020 à 13:51, Xeno Amess 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
Re: some questions about commons projects.
2020-06-12 15:36 UTC+02:00, Gary Gregory : > On Fri, Jun 12, 2020 at 9:07 AM Gilles Sadowski > wrote: > >> Hello. >> >> Le ven. 12 juin 2020 à 13:51, Xeno Amess 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
Re: some questions about commons projects.
>> 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. Xeno Amess 于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 于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 于2020年6月12日周五 下午9:07写道: >> >>> Hello. >>> >>> Le ven. 12 juin 2020 à 13:51, Xeno Amess 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
Re: some questions about commons projects.
On Fri, Jun 12, 2020 at 9:30 AM Xeno Amess wrote: > 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? > Some terms: - Apache Commons is an Apache _project_. - Apache Commons Lang is a _component_ of the _project_. Each component has its own level of functionality and granularity. Some are lower level, like Commons Lang and Commons IO and do not depend on anything at runtime. Others offer higher levels of functionality like Commons VFS, Commons Configuration, Commons Digester, and Commons Weaver. You'll notice that some of the lower-level components offer a single Maven module and jar, while others offer many. There is no uniform granularity to be expected. HTH, Gary > > Gilles Sadowski 于2020年6月12日周五 下午9:07写道: > > > Hello. > > > > Le ven. 12 juin 2020 à 13:51, Xeno Amess 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:
Re: some questions about commons projects.
On Fri, Jun 12, 2020 at 9:07 AM Gilles Sadowski wrote: > Hello. > > Le ven. 12 juin 2020 à 13:51, Xeno Amess 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. 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 > >
Re: some questions about commons projects.
>> 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 于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 于2020年6月12日周五 下午9:07写道: > >> Hello. >> >> Le ven. 12 juin 2020 à 13:51, Xeno Amess 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 >> >>
Re: some questions about commons projects.
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 于2020年6月12日周五 下午9:07写道: > Hello. > > Le ven. 12 juin 2020 à 13:51, Xeno Amess 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 > >
Re: some questions about commons projects.
Hello. Le ven. 12 juin 2020 à 13:51, Xeno Amess 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
some questions about commons projects.
1. How can a project *** becomes commons-***, or how did a commons-*** project started? What is the actual procedural? 2. How are commons projects related? Are they under a same (or at least similar) management mechanism? Or just sharing a common prefix? 3. How is commons projects' version control, based on function or based on time? 4. Why some projects are on svn, some on gitbox, and some on github? 5. What problems shall be put on mailing list, and what problems shall be put on Jira? 6. Is there quite some dead projects in commons? And how to detect/mark them? 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? 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? Sorry for having so many questions, but I'm just very curious.