Re: Apache CVS (was Re: Lessons Learned)
please post this question to the right list (http://jakarta.apache.org/site/mail.html). FWIW i have used JMeter for web testing though (depending on your needs) cactus (http://jakarta.apache.org/cactus) may be more suitable. - robert On 14 Dec 2004, at 22:58, Jim Amini wrote: Hi, Has anyone used Jmeter for web testing? Please respond if you have used this tool or you know how to use it. Thanks, Jim. -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 2:57 PM To: Jakarta General List Subject: Re: Apache CVS (was Re: Lessons Learned) On 13 Dec 2004, at 22:20, Richard Bair wrote: Thanks everyone for your insight! Related to this, I have a question regarding the organizational structure of CVS. I noticed that cvs.apache.org has, predictably, a different package for all of the top-level projects, and even sub-projects (although all of the commons-components are considered components and not sub-projects, hence the lack of any of the components at this top level). I also noticed that each of the websites is listed as [projectname]-site. I'm certainly not the worlds foremost expert at CVS, so I naturally assume that since apache is laid out this way that this must a great way to lay out a project its sub-projects in CVS. Is this so? What are the pros/cons to doing it this way, as opposed to a true tree structure? I assume it has something to do with the way CVS does things. (though it is the conventional way to lay out CVS projects) i suspect that this organization grew rather than being planned. (though it may well be easier to manage permissions with this structure.) we're moving to subversion and there have been quite a few discussions about the best ways of laying our repositories recently. if you can use subversion, seriously consider using it. the way our subversion repository is laid out is a little different. - 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]
Re: Apache CVS (was Re: Lessons Learned)
we're moving to subversion and there have been quite a few discussions about the best ways of laying our repositories recently. if you can use subversion, seriously consider using it. the way our subversion repository is laid out is a little different. - robert Hmm... I have been thinking about subversion. Collabnet is doing our hosting, so moving to subversion instead of cvs *shouldn't* be a big deal from a technical standpoint. I don't know how well supported subversion is via IDE's and the like. I assume there is a good web client for subversion as well? How is apache changing its layout for subversion? I'll check the archives for this list and see what is mentioned, are there any other good resources for seeing how Jakarta is going to use subversion? Thanks Richard __ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache CVS (was Re: Lessons Learned)
Richard, The IDE most people seem to talk about most (Eclipse) has a plugin called Subclipse (search for it on Tigris). It works, but it isn't as well supported as CVS. For example, the synchronize perspective doesn't work yet. But, tool support is a which comes first? problem, as more projects move towards Subversion, more widely used IDEs will support it out-of-the-box (but, who gets software in a box these days?). As far as Jakarta's eventual move to Subversion, you can see the start here: http://svn.apache.org/repos/asf/jakarta/ I believe the plan is to have a directory per subproject. Below that, structure will depend on what an individual subproject needs. But, there are some tricky questions to answer especially in subprojects with multiple artifacts. Take jakarta commons as an example. We still haven't decided where our trunk, tags, and branches will go. Tim -Original Message- From: Richard Bair [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 5:37 PM To: Jakarta General List Subject: Re: Apache CVS (was Re: Lessons Learned) we're moving to subversion and there have been quite a few discussions about the best ways of laying our repositories recently. if you can use subversion, seriously consider using it. the way our subversion repository is laid out is a little different. - robert Hmm... I have been thinking about subversion. Collabnet is doing our hosting, so moving to subversion instead of cvs *shouldn't* be a big deal from a technical standpoint. I don't know how well supported subversion is via IDE's and the like. I assume there is a good web client for subversion as well? How is apache changing its layout for subversion? I'll check the archives for this list and see what is mentioned, are there any other good resources for seeing how Jakarta is going to use subversion? Thanks Richard __ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com - 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: Lessons Learned
On 13 Dec 2004, at 01:04, Felipe Leme wrote: On Sun, 2004-12-12 at 21:15, robert burrell donkin wrote: though committing a few risky patches in the hope of recruiting a new committer might seem like a good plan, there are definite drawbacks. I agree. I didn't mean that all patches, but they should at least be 'acknowledged'. Even a comment like 'this patch seems great, but I do not have time to carefully analyze it right now' would be better than simply ignoring it. i'd agree with this. though i find it is often very difficult to achieve :( flamewars are rarer in bugzilla and it can save time in the long run (like next release time) to give a good reason why a patch won't be applied (especially when it's a design reason). a request for additional work from the patcher is also worth noting (if this is what's stopping the patch being applied). - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache CVS (was Re: Lessons Learned)
On 13 Dec 2004, at 22:20, Richard Bair wrote: Thanks everyone for your insight! Related to this, I have a question regarding the organizational structure of CVS. I noticed that cvs.apache.org has, predictably, a different package for all of the top-level projects, and even sub-projects (although all of the commons-components are considered components and not sub-projects, hence the lack of any of the components at this top level). I also noticed that each of the websites is listed as [projectname]-site. I'm certainly not the worlds foremost expert at CVS, so I naturally assume that since apache is laid out this way that this must a great way to lay out a project its sub-projects in CVS. Is this so? What are the pros/cons to doing it this way, as opposed to a true tree structure? I assume it has something to do with the way CVS does things. (though it is the conventional way to lay out CVS projects) i suspect that this organization grew rather than being planned. (though it may well be easier to manage permissions with this structure.) we're moving to subversion and there have been quite a few discussions about the best ways of laying our repositories recently. if you can use subversion, seriously consider using it. the way our subversion repository is laid out is a little different. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache CVS (was Re: Lessons Learned)
Hi, Has anyone used Jmeter for web testing? Please respond if you have used this tool or you know how to use it. Thanks, Jim. -Original Message- From: robert burrell donkin [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 2:57 PM To: Jakarta General List Subject: Re: Apache CVS (was Re: Lessons Learned) On 13 Dec 2004, at 22:20, Richard Bair wrote: Thanks everyone for your insight! Related to this, I have a question regarding the organizational structure of CVS. I noticed that cvs.apache.org has, predictably, a different package for all of the top-level projects, and even sub-projects (although all of the commons-components are considered components and not sub-projects, hence the lack of any of the components at this top level). I also noticed that each of the websites is listed as [projectname]-site. I'm certainly not the worlds foremost expert at CVS, so I naturally assume that since apache is laid out this way that this must a great way to lay out a project its sub-projects in CVS. Is this so? What are the pros/cons to doing it this way, as opposed to a true tree structure? I assume it has something to do with the way CVS does things. (though it is the conventional way to lay out CVS projects) i suspect that this organization grew rather than being planned. (though it may well be easier to manage permissions with this structure.) we're moving to subversion and there have been quite a few discussions about the best ways of laying our repositories recently. if you can use subversion, seriously consider using it. the way our subversion repository is laid out is a little different. - 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]
Apache CVS (was Re: Lessons Learned)
Thanks everyone for your insight! Related to this, I have a question regarding the organizational structure of CVS. I noticed that cvs.apache.org has, predictably, a different package for all of the top-level projects, and even sub-projects (although all of the commons-components are considered components and not sub-projects, hence the lack of any of the components at this top level). I also noticed that each of the websites is listed as [projectname]-site. I'm certainly not the worlds foremost expert at CVS, so I naturally assume that since apache is laid out this way that this must a great way to lay out a project its sub-projects in CVS. Is this so? What are the pros/cons to doing it this way, as opposed to a true tree structure? I assume it has something to do with the way CVS does things. Thanks again Richard __ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
Unless, for example, you do this intentionally ;) Oliver On Sun, 12 Dec 2004 15:30:10 -0200, Felipe Leme [EMAIL PROTECTED] wrote: I would add a note to Danny's comment: treat contributors as your primary users. I have seem many projects (inside and outside ASF) where people submit patches and the patches are just ignored, without even an explanation why it was not accepted. I know that applying a patch is not that simple in most cases, but I think the risk of breaking something is lesser than the risk of losing a good contributor. After all, if the patch breaks something, you can fix it later; but if you piss-off a contributor he/she will probably put his/her efforts in another project. -- Felipe On Fri, 2004-12-10 at 07:28, Danny Angus wrote: Encourage anyone to contribute, create a welcoming culture but let people earn your trust, don't form a clique. Don't form a clique. Don't patronise - 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: Lessons Learned
On 12 Dec 2004, at 17:30, Felipe Leme wrote: I would add a note to Danny's comment: treat contributors as your primary users. I have seem many projects (inside and outside ASF) where people submit patches and the patches are just ignored, without even an explanation why it was not accepted. I know that applying a patch is not that simple in most cases, but I think the risk of breaking something is lesser than the risk of losing a good contributor. After all, if the patch breaks something, you can fix it later; but if you piss-off a contributor he/she will probably put his/her efforts in another project. there is some truth buried somewhere in there... the time required to review, correctly and apply a patch is often underestimated. projects with too little available committer energy may get into a viscous circle whereby new committers cannot be recruited because there's too little energy to review patches. one way round this problem is to encourage users and developers to review patches submitted by others. it's also useful to try to do some sort of preliminary review and offer some kind words as soon as possible after a patch is posted even if work on the core project prevents a full review at this time. however, the quality of patches applied is crucial to the long term health of a project. reviewing and rewriting patches is the only way that developers are taught the standards required by the project. applying substandard patches shouldn't break the project in the short term (providing that it's adequately unit tested) but often produces headaches in the medium and long term. though committing a few risky patches in the hope of recruiting a new committer might seem like a good plan, there are definite drawbacks. the energy gained by recruiting a new committer (in this fashion) can easily be lost to the mentoring and refactoring required to produce code of the correct quality align with the goals of the project. IMHO it's almost always better (in the long term) for a developer to prove that they understand the direction and philosophy of a project by producing good patches which require no correction before they are elected a committer. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
On Sun, 2004-12-12 at 21:15, robert burrell donkin wrote: though committing a few risky patches in the hope of recruiting a new committer might seem like a good plan, there are definite drawbacks. I agree. I didn't mean that all patches, but they should at least be 'acknowledged'. Even a comment like 'this patch seems great, but I do not have time to carefully analyze it right now' would be better than simply ignoring it. -- Felipe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
I would add a note to Danny's comment: treat contributors as your primary users. I have seem many projects (inside and outside ASF) where people submit patches and the patches are just ignored, without even an explanation why it was not accepted. I know that applying a patch is not that simple in most cases, but I think the risk of breaking something is lesser than the risk of losing a good contributor. After all, if the patch breaks something, you can fix it later; but if you piss-off a contributor he/she will probably put his/her efforts in another project. -- Felipe On Fri, 2004-12-10 at 07:28, Danny Angus wrote: Encourage anyone to contribute, create a welcoming culture but let people earn your trust, don't form a clique. Don't form a clique. Don't patronise - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
robert burrell donkin wrote: beware too many organizational layers. flat is best. having a single sub-project with many releasables artifacts sharing the same community space (mailing lists, committer lists, voting eligability and so on) has proved more successful (see jakarta commons) than a complex web of sub-sub-sub-projects. factor along community lines: groups working on different releasables being unhappy about sharing the same community space is a good sign that they are two separate projects. (most modern email clients have good filtering support so provided conventions are adopted, several different code bases can be easily support on a single mailing list. for those unwilling or unable to set up filters, using a news reader and www.gmane.org works well.) +1 Don't be afraid of forks or duplication. If someone wants to try something out on their own, let them. But that doesn't mean you have to host it in the original project. There's plenty of space for similar and even competing software projects. A single project does not have to be everything to everyone. Some other lessons I learned in working with Apache Avalon: http://www.jadetower.org/muses/archives/000146.html jaaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
On 10 Dec 2004, at 09:28, Danny Angus wrote: If you were starting all over today, what things would you have done differently? What are the blind alleys? snip Keep it simple. Keep it public. Have one official communication channel for decision making, we use well publicised mailinglists for a reason, and stick to it, keep traffic on the lists so that everone can see whats going on now and what went on in the past. Encourage anyone to contribute, create a welcoming culture but let people earn your trust, don't form a clique. Don't form a clique. Don't patronise or underestimate people just because they can't use the tool or don't have english as their native tounge. Always try to get consensus. Have a clear and acceptable policy for expelling people and then try your damnedest not to ever invoke it. Make sure your product is in demand and of high quality. +1 danny's covered all the fundamentals well but here are a few random personal recommendations: unit test everything. encourage a healthy culture where developers contributing code patches and users reporting bugs contribute unit test code. let everyone know exactly how much you value documentation patches. documentation is of equal value to code and don't be afraid to make people committers who have only contributed documentation. remember the rule of three: it takes three committers to form a quorum. the natural process by which committers are replenished seems to break down when the number of committers falls too low. action may be needed if the number of active committers on an active project falls too low. beware too many organizational layers. flat is best. having a single sub-project with many releasables artifacts sharing the same community space (mailing lists, committer lists, voting eligability and so on) has proved more successful (see jakarta commons) than a complex web of sub-sub-sub-projects. factor along community lines: groups working on different releasables being unhappy about sharing the same community space is a good sign that they are two separate projects. (most modern email clients have good filtering support so provided conventions are adopted, several different code bases can be easily support on a single mailing list. for those unwilling or unable to set up filters, using a news reader and www.gmane.org works well.) mentor new committers and projects either formally or informally. this is the best way to ensure continuity of culture. devise a way for sub-projects to be monitored and potential issues picked up before they blow up. (this is an area where jakarta has had problems in the past and IMHO we don't have good answers for this one.) take legal issues seriously and make sure a few trusted people have the means to act first and discuss later. these actions should be provision pending a properly constituted decision. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lessons Learned
Richard, Hi. I was wondering; what are the lessons learned? Everything you see is a lesson learned, what you see in practice is our best, but still admittedly flawed, practice. If you were starting all over today, what things would you have done differently? What are the blind alleys? I'm not sure that there is much, some practices have evolved and others have been abandoned or withered away, management structures are changing, but I suspect they always change for any project OS or commercial which has some life about it. I've set up commercial projects for former employees based upon the Apache Way and they do tend to work, it is all about empowering people to make the decisions which they are best placed to make, but at the same time ensuring peer review and oversight to ensure consistency and quality. The important thing to remember is that you're working with volunteers, hell we're all volunteers, and if you suceed they'll all be way smarter, and busier, than you are. So you have to keep the bar to contribution low. It must be easy for anyone who has the knowledge you need to contribute it. Keep the need for knowledge as close to the focus of you project as you can, don't make people have to learn how to use new technology just to participate. Don't have a requirement which makes people spend money or sign contracts in order to become a first class citizen. Value each and every contributor highly, judge people only on their merit. Keep it simple. Keep it public. Have one official communication channel for decision making, we use well publicised mailinglists for a reason, and stick to it, keep traffic on the lists so that everone can see whats going on now and what went on in the past. Encourage anyone to contribute, create a welcoming culture but let people earn your trust, don't form a clique. Don't form a clique. Don't patronise or underestimate people just because they can't use the tool or don't have english as their native tounge. Always try to get consensus. Have a clear and acceptable policy for expelling people and then try your damnedest not to ever invoke it. Make sure your product is in demand and of high quality. Also, I have been researching and designing the build process for these various projects. I've looked into using Maven, in particular. It looks like you guys are using Ant to drive your build process ~ are the reasons based on history or did maven not provide the flexibility you wanted? Do you like the way you are generating your websites right now? Actually it is a decison made by the people who are going to use it, don't constrain people by imposing unnecessary boundaries. Opinion is mixed about how we generate the sites its not perfect (having several different processes each with its own strengths and weaknesses) but it works enough to get the job done. If you look around you'll see that as well as Maven and Ant there are a range of choices made by sub-projects and other Apache projects about how to manage this that or the other part of the lifecycle. Not all projects use the same version labelling, though most use a variation on a theme, not everyone uses the same wiki or bug tracking tool, though there are Apache systems available, it a matter of taste. As long as you are clear about what you are doing and what the benefit is, can justify it, and it doesn't raise legal or security issues there's no real reason why you shouldn't do it. There is an infrastructure which provides mailing lists, wiki, version control, web servers etc. But there are few hard and fast rules about what you *must* do or how you *must* do it. Those that there are are there largely for security and legal reasons, everything else is decided on its merits often from bitter experience. Jakarta is a meritocracy, I believe that that is why it works. But I think the real lesson for you is, don't ask *us*, have a look at what we do but ask your own community to make these choices. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may
Re: Lessons Learned
Thanks everybody for their input. Jakarta is a meritocracy, I believe that that is why it works. But I think the real lesson for you is, don't ask *us*, have a look at what we do but ask your own community to make these choices. Will do! Thanks Richard __ Do you Yahoo!? Send a seasonal email greeting and help others. Do good. http://celebrity.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Lessons Learned
Hey Folks, I'm working on the JDNC project over at java.net where we are currently considering making JDNC a jakarta-like entity with several blessed open source projects and an incubator. We envision JDNC focusing expecially on Swing related components and frameworks. Y'all are the experts when it comes to hosting open source projects and an open source community. I was wondering; what are the lessons learned? If you were starting all over today, what things would you have done differently? What are the blind alleys? Also, I have been researching and designing the build process for these various projects. I've looked into using Maven, in particular. It looks like you guys are using Ant to drive your build process ~ are the reasons based on history or did maven not provide the flexibility you wanted? Do you like the way you are generating your websites right now? Thanks for your wisdom! Richard __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
