You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by Xeno Amess <xe...@gmail.com> on 2020/06/12 11:51:22 UTC

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.

Re: some questions about commons projects.

Posted by Stefan Bodewig <bo...@apache.org>.

On 2020-06-12, Gilles Sadowski wrote:

> 2020-06-12 15:52 UTC+02:00, Xeno Amess <xe...@gmail.com>:

>> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: some questions about commons projects.

Posted by Gilles Sadowski <gi...@gmail.com>.

Hi.

2020-06-12 15:52 UTC+02:00, Xeno Amess <xe...@gmail.com>:
>> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: some questions about commons projects.

Posted by Xeno Amess <xe...@gmail.com>.

> 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 <ga...@gmail.com> 于2020年6月12日周五 下午9:42写道：

> On Fri, Jun 12, 2020 at 9:30 AM Xeno Amess <xe...@gmail.com> 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 <gi...@gmail.com> 于2020年6月12日周五 下午9:07写道：
> >
> > > Hello.
> > >
> > > Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>

Re: some questions about commons projects.

Posted by Gary Gregory <ga...@gmail.com>.

On Fri, Jun 12, 2020 at 9:30 AM Xeno Amess <xe...@gmail.com> 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 <gi...@gmail.com> 于2020年6月12日周五 下午9:07写道：
>
> > Hello.
> >
> > Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

Re: some questions about commons projects.

Posted by Stefan Bodewig <bo...@apache.org>.

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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: some questions about commons projects.

Posted by Xeno Amess <xe...@gmail.com>.

> 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 <ga...@gmail.com> 于2020年6月12日周五 下午10:34写道：

> On Fri, Jun 12, 2020 at 10:22 AM Xeno Amess <xe...@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 <xe...@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 <ga...@gmail.com> 于2020年6月12日周五 下午9:56写道：
> > >
> > >> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess <xe...@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 <xe...@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 <xe...@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 <gi...@gmail.com> 于2020年6月12日周五 下午9:07写道：
> > >> > >>
> > >> > >>> Hello.
> > >> > >>>
> > >> > >>> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
> > >> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >> > >>>
> > >> > >>>
> > >> >
> > >>
> > >
> >
>

Re: some questions about commons projects.

Posted by Gary Gregory <ga...@gmail.com>.

On Fri, Jun 12, 2020 at 10:22 AM Xeno Amess <xe...@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 <xe...@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 <ga...@gmail.com> 于2020年6月12日周五 下午9:56写道：
> >
> >> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess <xe...@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 <xe...@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 <xe...@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 <gi...@gmail.com> 于2020年6月12日周五 下午9:07写道：
> >> > >>
> >> > >>> Hello.
> >> > >>>
> >> > >>> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
> >> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> >> > >>>
> >> > >>>
> >> >
> >>
> >
>

Re: some questions about commons projects.

Posted by Xeno Amess <xe...@gmail.com>.

>> 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 <xe...@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 <ga...@gmail.com> 于2020年6月12日周五 下午9:56写道：
>
>> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess <xe...@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 <xe...@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 <xe...@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 <gi...@gmail.com> 于2020年6月12日周五 下午9:07写道：
>> > >>
>> > >>> Hello.
>> > >>>
>> > >>> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
>> > >>> For additional commands, e-mail: dev-help@commons.apache.org
>> > >>>
>> > >>>
>> >
>>
>

Re: some questions about commons projects.

Posted by Xeno Amess <xe...@gmail.com>.

> 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 <ga...@gmail.com> 于2020年6月12日周五 下午9:56写道：

> On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess <xe...@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 <xe...@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 <xe...@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 <gi...@gmail.com> 于2020年6月12日周五 下午9:07写道：
> > >>
> > >>> Hello.
> > >>>
> > >>> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
> > >>> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>
> > >>>
> >
>

Re: some questions about commons projects.

Posted by Gary Gregory <ga...@gmail.com>.

On Fri, Jun 12, 2020 at 9:44 AM Xeno Amess <xe...@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 <xe...@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 <xe...@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 <gi...@gmail.com> 于2020年6月12日周五 下午9:07写道：
> >>
> >>> Hello.
> >>>
> >>> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
>

Re: some questions about commons projects.

Posted by Gilles Sadowski <gi...@gmail.com>.

2020-06-12 16:14 UTC+02:00, Xeno Amess <xe...@gmail.com>:
>> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: some questions about commons projects.

Posted by Xeno Amess <xe...@gmail.com>.

> 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 <gi...@gmail.com> 于2020年6月12日周五 下午10:04写道：

> Hi.
>
> 2020-06-12 15:44 UTC+02:00, Xeno Amess <xe...@gmail.com>:
> >>> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: some questions about commons projects.

Posted by Gilles Sadowski <gi...@gmail.com>.

Hi.

2020-06-12 15:44 UTC+02:00, Xeno Amess <xe...@gmail.com>:
>>> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: some questions about commons projects.

Posted by Xeno Amess <xe...@gmail.com>.

>> 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 <xe...@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 <xe...@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 <gi...@gmail.com> 于2020年6月12日周五 下午9:07写道：
>>
>>> Hello.
>>>
>>> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>

Re: some questions about commons projects.

Posted by Xeno Amess <xe...@gmail.com>.

>> 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 <xe...@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 <gi...@gmail.com> 于2020年6月12日周五 下午9:07写道：
>
>> Hello.
>>
>> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

Re: some questions about commons projects.

Posted by Xeno Amess <xe...@gmail.com>.

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 <gi...@gmail.com> 于2020年6月12日周五 下午9:07写道：

> Hello.
>
> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: some questions about commons projects.

Posted by Xeno Amess <xe...@gmail.com>.

> 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 <gi...@gmail.com> 于2020年6月12日周五 下午9:50写道：

> 2020-06-12 15:36 UTC+02:00, Gary Gregory <ga...@gmail.com>:
> > On Fri, Jun 12, 2020 at 9:07 AM Gilles Sadowski <gi...@gmail.com>
> > wrote:
> >
> >> Hello.
> >>
> >> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@gmail.com> a écrit
> :
> >> >
> >> > 1. How can a project *** becomes commons-***, or how did a commons-***
> >> > project started? What is the actual procedural?
> >>
> >> For new components, this list would be the place to make the
> >> proposal.  A discussion would decide if "Apache Commons" is
> >> the right place (given the interest/capacity of the current team).
> >>
> >> > 2. How are commons projects related?
> >>
> >> They are not necessarily related.  Usually it is considered
> >> a feature if a component has zero dependency (as it is was
> >> easier to avoid "JAR hell").
> >> However, there are also drawbacks, e.g. duplicating functionality
> >> (and work) needed by several components.
> >>
> >> > Are they under a same (or at least
> >> > similar) management mechanism? Or just sharing a common prefix?
> >>
> >> Do you mean the development tools (maven, git)?
> >> There some measure of "standardization" through the parent POM
> >> file, but nothing is really enforced.  The code style depends on the
> >> regular contributors (and how old the codebase was when it was
> >> considered "mature").
> >>
> >> > 3. How is commons projects' version control, based on function or
> based
> >> on
> >> > time?
> >>
> >> A backward-compatible release has its minor version number
> >> increased; otherwise both the major number and the base package
> >> are changed.
> >>
> >> > 4. Why some projects are on svn, some on gitbox, and some on github?
> >>
> >> All actively developed components were (will be) moved to "gitbox"
> >> (decision made a few years ago, cf. "dev" M archive).
> >> Those remaining on SVN are probably mainly "dormant" (except
> >> perhaps for some security fix).
> >>
> >
> > Not quite. SVN should be considered read-only. A new work should be done
> in
> > Git.
>
> Hopefully we mean the same thing, but this is not
> true: Only those components for which a git repository
> was set up have their SVN set as read-only (by INFRA).
>
> See also my recent post asking how to finalize the
> move (to the "read-only area") of [Graph].
>
> Regards,
> Gilles
>
> >
> > Gary
> >
> >
> >>
> >> IIUC, a "GitHub" mirror is automatically created for every new
> >> "gitbox" Apache project.
> >>
> >> > 5. What problems shall be put on mailing list, and what problems shall
> >> > be
> >> > put on Jira?
> >>
> >> ML: proposal, discussion on design, ...
> >> JIRA: identified bugs (with references and/or unit test), accepted
> >> feature, discussion on implementation details, ...
> >>
> >> > 6. Is there quite some dead projects in commons? And how to
> detect/mark
> >> > them?
> >>
> >> Depends on the definition of "dead".
> >> None of the components in "proper" are considered dead, even if
> >> they are not actively developed anymore (whether this is "good"
> >> or "bad" is another question).
> >> I haven't seen anything in "sandbox" being developed for a long
> >> time (until the last few days where "Commons Graph" seems it
> >> may be revived).
> >> Unless I'm mistaken, a project in "dormant" has been subject to
> >> decision for stopping its development.
> >>
> >> > 7. What is the general waiting time for a pr to be reviewed(and
> >> > rejected
> >> or
> >> > accepted)? In my own observation the waiting time is between [1 days,
> >> > 1.5
> >> > years) , is it a little...large?
> >>
> >> It boils down to the level of involvement of a committer for the
> >> component being the target of the PR.
> >> Developers being volunteers, it certainly also depends on the
> >> balance between the usefulness of the PR and the work required
> >> from the reviewer.
> >>
> >> > 8. What should we do when we have a pr delayed for a long time? And
> how
> >> > long is thought to be an unusual long time for waiting? 3 days.1
> >> > week,or
> >> 1
> >> > month?
> >>
> >> They might have been forgotten, or there may other issues.
> >> Examples?
> >>
> >> >
> >> > Sorry for having so many questions, but I'm just very curious.
> >>
> >> Hope the above answers have helped.
> >>
> >> Regards,
> >> Gilles
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: some questions about commons projects.

Posted by Gilles Sadowski <gi...@gmail.com>.

2020-06-12 15:36 UTC+02:00, Gary Gregory <ga...@gmail.com>:
> On Fri, Jun 12, 2020 at 9:07 AM Gilles Sadowski <gi...@gmail.com>
> wrote:
>
>> Hello.
>>
>> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@gmail.com> a écrit :
>> >
>> > 1. How can a project *** becomes commons-***, or how did a commons-***
>> > project started? What is the actual procedural?
>>
>> For new components, this list would be the place to make the
>> proposal.  A discussion would decide if "Apache Commons" is
>> the right place (given the interest/capacity of the current team).
>>
>> > 2. How are commons projects related?
>>
>> They are not necessarily related.  Usually it is considered
>> a feature if a component has zero dependency (as it is was
>> easier to avoid "JAR hell").
>> However, there are also drawbacks, e.g. duplicating functionality
>> (and work) needed by several components.
>>
>> > Are they under a same (or at least
>> > similar) management mechanism? Or just sharing a common prefix?
>>
>> Do you mean the development tools (maven, git)?
>> There some measure of "standardization" through the parent POM
>> file, but nothing is really enforced.  The code style depends on the
>> regular contributors (and how old the codebase was when it was
>> considered "mature").
>>
>> > 3. How is commons projects' version control, based on function or based
>> on
>> > time?
>>
>> A backward-compatible release has its minor version number
>> increased; otherwise both the major number and the base package
>> are changed.
>>
>> > 4. Why some projects are on svn, some on gitbox, and some on github?
>>
>> All actively developed components were (will be) moved to "gitbox"
>> (decision made a few years ago, cf. "dev" M archive).
>> Those remaining on SVN are probably mainly "dormant" (except
>> perhaps for some security fix).
>>
>
> Not quite. SVN should be considered read-only. A new work should be done in
> Git.

Hopefully we mean the same thing, but this is not
true: Only those components for which a git repository
was set up have their SVN set as read-only (by INFRA).

See also my recent post asking how to finalize the
move (to the "read-only area") of [Graph].

Regards,
Gilles

>
> Gary
>
>
>>
>> IIUC, a "GitHub" mirror is automatically created for every new
>> "gitbox" Apache project.
>>
>> > 5. What problems shall be put on mailing list, and what problems shall
>> > be
>> > put on Jira?
>>
>> ML: proposal, discussion on design, ...
>> JIRA: identified bugs (with references and/or unit test), accepted
>> feature, discussion on implementation details, ...
>>
>> > 6. Is there quite some dead projects in commons? And how to detect/mark
>> > them?
>>
>> Depends on the definition of "dead".
>> None of the components in "proper" are considered dead, even if
>> they are not actively developed anymore (whether this is "good"
>> or "bad" is another question).
>> I haven't seen anything in "sandbox" being developed for a long
>> time (until the last few days where "Commons Graph" seems it
>> may be revived).
>> Unless I'm mistaken, a project in "dormant" has been subject to
>> decision for stopping its development.
>>
>> > 7. What is the general waiting time for a pr to be reviewed(and
>> > rejected
>> or
>> > accepted)? In my own observation the waiting time is between [1 days,
>> > 1.5
>> > years) , is it a little...large?
>>
>> It boils down to the level of involvement of a committer for the
>> component being the target of the PR.
>> Developers being volunteers, it certainly also depends on the
>> balance between the usefulness of the PR and the work required
>> from the reviewer.
>>
>> > 8. What should we do when we have a pr delayed for a long time? And how
>> > long is thought to be an unusual long time for waiting? 3 days.1
>> > week,or
>> 1
>> > month?
>>
>> They might have been forgotten, or there may other issues.
>> Examples?
>>
>> >
>> > Sorry for having so many questions, but I'm just very curious.
>>
>> Hope the above answers have helped.
>>
>> Regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: some questions about commons projects.

Posted by Gary Gregory <ga...@gmail.com>.

On Fri, Jun 12, 2020 at 9:07 AM Gilles Sadowski <gi...@gmail.com>
wrote:

> Hello.
>
> Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@gmail.com> a écrit :
> >
> > 1. How can a project *** becomes commons-***, or how did a commons-***
> > project started? What is the actual procedural?
>
> For new components, this list would be the place to make the
> proposal.  A discussion would decide if "Apache Commons" is
> the right place (given the interest/capacity of the current team).
>
> > 2. How are commons projects related?
>
> They are not necessarily related.  Usually it is considered
> a feature if a component has zero dependency (as it is was
> easier to avoid "JAR hell").
> However, there are also drawbacks, e.g. duplicating functionality
> (and work) needed by several components.
>
> > Are they under a same (or at least
> > similar) management mechanism? Or just sharing a common prefix?
>
> Do you mean the development tools (maven, git)?
> There some measure of "standardization" through the parent POM
> file, but nothing is really enforced.  The code style depends on the
> regular contributors (and how old the codebase was when it was
> considered "mature").
>
> > 3. How is commons projects' version control, based on function or based
> on
> > time?
>
> A backward-compatible release has its minor version number
> increased; otherwise both the major number and the base package
> are changed.
>
> > 4. Why some projects are on svn, some on gitbox, and some on github?
>
> All actively developed components were (will be) moved to "gitbox"
> (decision made a few years ago, cf. "dev" M archive).
> Those remaining on SVN are probably mainly "dormant" (except
> perhaps for some security fix).
>

Not quite. SVN should be considered read-only. A new work should be done in
Git.

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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: some questions about commons projects.

Posted by Gilles Sadowski <gi...@gmail.com>.

Hello.

Le ven. 12 juin 2020 à 13:51, Xeno Amess <xe...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org