You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@commons.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 2002/11/28 05:45:51 UTC
[STATUS] (commons) Wed Nov 27 23:45:51 EST 2002
APACHE COMMONS PROJECT STATUS: -*-indented-text-*-
Last modified at [$Date: 2002/11/05 05:32:02 $]
Background:
o IRC channel #apache-commons on irc.openprojects.net
traffic is logged to <URL:http://Source-Zone.Org/apache-irc/>
so that the content of interactive discussions is available
to everyone
Project committers (as of 2002-10-27):
o commons:
aaron,coar,donaldp,jerenkrantz,fitz,geirm,gstein,jim,striker
o commons-site:
aaron,coar,donaldp,jerenkrantz,fitz,geirm,gstein,jim,striker,
sanders,nicolaken
Release:
none yet; still defining mission :-)
Resolved Issues:
o Commons is a parent of reusable code projects. These projects
may be used by other projects of the ASF, but it is not a
requirement.
o The Commons will be language-agnostic.
o Projects that are "in scope" are defined as:
- Existing components that are, or would be, useful to multiple
projects
- If a component does not fit the (TBD) goals of Apache Commons,
then it is not considered "in scope" just because it has no
other home. In other words, the Apache Commons is not a place
of last refuge if the component does not match the Apache
Commons' goals.
- Reusable libraries
[ gstein: we should expand this definition for the mission
statement; examples provided were serf and regexp ]
- Components that do not fit cleanly into any other top-level
project, but they do fit the goals of Commons.
o Voting will follow the "standard Apache voting guidelines"
[ be nice to refer to an Incubator doc here ]
o All code donations [to the ASF, destined for Apache Commons]
arrive via the Incubator, unless the Incubator states they can
be placed directly into Commons.
o Existing Commons committers can start new components without a
detour to the Incubator. These new components must be approved
by the PMC and must meet the (TBD) goals of Apache Commons.
Pending issues:
o Coming up with a set of bylaws for the project
o Enabling Reply-to on the @commons lists
(pmc@ will *not* use reply-to munging, but user lists
will be determined by user majority; this item applies
to lists for which the decision has not yet been made)
+1: aaron, coar, donaldp, geirm, acoliver, mas, bayard, sanders
-1: fitz, gstein, jerenkrantz, striker, jim
o The name 'Commons' has caused some heartburn with the
Jakarta community because of the Jakarta-Commons project.
Should we rename to avoid conflicts and keep the peace?
Conflicts would include Java namespace as well as
philosophical aspects.
+1:
+0: coar (i'm willing)
-0: jerenkrantz, donaldp, striker, gstein, fitz
-1: sanders
o If we rename, to what? What words/names describe our
purpose?
- toolbox
+0: gstein (I'd be +1 but for the confusion with the existing
Apache Toolbox project, but *really* like this
name)
- toolchest
+0.5: gstein
- tools
+0: gstein
-1: donaldp (tools are different to components)
- components
+0: gstein (a bit long)
- util
- library
+0: gstein (doesn't fit well with perl/python "modules")
- suite (sweet?)
- belt (as in bat-belt or tool-belt)
- mcgyver
- foundry or mill
+1: sanders (maybe too 'SourceForgeesque')
-0: donaldp (If reorg goes through we may have multiple
foundaries or federations for different "concepts")
- federation
- share or shared
- stuff
+.3: fitz :)
- ?
o Style for the mailing lists:
One community mailing list, with specific breakouts:
+1: fitz, jerenkrantz, sanders, coar,
donaldp (lets start here and evolve)
+0.5: mas
-0: aaron (too early)
Topical mailing lists:
+1: gstein, scolebourne, acoliver, striker
-0: aaron (too early), jerenkrantz
-0.1: mas, sanders (too early for this), donaldp
-1: coar
Per-language mailing lists:
-0: aaron (too early)
-0.1: mas
-1: gstein, sanders, fitz, jerenkrantz, striker, coar
Per-component mailing lists as a default (breakouts will create
these as a matter of course, this is about the default)
+0.7: mas
-0: aaron (too early)
-0.9: sanders
-1: gstein, fitz, jerenkrantz, striker
o A number of very valid issues have been brought up on the
list. We need to figure out how the Commons Project will
deal with each of these, in terms of new components and
how those components will contain code projects. This list
is only meant to keep record of all the issues:
- Releasable pieces
- Release rules
- Voting scope
- Directory structure and naming conventions
- Coding style
- Build system consistency (or inconsistency)
- Namespace issues (esp. w/ java)
- Language vs. Functional
o Default commit privileges
- Commons-wide
+1:
-1: gstein, striker, donaldp
- Per-component
+1: gstein, striker, donaldp, jerenkrantz
-1:
- Per-component with self-chosen aggregation
+1: gstein, donaldp
-1:
o Granularity of CVS repositories for components (this excludes
commons-site)
- Commons-wide
+1: gstein, donaldp, jerenkrantz
-1:
- Per-topic
+1:
-0: gstein, donaldp, jerenkrantz
-1:
- Per-component
+1:
-1: gstein, donaldp, jerenkrantz
Project Mission:
What is the project's mission? Our statement of goals/mission/vision
should arise from the answers to the following and other questions:
(jim notes that defining something after the fact seems very backwards
and broken; gstein notes that we're refining the board-provided
charter)
o Should commons have an sandbox component to ease infrastructure
burden on smaller code bases?
+1: coar, donaldp, jerenkrantz, gstein, sanders (non-binding)
+0: fitz
-0: striker
-1: jim (the PMC is about reusability, not sandbox),
aaron (what jim said; and go see incubator)
o What types of components would be appropriate for this project?
("in scope")
- Tools that help/promote reusability?
Hypothetical: ant, jlibtool, ASF-based autoconf
+1: jerenkrantz, gstein, striker, fitz, sanders (non-binding)
-0: donaldp (prefer a tools PMC for that)
-1: aaron (too broad, don't belong here)
- Development frameworks?
Hypothetical: avalon
+1: fitz
-0: donaldp (how do we determine this given we would prolly
accept it if it was new?)
-1: gstein (the avalon components, but not the whole bugger),
striker, sanders (non-binding)
- Components that fit the (TBD) goals of Commons, have a more
"logical" home elsewhere in the ASF, but were rejected by that
home?
+1: gstein, donaldp
0: striker (on a case by case basis, taking reasons for rejection
seriously into account. Abstain from vote until
rephrased),
fitz (what striker said), aaron (what fitz said)
-1: jerenkrantz, sanders (non-binding)
FOLD BELOW VOTES INTO ABOVE? (i.e. eliminate the "donation" wording)
- Donations that could fit but have a more obvious (proper) home which
has already rejected it?
+1: coar, donaldp, gstein (note the "might fit" term)
-0:
-1: jerenkrantz, jim, aaron, striker, fitz
- Existing ASF components whose committers believe that they
are a better fit under commons and the commons PMC agrees?
(If this component were brought up as new, we would accept it.)
+1: coar, donaldp, jerenkrantz, striker, gstein, fitz
-1: jim (by this definition httpd could be in commons)
(gstein says: see the "if" part; we wouldn't accept httpd)
(jim says: until we better define what the PMC would or
would not accept, then this seems too wishy-washy to me)
(gstein says: jim, you're blocking closure on this;
how would you refine the phrasing here; the intent
here is to accept components from the other Commons
projects or projects with reusable component),
aaron (we need to differenciate ourselves from other
libraries first, namely APR)
- Packages being worked on by Apache developers, with a clear
affiliation, that can't or won't be bundled? (E.g., an
httpd module)
+1: coar, donaldp
-1: jerenkrantz, striker, gstein, fitz, jim, aaron
CLOSE THIS? (as "not passed"; what is a good way to phrase this?)
- Should we have a minimum bar of entry for components?
+1:
-0: donaldp, gstein
-1:
- Should we have a minimum set of requirements before components
are released?
+1: donaldp, gstein (mixed, see below), striker
-1: jerenkrantz (what is released?)
- If yes to above then which things should be part of minimum
requirements?
documentation: require basic overview and user docs
+1: donaldp
-0: gstein (recommend highly, but let the committers determine
what is right for the component),
striker, jerenkrantz
-1:
uptodate website: require website be updated to latest release
but may still host previous release docs.
+1: donaldp, gstein, striker
-0: jerenkrantz
-1:
unit tests: (okay so this will never get consensus but ...)
+1: donaldp
-1: gstein (unit tests should be recommended, but not
mandated; I also find it unreasonable for initial
development/pre-alpha releases, but it can make
sense for "final" types of releases),
striker, jerenkrantz
versioning standard: derived from
http://apr.apache.org/versioning.html
http://jakarta.apache.org/commons/versioning.html
+1: donaldp, gstein, striker, jerenkrantz
-1:
release process: derived from
http://jakarta.apache.org/commons/releases.html
http://jakarta.apache.org/turbine/maven/development/release-process.html
http://cvs.apache.org/viewcvs.cgi/jakarta-ant/ReleaseInstructions?rev=1.9.2.1&content-type=text/vnd.viewcvs-markup
+1: donaldp
-1: gstein (we should provide "best practices" but allow each
components' committers to define their rules),
striker, jerenkrantz
deprecation process: (java specific?)
http://jakarta.apache.org/turbine/maven/development/deprecation.html
+1: donaldp, gstein (I see this as part of the "versioning"
process, and we can provide best
practices here)
-0: jerenkrantz (kinda sorta versioning, but not quite)
-1:
CVS/Subversion branching:
http://jakarta.apache.org/turbine/maven/development/branches.html
+1: donaldp
-1: gstein (we should provide "best practices" but allow each
components' committers to define their rules),
striker, jerenkrantz
Candidate Projects:
o APR's serf project has voted itself to move into Commons.
- Should the PMC accept it as fitting the Commons goal?
+1: gstein, fitz, jerenkrantz, striker, donaldp
-1: aaron (no such thing as "the Commons goal", how can it fit it?)
- When should it move?
Whenever it likes:
+1: gstein, sanders, jerenkrantz, striker
+0: donaldp (+1 if we use subversion, but if using CVS
we should hold off until structure is decided upon)
-1: aaron (after we know why it fits)
Give us a while:
+1: fitz (what's the hurry?), aaron
-0: gstein (we're only talking about a small seed of a
codebase; it won't get in our way as we complete the
charter), striker
- Where should the CVS code be located?
commons/serf (each component under top-level)
+1: sanders (works well at jakarta-commons)
fitz (Please don't mix interface and implementation
of commons!), aaron
+0: jerenkrantz
-0.5: gstein
-1: donaldp (makes it difficult to update all related
projects with a single sweep)
commons/components/serf (all components under this dir,
leaving the top open for other non-code items)
+0: gstein, striker, donaldp (is this just dev with a
different name?
(gstein says "yes"))
-1: fitz, aaron, jerenkrantz
commons/clients/serf (topical-groups under top-level)
+1: gstein, jerenkrantz
-1: fitz, aaron, donaldp
commons/dev/serf (all components under "dev")
+1: gstein, donaldp (if we are having a single
monolithic repo for all commons)
-1: fitz, aaron, jerenkrantz
commons/bootstrap/serf (serf is very early stage, so maybe we
have a "bootstrap" area; this is different from Incubator
since the existing committers do not need "training")
+1: gstein, donaldp
-1: fitz, aaron, jerenkrantz
commons/???
commons/c/serf (separate out component based on language
and then have a flat structure underneath)
+1: donaldp
-1: jerenkrantz
- What mailing list should it use for dev discussions?
general@commons.apache.org: (one group for all discussion;
dev and non-dev alike)
-0.5: gstein
-1: striker, aaron, jerenkrantz
dev@commons.apache.org: (one group for dev discussion;
general@ remains for non-dev)
+1: gstein, fitz, sanders, jerenkrantz, striker, donaldp
clients-dev@commons.apache.org:
(this is really TOPICNAME-dev@ where I preselected
"clients" for TOPICNAME; this question is whether this
style would be appropriate)
+1: gstein, striker
-0: sanders, donaldp (maybe in the future but too early),
jerenkrantz
-1: aaron (what is "clients"? I'd probably be +1 if I knew
what that was)
- Note: serf has no web site, so there isn't a need to figure
that out right now.
Assets:
DNS: commons.apache.org
Mailing lists: general@commons.apache.org
announce@commons.apache.org
pmc@commons.apache.org
cvs@commons.apache.org
[ core-cvs@commons.apache.org in case we
create a commons-core CVS module ]
Web site: http://commons.apache.org/
Repositories: commons (code, info, etc)
commons-site (the web site)
PMC Members:
Aaron Bannert <aa...@apache.org>
Ken Coar <co...@apache.org>
Peter Donald <pe...@apache.org>
Justin Erenkrantz <je...@apache.org>
Brian W. Fitzpatrick <fi...@apache.org>
Jim Jagielski <ji...@apache.org>
Geir Magnusson Jr. <ge...@apache.org>
Greg Stein <gs...@lyra.org>
Sander Striker <st...@apache.org>
Note: Ken Coar is the Chair
PMC Members, pending Board approval:
none yet
[ this may become obsolete; the Board is discussing a way for the
Chair to directly alter the PMC membership; until then, however,
we need PMC members ratified by the board, and this tracks them ]
Committers:
none yet [still defining mission]
Invited Committers:
none yet
Current mission/charter as approved by the board:
'The Apache Commons PMC hereby is responsible for the creation
and maintenance of software related to reusable libraries and
components, based on software licensed to the Foundation.'
The complete text of the resolution that was passed is:
WHEREAS, the Board of Directors deems it to be in the best
interests of the Foundation and consistent with the
Foundation's purpose to establish a Project Management
Committee charged with the creation and maintenance of
open-source software related to reusable libraries and
components, for distribution at no charge to the public.
NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the "Apache Commons PMC", be
and hereby is established pursuant to Bylaws of the Foundation;
and be it further
RESOLVED, that the Apache Commons PMC be and hereby is
responsible for the creation and maintenance of software
related to reusable libraries and components, based on software
licensed to the Foundation; and be it further
RESOLVED, that the office of "Vice President, Apache Commons"
be and hereby is created, the person holding such office to
serve at the direction of the Board of Directors as the chair
of the Apache Commons PMC, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Commons PMC; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache Commons PMC:
Aaron Bannert
Ken Coar (chair)
Peter Donald
Justin Erenkrantz
Brian W. Fitzpatrick
Jim Jagielski
Geir Magnusson Jr.
Greg Stein
Sander Striker
NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ken Coar be and
hereby is appointed to the office of Vice President, Apache
Commons, to serve in accordance with and subject to the
direction of the Board of Directors and the Bylaws of the
Foundation until death, resignation, retirement, removal or
disqualification, or until a successor is appointed; and be it
further
RESOLVED, that the initial Apache Commons PMC be and hereby is
tasked with the creation of a set of bylaws intended to
encourage open development and increased participation in the
Apache Commons Project.
#
# Local Variables:
# mode: indented-text
# tab-width: 4
# indent-tabs-mode: nil
# tab-stop-list: (4 6 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80)
# End:
#