Re: [POLL] drop 8
+1 On Jul 4, 2005, at 2:15 AM, Henri Yandell wrote: +1 On Sun, 3 Jul 2005, robert burrell donkin wrote: 8. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. doesn't seem very relevant. i think that it'd be simpler just to drop it. here's my +1 - robert --8--- [ ] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Added svn resource to library.xml
Henri Yandell wrote: Is there a BZ or Jira where one can open issues and add patches to the jakarta-site module? Or is all such requests handled on this ml? This mailing list is the best place. Hi! Here's the patch that I promised. Regards, Fredrik Westermarck Index: xdocs/site/library.xml === --- xdocs/site/library.xml (revision 208774) +++ xdocs/site/library.xml (arbetskopia) @@ -73,6 +73,12 @@ /p p +ba href=http://svnbook.red-bean.com/;Version Control with Subversion/a/bbr/ +Written by Ben Collins-Sussman, Brian W. Fitzpatrick amp; C. Michael Pilato. +This is a Subversion manual that currently provides information about Subversion 1.0 and 1.1. +/p + +p h3Source Code Philosophy Resources /h3 The following are a set of articles written about the recent source code movements that help illustrate some of the attributes of a collaborative project such as this. You may not agree with all of - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][POLL] drop point 12
+1 - robert On Mon, 2005-07-04 at 02:16 -0400, Henri Yandell wrote: We should do the same on Commons at some point. Throw out the ones that seem dead. Hen On Sun, 3 Jul 2005, robert burrell donkin wrote: i count 4 +1's the consensus seems to be in favour of removal so that's what i'm going to do. i propose to leave retain the number by noting those that have been deleted (rather than removing them). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [POLL] drop 8
i count 5 +1's and no objections so i'm going to go ahead and delete it. - robert On Sun, 2005-07-03 at 19:44 +0100, robert burrell donkin wrote: 8. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. doesn't seem very relevant. i think that it'd be simpler just to drop it. here's my +1 - robert --8--- [ ] +1 Get rid! [ ] -1 Keep it (please give a reason...) -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by RobertBurrellDonkin: http://wiki.apache.org/jakarta/DraftCharterForWebComponentCommons The comment on the change is: Dropped 8 as per POLL -- 1. The packages should fit within a unified package hierarchy. 1. In general, packages should provide an interface and one or more implementations of that interface, or implement another interface already in use. * The packages should have boring functional names. Implementations may choose more 'exciting' designations. -1. Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper. +1. '''DELETED''' ''Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper.'' 1. External configuration files are discouraged, but if required, XML format files are preferred for configuration options. 1. Each package will be hosted on its own page on the subproject Web site, and will also be indexed in a master directory. 1. The subproject will also host a top-level 'general' mailing list in addition to any lists for specific packages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] Added svn resource to library.xml
committed. many thanks. - robert On Tue, 2005-07-05 at 20:19 +0200, Fredrik Westermarck wrote: Henri Yandell wrote: Is there a BZ or Jira where one can open issues and add patches to the jakarta-site module? Or is all such requests handled on this ml? This mailing list is the best place. Hi! Here's the patch that I promised. Regards, Fredrik Westermarck Plain text document attachment (library.diff) Index: xdocs/site/library.xml === --- xdocs/site/library.xml(revision 208774) +++ xdocs/site/library.xml(arbetskopia) @@ -73,6 +73,12 @@ /p p +ba href=http://svnbook.red-bean.com/;Version Control with Subversion/a/bbr/ +Written by Ben Collins-Sussman, Brian W. Fitzpatrick amp; C. Michael Pilato. +This is a Subversion manual that currently provides information about Subversion 1.0 and 1.1. +/p + +p h3Source Code Philosophy Resources /h3 The following are a set of articles written about the recent source code movements that help illustrate some of the attributes of a collaborative project such as this. You may not agree with all of - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin
Dear Wiki user, You have subscribed to a wiki page or wiki category on Jakarta Wiki for change notification. The following page has been changed by RobertBurrellDonkin: http://wiki.apache.org/jakarta/DraftCharterForWebComponentCommons The comment on the change is: Changed to reflect consensus about mailing lists -- 1. The package library is not a framework but a collection of components designed to be used independently. 1. Each package must have a clearly defined purpose, scope, and API -- Do one thing well, and keep your contracts. 1. Each package is treated as a product in its own right. - 1. Each package has its own status file, release schedule, version number, QA tests, documentation, mailing list, bug category, and individual JAR. + 1. Each package has its own status file, release schedule, version number, QA tests, documentation, '''DELETED''' ''mailing list,'' bug category, and individual JAR. 2. Each package must clearly specify any external dependencies, including any other Commons packages, and the earliest JDK version required. 1. External dependencies on optional and third-party codebases should be minimized. 2. All necessary dependencies must be recorded in the MANIFEST.MF file of the package JAR, in the manner recommended in the JDK 1.3 documentation describing 'system extensions' @@ -49, +49 @@ 1. '''DELETED''' ''Packages are encouraged to either use JavaBeans as core objects, a JavaBean-style API, or to provide an optional JavaBean wrapper.'' 1. External configuration files are discouraged, but if required, XML format files are preferred for configuration options. 1. Each package will be hosted on its own page on the subproject Web site, and will also be indexed in a master directory. -1. The subproject will also host a top-level 'general' mailing list in addition to any lists for specific packages. +1. '''DELETED''' ''The subproject will also host a top-level 'general' mailing list in addition to any lists for specific packages.'' '''ADDED''' The subproject will provide two mailing lists: one for users and the other for developers. Posters should prefix the subject with the name of the component to allow easy filtering. 1. '''DELETED''' ''The subproject will also provide a single JAR of all stable package releases. It may also provide a second JAR with a subset of only JDK 1.1 compatible releases. A gump of nightly builds will also be provided.'' 1. Volunteers become committers to this subproject in the same way they are entered to any Jakarta subproject. Being a committer in another Jakarta subproject is not a prerequisite. 1. Each committer has karma to all the packages, but committers are required to add their name to a package's status file before their first commit to that package. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
there doesn't see any enthusiasm for those new ideas and no objections to phil's draft. i think we should go ahead and make the changes suggested by phil. - robert On Sun, 2005-07-03 at 22:39 +0100, robert burrell donkin wrote: On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote: Here is a stab at replacement text for 15, 17 and 18. great :) looks good but threw up some ideas... 15-1 Any member of the community may propose a new package. To be accepted, a package proposal must receive majority approval of the subproject committers and at least one committer must volunteer to serve as an initial package team member. Proposals should identify the rationale for the package, its scope, its interaction with other packages and products, the insert-subproject-name resources, if any, to be created, the initial source from which the package is to be created, and the sponsoring committers. 15-2 The subproject will maintain an svn repository, referred to as the isandbox/i, as a workplace for new packages. Once approved, new packages must all begin in the sandbox. Any apache committer may contribute code directly to the sandbox and this code may form the initial source for new packages. Code from existing apache projects can, with the support of the contributing projects, also be imported directly into the sandbox. Finally, patches contributed incrementally by community members may be committed to the sandox by a subproject committer. If the initial source for a new package is from outside of apache, the new package must be brought into apache via the apache incubator. not sure but wonder whether we might need to tightening this last sentence so that it can't be read as implying that having only a portion of the initial source from external sources is ok. opinions? 15-3 A majority vote among subproject commiters is required to graduate a package from the sandbox to become a proper package. Only proper packages may make releases. If a package remains in the sandbox for more than six months, a majority vote will be required to prevent its being archived from svn and removed from the subproject web site and any other public locations (e.g. nightly or continuous integration builds). Proper packages may not release code with dependencies on sandbox packages. 1. i wonder whether it'd be better to have bi-annual reviews to simplify administration. in january, review all sandbox components which were created before the previous july. could run them as a single vote. 2. i wonder whether we actually need to remove them from svn: just could copy them into an archive directory. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[POLL] Marking changes
(Was: Re: [Jakarta Wiki] Update of
DraftCharterForWebComponentCommons by RobertBurrellDonkin) - pasted
here since the title was getting too long ;-)
Thanks for making the changes Robert!
I propose we wrap changes in {{{DELETED}}} and {{{/DELETED}}} tags
(or ADDED tags, as appropriate) rather than purely relying on font
minutae. Amongst other things, that will work better for
accessibility. I'm +1.
Does anyone mind?
-Rahul
On 7/5/05, Apache Wiki [EMAIL PROTECTED] wrote:
snip/
- 1. Each package has its own status file, release schedule, version
number, QA tests, documentation, mailing list, bug category, and individual
JAR.
+ 1. Each package has its own status file, release schedule, version
number, QA tests, documentation, '''DELETED''' ''mailing list,'' bug
category, and individual JAR.
snap/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [POLL] Marking changes
On Tue, 2005-07-05 at 15:23 -0400, Rahul Akolkar wrote:
(Was: Re: [Jakarta Wiki] Update of
DraftCharterForWebComponentCommons by RobertBurrellDonkin) - pasted
here since the title was getting too long ;-)
Thanks for making the changes Robert!
I propose we wrap changes in {{{DELETED}}} and {{{/DELETED}}} tags
(or ADDED tags, as appropriate) rather than purely relying on font
minutae. Amongst other things, that will work better for
accessibility. I'm +1.
if it'll make things easier to read and you're willing to do the
formatting changes, i'm +1
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
+1 On 7/5/05, robert burrell donkin [EMAIL PROTECTED] wrote: there doesn't see any enthusiasm for those new ideas and no objections to phil's draft. i think we should go ahead and make the changes suggested by phil. - robert On Sun, 2005-07-03 at 22:39 +0100, robert burrell donkin wrote: On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote: Here is a stab at replacement text for 15, 17 and 18. great :) looks good but threw up some ideas... 15-1 Any member of the community may propose a new package. To be accepted, a package proposal must receive majority approval of the subproject committers and at least one committer must volunteer to serve as an initial package team member. Proposals should identify the rationale for the package, its scope, its interaction with other packages and products, the insert-subproject-name resources, if any, to be created, the initial source from which the package is to be created, and the sponsoring committers. 15-2 The subproject will maintain an svn repository, referred to as the isandbox/i, as a workplace for new packages. Once approved, new packages must all begin in the sandbox. Any apache committer may contribute code directly to the sandbox and this code may form the initial source for new packages. Code from existing apache projects can, with the support of the contributing projects, also be imported directly into the sandbox. Finally, patches contributed incrementally by community members may be committed to the sandox by a subproject committer. If the initial source for a new package is from outside of apache, the new package must be brought into apache via the apache incubator. not sure but wonder whether we might need to tightening this last sentence so that it can't be read as implying that having only a portion of the initial source from external sources is ok. opinions? 15-3 A majority vote among subproject commiters is required to graduate a package from the sandbox to become a proper package. Only proper packages may make releases. If a package remains in the sandbox for more than six months, a majority vote will be required to prevent its being archived from svn and removed from the subproject web site and any other public locations (e.g. nightly or continuous integration builds). Proper packages may not release code with dependencies on sandbox packages. 1. i wonder whether it'd be better to have bi-annual reviews to simplify administration. in january, review all sandbox components which were created before the previous july. could run them as a single vote. 2. i wonder whether we actually need to remove them from svn: just could copy them into an archive directory. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new components
robert burrell donkin wrote: there doesn't see any enthusiasm for those new ideas and no objections to phil's draft. i think we should go ahead and make the changes suggested by phil. I went ahead and updated, making some small changes to (hopefully) address the points above. I marked the items to be replaced as DELETED and added the replacement items at the end. Given that the discussion has referenced item numbers, I did not want to mess up the numbering. We can reorder as appropriate when the music stops. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: new Standard/JSTL subproject? [WAS Re: [Jakarta Wiki] Update of DraftCharterForWebComponentCommons by RobertBurrellDonkin]
Henri Yandell wrote: are there any committers involved with JSTL around? Sorry, I raised the question then entered in JavaOne-sleep-mode :( if not, would anyone like to volunteer to sound them out about a move to subproject status? I vote for Standard being a separate Jakarta sub-project. I've mentioned the idea on the taglibs-dev mailing list, no reply as yet. There hasn't being too many messages by the committers lately, specially on votes. So, tomorrow (I'm too tired now :-) I will send a big message summarizing all of these pending votes and hopefully we will get enough committer answers now... -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mailing lists for components [WAS Re: [PROPOSAL] subproject that's a home for bricks reusable in java web applications]
Martin Cooper wrote: +1 to just one dev and one user list, shared for all components, a la Jakarta Commons. Me too... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
