Monthly deployments, monthly releases? (long)

[Dave Johnson <da...@rollerweblogger.org>]

My group (the blogs.sun.com or BSC team) at Sun believes pretty  
strongly that small incremental releases are easier to document and  
deploy than large ones.  Following this philosophy, we deploy new  
features to our sites on a monthly basis. This presents some challenges  
for us because work directly with the Roller code-base and we don't  
maintain a separate fork of Roller.

I had been thinking that BSC would deploy each month, operating off of  
SVN HEAD, but the Roller project would make releases every couple of  
months -- when new features justify a release.  Each major Roller  
release (e.g. 1.2) would happen in a branch and would get one or more  
bug fixes releases (e.g. 1.2.1 and 1.2.2, etc.). I thought monthly  
releases were too frequent. My reasoning was this:

* Nobody would want to track the monthly releases
* Users who don't track will have more difficult upgrades
* Users who have deployed existing releases expect bugs to be fixed in  
those releases
* Users would want to stick with major releases for a long time

But there are problems with that. One problem is limited resources.  
Since BSC folks (Allen and I) are busy making monthly deployments, we  
have limited time to participate in the testing, documenting and  
releasing of big every-couple-of-months releases. We also have limited  
time (and limited interest) to work on fixing bugs in old releases of  
Roller.

Long story short, the BSC team is now pushing for monthly Roller  
releases to match the monthly BSC deployments. As a BSC team member, I  
have to advocate this and that is what I'm doing by writing this email.  
But as an independent Roller team member, I'm undecided. I'm not sure  
how I'd vote, so please help me out with some lively discussion.

So, let's say the Roller project makes monthly releases. What are the  
implications?

* The SVN HEAD must be very near stable at all times because a new  
release is never more than a month away. Any large development that  
takes more than a month must occur in a separate branch (as we're doing  
with Roller 2.0 / group blogging).

* It is no longer feasible to make bug fixes to old releases of Roller.  
The way you get new bug fixes is by keeping current on Roller.

* To make it easy for users to keep up with Roller we'll need to limit  
the frequency of database schema changes and when schema changes do  
occur, the database upgrade must be automated and trouble free.

The advantages of release early, release often are well known so I  
won't cover them here. You can read what ESR has to say about the  
philosophy here:
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ 
ar01s04.html

So my questions are:

    * How does the Roller community feel about monthly releases?
    * Is there any Apache policy that is relevant to this discussion?
    * How do we use the Apache voting rules to resolve this?


- Dave

Re: Monthly deployments, monthly releases? (long)

[Allen Gilliland <Al...@Sun.COM>]

I wanted to provide a few more counter arguments to the points made against short release cycles.

On Tue, 2005-08-09 at 06:11, Dave Johnson wrote:
> * Nobody would want to track the monthly releases

there is certainly overhead with tracking more releases, but i think a shorter release cycle should encourage us to keep this process simple.  you could also argue that smaller releases make each release easier to track because release notes and upgrade docs are kept very small and simple.

> * Users who don't track will have more difficult upgrades

i disagree.  if we enforce the rule with no database changes for minor releases then this should be very easy and will encourage users to upgrade.

> * Users who have deployed existing releases expect bugs to be fixed in  
> those releases
> * Users would want to stick with major releases for a long time

my experience in the web industry would lead me to say ... "no way, that's not how it works here."  i think we should always be encouraging users to keep up with the latest stable release and if users don't want to then they are on their own.  i think it's a huge amount of overhead to be providing bug fixes for all previous versions of roller.

> 
> So, let's say the Roller project makes monthly releases. What are the  
> implications?
> 
> * The SVN HEAD must be very near stable at all times because a new  
> release is never more than a month away. Any large development that  
> takes more than a month must occur in a separate branch (as we're doing  
> with Roller 2.0 / group blogging).

true, but i think we pretty much do this already.

> 
> * It is no longer feasible to make bug fixes to old releases of Roller.  
> The way you get new bug fixes is by keeping current on Roller.

not totally true, but in general i think this is fine.  if we really need to we can do a very small bug fix release for a given minor release, but the idea is to keep the entire code base moving forward.

> 
> * To make it easy for users to keep up with Roller we'll need to limit  
> the frequency of database schema changes and when schema changes do  
> occur, the database upgrade must be automated and trouble free.

agreed.  i think keeping schema changes limited to major releases only will work fine for this.

-- Allen

Re: Monthly deployments, monthly releases? (long)

[Matt Raible <mr...@gmail.com>]

On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> On Tue, 2005-08-09 at 11:22, Matt Raible wrote:
> > Dave and Allen,
> >
> > You guys are obviously biased in your votes here - primarily because
> > Roller is your job and you've been mandated to schedule the releases
> > to more fit their work schedule.  I don't blame you.
> >
> > You guys are contributing the most code, and handling all release
> > aspects - so I believe the decision is up to you.  I'm in favor of
> > whatever you guys advocate.  If you are going to go through with this,
> > it'd be nice to see a release schedule so we know when it's best to
> > commit code.  I'd like to integrate Acegi this week or next, but if
> > there's a release coming out soon, I should probably wait.
> 
> Dave and I are certainly influenced by our commitments to our team here at Sun, but ultimately the decision should come from the community at large.
> 
> I think a release schedule is a good idea and as usual we will want to communicate to everyone on the team when a release is nearing so that we can coordinate changes to the repository.  This also gives commiters a chance to better guage what release they want to target certain code for.
> 
> About commiting the Acegi stuff, my biggest concern here is not where/when to commit it but rather that I don't recall any formal proposal being sent around.  I know we talked about this a few times, but I like to see some kind of document that at least talks about ...
> 
> - are there db schema changes required, and if so what changes.
> - very generally, what is the new code design.  what classes are new, changed, removed?  how do they fit together?
> - what changes would there be to the UI, if any?
> 
> Hopefully I am not coming off as anal, but I am generally of the opinion that our greatest opportunity for teamwork comes at design time, not implemenation time.  So to really collaborate on this project as effectively as possible I think we need to have good design docs that are reviewed by everyone before coding beings (or gets too far along).

There should be no Java code changes required by Acegi, nor any
database changes.  I don't plan on committing anything until everyone
has looked at the code and approves it.  More than anything, I simply
plan on trying to make it work.  Since AppFuse used to use the same
authentication system that Roller does, and now it uses Acegi - it
should be an easy thing to implement.  I'm sorry if I implied I was
going to commit it as soon as I finished it - I will definitely write
up a detailed e-mail on how it works once I'm done.  At that time, we
can decided as a group if it should be committed or not.

Matt

> 
> -- Allen
> 
> 
> >
> > Matt
> >
> > On 8/9/05, Lance Lavandowska <la...@gmail.com> wrote:
> > > On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> > > >
> > > > > (2) Strict non-breakage policies on the trunk.  Successful build = full
> > > > > test passage.
> > > >
> > > > i'm not sure i agree here.  obviously we can't have ppl commiting code that is 25% complete or code that is completely broken, but who does that anyways?  i think most of us develop a feature in our own workspace and only commit it when we believe it's reasonably complete.
> > >
> > > Heh, Allen (as a relatively late-comer) isn't familiar with the
> > > Lavandowska "it's good enough" Principle.  I've often committed code
> > > that just-barely does what it is intended to do.  Often it's provided
> > > as a proof-of-concept, intended to elicit feedback and cooperation,
> > > that gets pushed into production.
> > >
> > > Now this mostly came about when we didn't do branches (I think because
> > > none of us were familiar/comfortable enough with them).  Now that I've
> > > trimmed my code contributions down to once-per-year I think there is
> > > much less danger from the Lavandowska Principle.
> > >
> > > Lance
> > >
> 
>

Re: Monthly deployments, monthly releases? (long)

[Allen Gilliland <Al...@Sun.COM>]

On Tue, 2005-08-09 at 13:59, Elias Torres wrote:
> - Will monthly releases include a decent amount of bug fixing or will
> it only be new features?

of course.  we'll include any bug fixes we can manage.  ultimately it's dependent on the priority of the bug.  and we fully expect that from time to time we will devote an entire release specifically to fixing bugs.

> - Will Dave/Allen work at all on community requirements?

hopefully we are always considering what the community wants when choosing what we work on, and at the very least we are working with the community when developing features to make sure we are solving not just our own problems.

> - What happens when the rest of the folks don't have the time
> bandwidth to design/spec out common features between Sun/BSC and rest
> of the community? Will you end up making all of the decisions
> regarding feature X? I guess this is how OS works anyways, whoever is
> writing the code makes the decisions. :-)

no, we never just "make the decision for the community".  we always try to involve the dev list whenever making changes that affect roller and of course if the dev community doesn't really speak up about something then it's possible we just move ahead with the attitude, "well, you had your chance to say something earlier."

> - Will every new feature *have* to be developed in branches to not
> interrupt your monthly schedule?

only if the developer is not willing to assure everyone that their code will be ready for the next release.  this is a good practice anways if you ask me.  if you are developing something at a slower pace then everyone else then you should have to work in a different branch.

> - I can't think of any more questions at this moment.

phew.

-- Allen


> 
> Regards,
> 
> Elias Torres
> 
> On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> > On Tue, 2005-08-09 at 11:22, Matt Raible wrote:
> > > Dave and Allen,
> > >
> > > You guys are obviously biased in your votes here - primarily because
> > > Roller is your job and you've been mandated to schedule the releases
> > > to more fit their work schedule.  I don't blame you.
> > >
> > > You guys are contributing the most code, and handling all release
> > > aspects - so I believe the decision is up to you.  I'm in favor of
> > > whatever you guys advocate.  If you are going to go through with this,
> > > it'd be nice to see a release schedule so we know when it's best to
> > > commit code.  I'd like to integrate Acegi this week or next, but if
> > > there's a release coming out soon, I should probably wait.
> > 
> > Dave and I are certainly influenced by our commitments to our team here at Sun, but ultimately the decision should come from the community at large.
> > 
> > I think a release schedule is a good idea and as usual we will want to communicate to everyone on the team when a release is nearing so that we can coordinate changes to the repository.  This also gives commiters a chance to better guage what release they want to target certain code for.
> > 
> > About commiting the Acegi stuff, my biggest concern here is not where/when to commit it but rather that I don't recall any formal proposal being sent around.  I know we talked about this a few times, but I like to see some kind of document that at least talks about ...
> > 
> > - are there db schema changes required, and if so what changes.
> > - very generally, what is the new code design.  what classes are new, changed, removed?  how do they fit together?
> > - what changes would there be to the UI, if any?
> > 
> > Hopefully I am not coming off as anal, but I am generally of the opinion that our greatest opportunity for teamwork comes at design time, not implemenation time.  So to really collaborate on this project as effectively as possible I think we need to have good design docs that are reviewed by everyone before coding beings (or gets too far along).
> > 
> > -- Allen
> > 
> > 
> > >
> > > Matt
> > >
> > > On 8/9/05, Lance Lavandowska <la...@gmail.com> wrote:
> > > > On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> > > > >
> > > > > > (2) Strict non-breakage policies on the trunk.  Successful build = full
> > > > > > test passage.
> > > > >
> > > > > i'm not sure i agree here.  obviously we can't have ppl commiting code that is 25% complete or code that is completely broken, but who does that anyways?  i think most of us develop a feature in our own workspace and only commit it when we believe it's reasonably complete.
> > > >
> > > > Heh, Allen (as a relatively late-comer) isn't familiar with the
> > > > Lavandowska "it's good enough" Principle.  I've often committed code
> > > > that just-barely does what it is intended to do.  Often it's provided
> > > > as a proof-of-concept, intended to elicit feedback and cooperation,
> > > > that gets pushed into production.
> > > >
> > > > Now this mostly came about when we didn't do branches (I think because
> > > > none of us were familiar/comfortable enough with them).  Now that I've
> > > > trimmed my code contributions down to once-per-year I think there is
> > > > much less danger from the Lavandowska Principle.
> > > >
> > > > Lance
> > > >
> > 
> >

Re: Sharing some stats

[Elias Torres <el...@gmail.com>]

Perfectly reasonable. I'll work on a design proposal. RollerWiki, right?

Elias

On 8/22/05, Allen Gilliland <Al...@sun.com> wrote:
> On Sun, 2005-08-21 at 19:33, Elias Torres wrote:
> > I'll try to prototype this when I get a chance if you guys tell me
> > you'd be interested in incorporating it.
> 
> we are always interested in useful new features developed by anyone, but if you really want to develop a feature this substantial you should start with a design plan and post it on the list for the other developers to look over and approve before you start too much coding.
> 
> i don't want to sound like a code nazi or anything, but personally i would likely reject pretty much any new code that didn't go through some form of design proposal before being submitted.  i just think this is a necessary quality control process.
> 
> -- Allen
> 
> 
> >
> > Elias
> >
> > On 8/16/05, Lance Lavandowska <la...@gmail.com> wrote:
> > > On 8/16/05, Elias Torres <el...@gmail.com> wrote:
> > > > Then we could write RewriteRules in Apache that translated these for example:
> > > >
> > > > http://www.jroller.com/page/fate/Weblog?catname=General into
> > > > http://www.jroller.com/static-content/fate/general/index.html
> > >
> > > Suggestion: write the static version to the user's resource directory:
> > > http://www.jroller.com/resources/fate/general/index.html
> > >
> > > The only problem with this is that it could interfere with the
> > > maxDirectorySize admin value (eating up space valuable to the user, so
> > > that they cannot upload a file).  Since currently that value only
> > > measures against the "base" resource directory for the user
> > > (/resources/fate) we can get aroudn this issue for the time being by
> > > writing all static content to a subdirectory.  THis stops working
> > > if/when we allow the user to create subdirectories.
> > >
> > > Lance
> > >
> 
>

Re: Sharing some stats

[Allen Gilliland <Al...@Sun.COM>]

On Sun, 2005-08-21 at 19:33, Elias Torres wrote:
> I'll try to prototype this when I get a chance if you guys tell me
> you'd be interested in incorporating it.

we are always interested in useful new features developed by anyone, but if you really want to develop a feature this substantial you should start with a design plan and post it on the list for the other developers to look over and approve before you start too much coding.

i don't want to sound like a code nazi or anything, but personally i would likely reject pretty much any new code that didn't go through some form of design proposal before being submitted.  i just think this is a necessary quality control process.

-- Allen


> 
> Elias
> 
> On 8/16/05, Lance Lavandowska <la...@gmail.com> wrote:
> > On 8/16/05, Elias Torres <el...@gmail.com> wrote:
> > > Then we could write RewriteRules in Apache that translated these for example:
> > >
> > > http://www.jroller.com/page/fate/Weblog?catname=General into
> > > http://www.jroller.com/static-content/fate/general/index.html
> > 
> > Suggestion: write the static version to the user's resource directory:
> > http://www.jroller.com/resources/fate/general/index.html
> > 
> > The only problem with this is that it could interfere with the
> > maxDirectorySize admin value (eating up space valuable to the user, so
> > that they cannot upload a file).  Since currently that value only
> > measures against the "base" resource directory for the user
> > (/resources/fate) we can get aroudn this issue for the time being by
> > writing all static content to a subdirectory.  THis stops working
> > if/when we allow the user to create subdirectories.
> > 
> > Lance
> >

Re: Sharing some stats

[Elias Torres <el...@gmail.com>]

wow. I did not know about your move away from OSCache. It tells you
how long I've been away from Roller. I found some post on google
around June 2004. Anyways, I still think that memory is not the way to
go since we keep recomputing pages that might not change for a long
time.

Regarding the library, it might be worth looking into to not have to
depend on Apache and having an entire blog on disk would totally
satisfy my requirement, no matter how Roller decides to serve it. :-)

Elias

On 8/22/05, Lance Lavandowska <la...@gmail.com> wrote:
> We actually moved away from OSCache due to a memory leak (I hear it's
> since been fixed, but don't know).
> 
> The reason I suggested an alternative file location, is that then we'd
> also have a mechanism by which the user can 'archive' her posts (add a
> "zip up your files for download" option ala Pebble).
> 
> Instead of Apache mod-rewrite, how about using the URLRewrite
> (https://urlrewrite.dev.java.net/) library?
> 
> Lance
> 
> On 8/21/05, Elias Torres <el...@gmail.com> wrote:
> > Lance,
> >
> > I'm not as concerned with the location on disk as I am with the actual
> > URL. The goal is to maintain the same URL pattern on the browser but
> > use instead a static version on disk. This is where RewriteRules come
> > in, but then we would depend on Apache. I think that if we can make
> > this optional, it would be great if we can pull this off.
> > Alternatively, we could explore OSCache disk-based caching so we don't
> > have to maintain an entire user's blog on memory. Also, I repeat, I
> > rather have Apache go straight to a static file, than the J2EE
> > container being hit just to read a file from disk.
> >
> > I'll try to prototype this when I get a chance if you guys tell me
> > you'd be interested in incorporating it.
> >
> > Elias
> >
> > On 8/16/05, Lance Lavandowska <la...@gmail.com> wrote:
> > > On 8/16/05, Elias Torres <el...@gmail.com> wrote:
> > > > Then we could write RewriteRules in Apache that translated these for example:
> > > >
> > > > http://www.jroller.com/page/fate/Weblog?catname=General into
> > > > http://www.jroller.com/static-content/fate/general/index.html
> > >
> > > Suggestion: write the static version to the user's resource directory:
> > > http://www.jroller.com/resources/fate/general/index.html
> > >
> > > The only problem with this is that it could interfere with the
> > > maxDirectorySize admin value (eating up space valuable to the user, so
> > > that they cannot upload a file).  Since currently that value only
> > > measures against the "base" resource directory for the user
> > > (/resources/fate) we can get aroudn this issue for the time being by
> > > writing all static content to a subdirectory.  THis stops working
> > > if/when we allow the user to create subdirectories.
> > >
> > > Lance
> > >
> >
>

Re: Sharing some stats

[Lance Lavandowska <la...@gmail.com>]

We actually moved away from OSCache due to a memory leak (I hear it's
since been fixed, but don't know).

The reason I suggested an alternative file location, is that then we'd
also have a mechanism by which the user can 'archive' her posts (add a
"zip up your files for download" option ala Pebble).

Instead of Apache mod-rewrite, how about using the URLRewrite
(https://urlrewrite.dev.java.net/) library?

Lance

On 8/21/05, Elias Torres <el...@gmail.com> wrote:
> Lance,
> 
> I'm not as concerned with the location on disk as I am with the actual
> URL. The goal is to maintain the same URL pattern on the browser but
> use instead a static version on disk. This is where RewriteRules come
> in, but then we would depend on Apache. I think that if we can make
> this optional, it would be great if we can pull this off.
> Alternatively, we could explore OSCache disk-based caching so we don't
> have to maintain an entire user's blog on memory. Also, I repeat, I
> rather have Apache go straight to a static file, than the J2EE
> container being hit just to read a file from disk.
> 
> I'll try to prototype this when I get a chance if you guys tell me
> you'd be interested in incorporating it.
> 
> Elias
> 
> On 8/16/05, Lance Lavandowska <la...@gmail.com> wrote:
> > On 8/16/05, Elias Torres <el...@gmail.com> wrote:
> > > Then we could write RewriteRules in Apache that translated these for example:
> > >
> > > http://www.jroller.com/page/fate/Weblog?catname=General into
> > > http://www.jroller.com/static-content/fate/general/index.html
> >
> > Suggestion: write the static version to the user's resource directory:
> > http://www.jroller.com/resources/fate/general/index.html
> >
> > The only problem with this is that it could interfere with the
> > maxDirectorySize admin value (eating up space valuable to the user, so
> > that they cannot upload a file).  Since currently that value only
> > measures against the "base" resource directory for the user
> > (/resources/fate) we can get aroudn this issue for the time being by
> > writing all static content to a subdirectory.  THis stops working
> > if/when we allow the user to create subdirectories.
> >
> > Lance
> >
>

Re: Sharing some stats

[Elias Torres <el...@gmail.com>]

Lance,

I'm not as concerned with the location on disk as I am with the actual
URL. The goal is to maintain the same URL pattern on the browser but
use instead a static version on disk. This is where RewriteRules come
in, but then we would depend on Apache. I think that if we can make
this optional, it would be great if we can pull this off.
Alternatively, we could explore OSCache disk-based caching so we don't
have to maintain an entire user's blog on memory. Also, I repeat, I
rather have Apache go straight to a static file, than the J2EE
container being hit just to read a file from disk.

I'll try to prototype this when I get a chance if you guys tell me
you'd be interested in incorporating it.

Elias

On 8/16/05, Lance Lavandowska <la...@gmail.com> wrote:
> On 8/16/05, Elias Torres <el...@gmail.com> wrote:
> > Then we could write RewriteRules in Apache that translated these for example:
> >
> > http://www.jroller.com/page/fate/Weblog?catname=General into
> > http://www.jroller.com/static-content/fate/general/index.html
> 
> Suggestion: write the static version to the user's resource directory:
> http://www.jroller.com/resources/fate/general/index.html
> 
> The only problem with this is that it could interfere with the
> maxDirectorySize admin value (eating up space valuable to the user, so
> that they cannot upload a file).  Since currently that value only
> measures against the "base" resource directory for the user
> (/resources/fate) we can get aroudn this issue for the time being by
> writing all static content to a subdirectory.  THis stops working
> if/when we allow the user to create subdirectories.
> 
> Lance
>

Re: Sharing some stats

[Elias Torres <el...@gmail.com>]

On 8/11/05, Matt Raible <mr...@gmail.com> wrote:
> On 8/11/05, Elias Torres <el...@gmail.com> wrote:
> > On 8/11/05, Allen Gilliland <Al...@sun.com> wrote:
> > > excellent, thanks for the info guys.
> > >
> > > yeah ... 9000 blogs is a lot and in truth i'm not even sure any system
> > > could really handle much more than that in a truly dynamic fashion.  rss
> > > feeds are pretty easy to cache because they aren't as complex, but the
> > > pages themselves are more complicated and there are a number of possible
> > > views of the page data which makes caching even harder.
> > >
> > > i am particularly intrigued that you both commented about the use of
> > > static html pages.  i think this would be a great option for Roller and
> > > it would be very cool if we could be pretty sneaky about it and actually
> > > use the same url structure that exists now, but just map to raw html
> > > files on the backend.  we should do some investigations on this, but i
> > > certainly like the idea of having the option to use static html pages.
> > >
> >
> > I'm not sure we would want J2EE container serving files though. Also,
> > just like wordpress we don't have to match the file structure, because
> > we can have a set of URLRewrites to map to whichever structure we
> > please on the filesystem. I mean MovableType, Blogger works this way,
> > why can't we do the same for Roller. We are right now in the process
> > of deciding what our solution will be to replace our existing server,
> > but those limits we see for Roller will hurt us for a company of the
> > size of IBM. Nothing can beat static content performance. What do you
> > guys think?
> 
> I agree that static content performance is good - but we'd likely have
> to generate the static content from the HTML content each time it
> changed.  If we did this, you could literally get 1000s of pages for
> one blog, since there are many different views if you change the date.
>  I'm fine with doing this, but it'd likely result in lots of disk
> space required.
> 
> Matt

I don't think we should worry about disk space, especially when
contrasted to the performance gains we would get from static content.
I would highly doubt the entire JRoller content being more than one
1GB of generated HTML content. That's nothing, if being served by
apache via static files, compared to the machinery that it takes to
run it dynamic. Roller is growing quite rapidly and it needs to
perform as more people are interested in it.

> 
> >
> > > Matt, if you are curious about your cache performance then you can turn
> > > up the debugging on the LRUCacheHandler2 class (i believe that's the
> > > right one).  This will flood your logs with lots of messages about cache
> > > hits and misses so make sure and watch your log files sizes, but it'll
> > > give you the info you need.  Another good idea is to turn on garbage
> > > collection debugging messages so you can see how much of your heap you
> > > are using.  With 9000 blogs my guess is that your caches are pretty
> > > overwhelmed, but I would also guess that if you check your the garbage
> > > collection after a Full GC that you probably have a little more room in
> > > your heap to increase the sizes.
> > >
> > > -- Allen
> > >
> > >
> > > Matthew P. Schmidt wrote:
> > >
> > > > I'll share.  We have about 9000 blogs with rapid growth.  Its running
> > > > on one dual xeon, on MySQL and Resin and uses about a 1.6G heap with 3
> > > > 3000 item caches (page, rss, last modified).  I'm not sure how much
> > > > they're actually being used.  Load is generally pretty manageable,
> > > > especially with the latest version of Roller.   As for hits, most of
> > > > it is RSS, with several million hits of that per month.  There are
> > > > also a million or more blog views per month and the server doesn't
> > > > generally have to restart that often.  Before merging our fork with
> > > > Roller 1.2, we were restarting every night due to a memory leak.  Our
> > > > biggest problem is probably the amount of referrer spam, even with a
> > > > healthy blacklist of dirty words.  I think static HTML for the pages
> > > > (which they basically are now if your cache is big enough) and a
> > > > better referrer filter would be two big helpers for us.
> > > > Matthew P. Schmidt
> > > > Vice President of Technology
> > > > Javalobby.org
> > > > Email: matt@javalobby.org
> > > > Phone: 919.678.0300
> > > >
> > > >
> > > >
> > > > Elias Torres wrote:
> > > >
> > > >> We have also around 1800 blogs and it's growing rapidly. Also, around
> > > >> 12K people make use of the system in total and this we know because we
> > > >> don't allow anonymous comments. You need to be authenticated for
> > > >> someone to comment/post.
> > > >>
> > > >> I wonder why you are not allowed to give out server info. Maybe I'll
> > > >> hold off on that too for now.
> > > >>
> > > >> I'm sure others have asked this before, but is there a plan of turning
> > > >> Roller blogs into static HTML? I'd be interested in hearing your
> > > >> thoughts on this. I'm sure this would alleviate many of the caching
> > > >> performance problems.
> > > >>
> > > >> Elias
> > > >>
> > > >> On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> > > >>
> > > >>
> > > >>> I am diverging from the deployments discussion for a second because
> > > >>> Elias comment sparked a question.  I'm interested in anything that
> > > >>> anyone wants to share about their roller installation ...
> > > >>>
> > > >>> how many blogs does it have?
> > > >>> what is your performance like?
> > > >>> what are your cache size settings?
> > > >>> how good is your caching efficiency on average?
> > > >>> any numbers on how much activity the site gets? hits/visits? load?
> > > >>> server info?  processors?  ram?  OS?  webserver?  database?
> > > >>> how is stability?  does the server require restarts often?
> > > >>>
> > > >>> anything that can be shared would be cool.  i'd like to keep some
> > > >>> info on who is running roller and in what kind of environments so
> > > >>> that we can hopefully make sure we are keeping roller well suited
> > > >>> for various situations.
> > > >>>
> > > >>> blogs.sun.com currently has almost 1600 blogs on it and our
> > > >>> stability is quite good.  i would give out server info, but i'm not
> > > >>> allowed to.  probably our biggest performance concern is page
> > > >>> caching, which has gotten worse and worse as more people start
> > > >>> blogging.  i think out cache size is 4000 right now and that is
> > > >>> plenty for the rss cache, but the page cache is still overwhelmed :/
> > > >>>
> > > >>> anyways ... how about others?
> > > >>>
> > > >>> -- Allen
> > > >>>
> > > >>>
> > > >>> On Tue, 2005-08-09 at 13:59, Elias Torres wrote:
> > > >>>
> > > >>>
> > > >>>> I'm also not an official part of the project, but I might be running
> > > >>>> the second or third largest Roller-based website ;-) and my opinion if
> > > >>>> it counts at all, is that if Dave/Allen can handle the heat in the
> > > >>>> kitchen, let them stay in the kitchen. I'm sure that's why they pay
> > > >>>> them the big bucks.
> > > >>>>
> > > >>>
> > > >>>
> > > >>
> > >
> >
>

Re: Sharing some stats

[Matt Raible <mr...@gmail.com>]

On 8/11/05, Elias Torres <el...@gmail.com> wrote:
> On 8/11/05, Allen Gilliland <Al...@sun.com> wrote:
> > excellent, thanks for the info guys.
> >
> > yeah ... 9000 blogs is a lot and in truth i'm not even sure any system
> > could really handle much more than that in a truly dynamic fashion.  rss
> > feeds are pretty easy to cache because they aren't as complex, but the
> > pages themselves are more complicated and there are a number of possible
> > views of the page data which makes caching even harder.
> >
> > i am particularly intrigued that you both commented about the use of
> > static html pages.  i think this would be a great option for Roller and
> > it would be very cool if we could be pretty sneaky about it and actually
> > use the same url structure that exists now, but just map to raw html
> > files on the backend.  we should do some investigations on this, but i
> > certainly like the idea of having the option to use static html pages.
> >
> 
> I'm not sure we would want J2EE container serving files though. Also,
> just like wordpress we don't have to match the file structure, because
> we can have a set of URLRewrites to map to whichever structure we
> please on the filesystem. I mean MovableType, Blogger works this way,
> why can't we do the same for Roller. We are right now in the process
> of deciding what our solution will be to replace our existing server,
> but those limits we see for Roller will hurt us for a company of the
> size of IBM. Nothing can beat static content performance. What do you
> guys think?

I agree that static content performance is good - but we'd likely have
to generate the static content from the HTML content each time it
changed.  If we did this, you could literally get 1000s of pages for
one blog, since there are many different views if you change the date.
 I'm fine with doing this, but it'd likely result in lots of disk
space required.

Matt

> 
> > Matt, if you are curious about your cache performance then you can turn
> > up the debugging on the LRUCacheHandler2 class (i believe that's the
> > right one).  This will flood your logs with lots of messages about cache
> > hits and misses so make sure and watch your log files sizes, but it'll
> > give you the info you need.  Another good idea is to turn on garbage
> > collection debugging messages so you can see how much of your heap you
> > are using.  With 9000 blogs my guess is that your caches are pretty
> > overwhelmed, but I would also guess that if you check your the garbage
> > collection after a Full GC that you probably have a little more room in
> > your heap to increase the sizes.
> >
> > -- Allen
> >
> >
> > Matthew P. Schmidt wrote:
> >
> > > I'll share.  We have about 9000 blogs with rapid growth.  Its running
> > > on one dual xeon, on MySQL and Resin and uses about a 1.6G heap with 3
> > > 3000 item caches (page, rss, last modified).  I'm not sure how much
> > > they're actually being used.  Load is generally pretty manageable,
> > > especially with the latest version of Roller.   As for hits, most of
> > > it is RSS, with several million hits of that per month.  There are
> > > also a million or more blog views per month and the server doesn't
> > > generally have to restart that often.  Before merging our fork with
> > > Roller 1.2, we were restarting every night due to a memory leak.  Our
> > > biggest problem is probably the amount of referrer spam, even with a
> > > healthy blacklist of dirty words.  I think static HTML for the pages
> > > (which they basically are now if your cache is big enough) and a
> > > better referrer filter would be two big helpers for us.
> > > Matthew P. Schmidt
> > > Vice President of Technology
> > > Javalobby.org
> > > Email: matt@javalobby.org
> > > Phone: 919.678.0300
> > >
> > >
> > >
> > > Elias Torres wrote:
> > >
> > >> We have also around 1800 blogs and it's growing rapidly. Also, around
> > >> 12K people make use of the system in total and this we know because we
> > >> don't allow anonymous comments. You need to be authenticated for
> > >> someone to comment/post.
> > >>
> > >> I wonder why you are not allowed to give out server info. Maybe I'll
> > >> hold off on that too for now.
> > >>
> > >> I'm sure others have asked this before, but is there a plan of turning
> > >> Roller blogs into static HTML? I'd be interested in hearing your
> > >> thoughts on this. I'm sure this would alleviate many of the caching
> > >> performance problems.
> > >>
> > >> Elias
> > >>
> > >> On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> > >>
> > >>
> > >>> I am diverging from the deployments discussion for a second because
> > >>> Elias comment sparked a question.  I'm interested in anything that
> > >>> anyone wants to share about their roller installation ...
> > >>>
> > >>> how many blogs does it have?
> > >>> what is your performance like?
> > >>> what are your cache size settings?
> > >>> how good is your caching efficiency on average?
> > >>> any numbers on how much activity the site gets? hits/visits? load?
> > >>> server info?  processors?  ram?  OS?  webserver?  database?
> > >>> how is stability?  does the server require restarts often?
> > >>>
> > >>> anything that can be shared would be cool.  i'd like to keep some
> > >>> info on who is running roller and in what kind of environments so
> > >>> that we can hopefully make sure we are keeping roller well suited
> > >>> for various situations.
> > >>>
> > >>> blogs.sun.com currently has almost 1600 blogs on it and our
> > >>> stability is quite good.  i would give out server info, but i'm not
> > >>> allowed to.  probably our biggest performance concern is page
> > >>> caching, which has gotten worse and worse as more people start
> > >>> blogging.  i think out cache size is 4000 right now and that is
> > >>> plenty for the rss cache, but the page cache is still overwhelmed :/
> > >>>
> > >>> anyways ... how about others?
> > >>>
> > >>> -- Allen
> > >>>
> > >>>
> > >>> On Tue, 2005-08-09 at 13:59, Elias Torres wrote:
> > >>>
> > >>>
> > >>>> I'm also not an official part of the project, but I might be running
> > >>>> the second or third largest Roller-based website ;-) and my opinion if
> > >>>> it counts at all, is that if Dave/Allen can handle the heat in the
> > >>>> kitchen, let them stay in the kitchen. I'm sure that's why they pay
> > >>>> them the big bucks.
> > >>>>
> > >>>
> > >>>
> > >>
> >
>

Re: Sharing some stats

[Elias Torres <el...@gmail.com>]

Trygve,

I'm not sure if you are familiar with the way that Roller is
implemented today. Just in case, it already uses a memory/disk caching
system written by Open Symphony called OSCache. I'm not sure what the
differences are between it and what you are suggesting. But I do know
that using a memory caching system is already not the most optimal
solution as indicated by the fellow who runs JRoller.com.

Elias

On 8/18/05, Trygve Lie <tr...@hotmail.com> wrote:
> Hi
> 
> I do not think static content is the way to go. By my experience it will
> introduce a lot of new issues.
> At least if the posibillities of static content is introduced it must be
> able to turn it on or off on different levels (not just on or off at a whole
> site).
> 
> But; I would much rather see a implementation with Memcached:
> http://www.danga.com/memcached/
> 
> I work in a company which maintains and develops the largest media network
> in Norway and we have a quite large scale CMS running all our media
> services. A time a go we did have the same problem with caching as described
> here. Turning on static caching was not an option for us.
> For us Memcached was the definitive solution to a lot of our performance
> problems.
> Now we can just put in a blade server with a lot of memory if we need more
> cache...
> 
> In our network there has been done an implementation of Memcached for
> Hibernate. This would probably work for Roller also. I can see if I can get
> this code awailable for the public....
> 
> Trygve
> 
> 
> >From: Lance Lavandowska <la...@gmail.com>
> >Reply-To: roller-dev@incubator.apache.org
> >To: roller-dev@incubator.apache.org, elias@torrez.us
> >Subject: Re: Sharing some stats
> >Date: Tue, 16 Aug 2005 12:02:33 -0500
> >
> >On 8/16/05, Elias Torres <el...@gmail.com> wrote:
> > > Then we could write RewriteRules in Apache that translated these for
> >example:
> > >
> > > http://www.jroller.com/page/fate/Weblog?catname=General into
> > > http://www.jroller.com/static-content/fate/general/index.html
> >
> >Suggestion: write the static version to the user's resource directory:
> >http://www.jroller.com/resources/fate/general/index.html
> >
> >The only problem with this is that it could interfere with the
> >maxDirectorySize admin value (eating up space valuable to the user, so
> >that they cannot upload a file).  Since currently that value only
> >measures against the "base" resource directory for the user
> >(/resources/fate) we can get aroudn this issue for the time being by
> >writing all static content to a subdirectory.  THis stops working
> >if/when we allow the user to create subdirectories.
> >
> >Lance
> 
> _________________________________________________________________
> MSN Search http://search.msn.no/ Raskere. Rett på sak. Mer presist.
> 
>

Re: Sharing some stats

[Trygve Lie <tr...@hotmail.com>]

Hi

Sorry for the late reply.

Great to see you like it and that you are woundering about implementing it 
:)

I'm very aware of Rollers use of OSCache (which I'm also familiar with) but 
memcached works in another way.
Let me explain to those of you who have not looked at it; First of all it's 
distributed memory and second it's not an JAVA applications. In other words 
you can start memcached on as many servers (where you have free space) as 
you want and it will act as one huge pile of memory for the application.
First of all you end up with the posibillity to have unlimited amount of 
memory and this is a lightning fast way to cache tings, but another 
advantage is that the cached objects are moved out of the JAVA VM. JAVA just 
connects to it and this is a huge bennefit if the JAVA EE server dies (not 
the entire server).
If the JAVA EE server dies all the cached objects will still be in memcached 
and when the JAVA EE server are up running again it will just have the 
cached objects there again. It does not need to pul every thing from the DB 
again, it's just there :)
Even if the whole server dies or one of the servers alocating memory to 
memcached only parts of the cached objects will be lost because it's 
distributed..

I find this much more interesting in a large scale installation than a 
static content function, but static content are nice for smaller sites which 
does not have the access to hardware such as larger installations might 
have.

Anyway; very nice to see you do find this interesting :)

Just to change topic; I'll be starting to look at a integration of the 
FCKEditor (http://www.fckeditor.net/) into Roller. I think it should be an 
easy task to do and a nice start for me to be able to contribute. Is there 
anybody else looking at this?
This does belong in a new tread...

PS: My last post ended up at the root in the apache incubator archive. If 
this one does also, what am I doing wrong? I'm just replying to the post I 
want to reply to and the reply adress is roller-dev@incubator.apache.org

Kind regards
Trygve



>From: Allen Gilliland <Al...@Sun.COM>
>Reply-To: roller-dev@incubator.apache.org
>To: roller-dev <ro...@incubator.apache.org>
>CC: elias@torrez.us
>Subject: Re: Sharing some stats
>Date: Wed, 24 Aug 2005 14:46:50 -0700
>
>I spent a little time playing with memcached today and I must say that I 
>rather like it.  The setup was pretty easy and depending on how we would 
>would want to use it I think this could be a nice little feature.
>
>Rather than bother with trying to integrate this into the backend via 
>hibernate I instead decided to just apply it to the page level cache.  
>There are a number of things in the presentation layer caching setup that I 
>think can be cleaned up to make this easier, but so far it hasn't been too 
>bad.
>
>It seems to me like we probably don't need to use memcached for more than 
>just the presentation level caching, and means we should be able to keep 
>our implementation pretty simple.
>
>thanks for making this suggestion Trygve.
>
>-- Allen
>
>
>On Thu, 2005-08-18 at 00:52, Trygve Lie wrote:
> > Hi
> >
> > I do not think static content is the way to go. By my experience it will
> > introduce a lot of new issues.
> > At least if the posibillities of static content is introduced it must be
> > able to turn it on or off on different levels (not just on or off at a 
>whole
> > site).
> >
> > But; I would much rather see a implementation with Memcached:
> > http://www.danga.com/memcached/
> >
> > I work in a company which maintains and develops the largest media 
>network
> > in Norway and we have a quite large scale CMS running all our media
> > services. A time a go we did have the same problem with caching as 
>described
> > here. Turning on static caching was not an option for us.
> > For us Memcached was the definitive solution to a lot of our performance
> > problems.
> > Now we can just put in a blade server with a lot of memory if we need 
>more
> > cache...
> >
> > In our network there has been done an implementation of Memcached for
> > Hibernate. This would probably work for Roller also. I can see if I can 
>get
> > this code awailable for the public....
> >
> > Trygve
> >
> >
> > >From: Lance Lavandowska <la...@gmail.com>
> > >Reply-To: roller-dev@incubator.apache.org
> > >To: roller-dev@incubator.apache.org, elias@torrez.us
> > >Subject: Re: Sharing some stats
> > >Date: Tue, 16 Aug 2005 12:02:33 -0500
> > >
> > >On 8/16/05, Elias Torres <el...@gmail.com> wrote:
> > > > Then we could write RewriteRules in Apache that translated these for
> > >example:
> > > >
> > > > http://www.jroller.com/page/fate/Weblog?catname=General into
> > > > http://www.jroller.com/static-content/fate/general/index.html
> > >
> > >Suggestion: write the static version to the user's resource directory:
> > >http://www.jroller.com/resources/fate/general/index.html
> > >
> > >The only problem with this is that it could interfere with the
> > >maxDirectorySize admin value (eating up space valuable to the user, so
> > >that they cannot upload a file).  Since currently that value only
> > >measures against the "base" resource directory for the user
> > >(/resources/fate) we can get aroudn this issue for the time being by
> > >writing all static content to a subdirectory.  THis stops working
> > >if/when we allow the user to create subdirectories.
> > >
> > >Lance
> >
> > _________________________________________________________________
> > MSN Search http://search.msn.no/ Raskere. Rett på sak. Mer presist.
> >
>

_________________________________________________________________
MSN Messenger http://www.msn.no/messenger Den enkleste og raskeste måten å 
holde kontakten på.

Re: Sharing some stats

[Allen Gilliland <Al...@Sun.COM>]

I spent a little time playing with memcached today and I must say that I rather like it.  The setup was pretty easy and depending on how we would would want to use it I think this could be a nice little feature.

Rather than bother with trying to integrate this into the backend via hibernate I instead decided to just apply it to the page level cache.  There are a number of things in the presentation layer caching setup that I think can be cleaned up to make this easier, but so far it hasn't been too bad.

It seems to me like we probably don't need to use memcached for more than just the presentation level caching, and means we should be able to keep our implementation pretty simple.

thanks for making this suggestion Trygve.

-- Allen


On Thu, 2005-08-18 at 00:52, Trygve Lie wrote:
> Hi
> 
> I do not think static content is the way to go. By my experience it will 
> introduce a lot of new issues.
> At least if the posibillities of static content is introduced it must be 
> able to turn it on or off on different levels (not just on or off at a whole 
> site).
> 
> But; I would much rather see a implementation with Memcached: 
> http://www.danga.com/memcached/
> 
> I work in a company which maintains and develops the largest media network 
> in Norway and we have a quite large scale CMS running all our media 
> services. A time a go we did have the same problem with caching as described 
> here. Turning on static caching was not an option for us.
> For us Memcached was the definitive solution to a lot of our performance 
> problems.
> Now we can just put in a blade server with a lot of memory if we need more 
> cache...
> 
> In our network there has been done an implementation of Memcached for 
> Hibernate. This would probably work for Roller also. I can see if I can get 
> this code awailable for the public....
> 
> Trygve
> 
> 
> >From: Lance Lavandowska <la...@gmail.com>
> >Reply-To: roller-dev@incubator.apache.org
> >To: roller-dev@incubator.apache.org, elias@torrez.us
> >Subject: Re: Sharing some stats
> >Date: Tue, 16 Aug 2005 12:02:33 -0500
> >
> >On 8/16/05, Elias Torres <el...@gmail.com> wrote:
> > > Then we could write RewriteRules in Apache that translated these for 
> >example:
> > >
> > > http://www.jroller.com/page/fate/Weblog?catname=General into
> > > http://www.jroller.com/static-content/fate/general/index.html
> >
> >Suggestion: write the static version to the user's resource directory:
> >http://www.jroller.com/resources/fate/general/index.html
> >
> >The only problem with this is that it could interfere with the
> >maxDirectorySize admin value (eating up space valuable to the user, so
> >that they cannot upload a file).  Since currently that value only
> >measures against the "base" resource directory for the user
> >(/resources/fate) we can get aroudn this issue for the time being by
> >writing all static content to a subdirectory.  THis stops working
> >if/when we allow the user to create subdirectories.
> >
> >Lance
> 
> _________________________________________________________________
> MSN Search http://search.msn.no/ Raskere. Rett på sak. Mer presist.
> 

Re: Sharing some stats

[Trygve Lie <tr...@hotmail.com>]

Hi

I do not think static content is the way to go. By my experience it will 
introduce a lot of new issues.
At least if the posibillities of static content is introduced it must be 
able to turn it on or off on different levels (not just on or off at a whole 
site).

But; I would much rather see a implementation with Memcached: 
http://www.danga.com/memcached/

I work in a company which maintains and develops the largest media network 
in Norway and we have a quite large scale CMS running all our media 
services. A time a go we did have the same problem with caching as described 
here. Turning on static caching was not an option for us.
For us Memcached was the definitive solution to a lot of our performance 
problems.
Now we can just put in a blade server with a lot of memory if we need more 
cache...

In our network there has been done an implementation of Memcached for 
Hibernate. This would probably work for Roller also. I can see if I can get 
this code awailable for the public....

Trygve


>From: Lance Lavandowska <la...@gmail.com>
>Reply-To: roller-dev@incubator.apache.org
>To: roller-dev@incubator.apache.org, elias@torrez.us
>Subject: Re: Sharing some stats
>Date: Tue, 16 Aug 2005 12:02:33 -0500
>
>On 8/16/05, Elias Torres <el...@gmail.com> wrote:
> > Then we could write RewriteRules in Apache that translated these for 
>example:
> >
> > http://www.jroller.com/page/fate/Weblog?catname=General into
> > http://www.jroller.com/static-content/fate/general/index.html
>
>Suggestion: write the static version to the user's resource directory:
>http://www.jroller.com/resources/fate/general/index.html
>
>The only problem with this is that it could interfere with the
>maxDirectorySize admin value (eating up space valuable to the user, so
>that they cannot upload a file).  Since currently that value only
>measures against the "base" resource directory for the user
>(/resources/fate) we can get aroudn this issue for the time being by
>writing all static content to a subdirectory.  THis stops working
>if/when we allow the user to create subdirectories.
>
>Lance

_________________________________________________________________
MSN Search http://search.msn.no/ Raskere. Rett på sak. Mer presist.

Re: Sharing some stats

[Lance Lavandowska <la...@gmail.com>]

On 8/16/05, Elias Torres <el...@gmail.com> wrote:
> Then we could write RewriteRules in Apache that translated these for example:
> 
> http://www.jroller.com/page/fate/Weblog?catname=General into
> http://www.jroller.com/static-content/fate/general/index.html

Suggestion: write the static version to the user's resource directory:
http://www.jroller.com/resources/fate/general/index.html

The only problem with this is that it could interfere with the
maxDirectorySize admin value (eating up space valuable to the user, so
that they cannot upload a file).  Since currently that value only
measures against the "base" resource directory for the user
(/resources/fate) we can get aroudn this issue for the time being by
writing all static content to a subdirectory.  THis stops working
if/when we allow the user to create subdirectories.

Lance

Re: Sharing some stats

[Elias Torres <el...@gmail.com>]

The URL rewriting that I'm talking about is used more with WordPress.
Wordpress has an index.php that takes parameters for everything like
yeah, monthnum, day, feed, etc. Now what they do is to provide a
sample .htaccess file that allows the user to have nice URLs like
"/archives/2005/06/05/123" through a rewrite rule like the following:

RewriteRule ^archives/([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/([0-9]+)?$
/index.php?year=$1&monthnum=$2&day=$3&p=$4 [QSA,L]

This is practically what Roller does in that function to parse the
path info from the RollerServlet (I'm not 100% where this is, but I
know of such function). Now, my intention is not to make Apache a
requirement, but an option. Roller already has a nice URL pattern
already so this would not be too hard to map to static content. From a
quick glance at it, it would be a matter of creating a "theme" that
supported static publication. There are four types of pages, the main
weblog page, the category page, the day page and the entry page.
Everytime a person makes a post/comment, we can re-generate the pages
affected by changes and put them into another directory structure.
Then, using URL Rewrites, we can make them look like the normal Roller
J2EE deployment.

For example,

If we had:

/roller
+ /username
 + index.html <- This is the normal homepage
 + /archives/20050605.html <- A day's worth of entries
 + /entries/page_slug.html <- An entry
 + /categoryname/index.html <- The generated page with recent entries
in that category
 + /rss/index.atom <- Atom feed
 + /rss/categoryname/index.atom <- The Java Atom feed, etc.

Then we could write RewriteRules in Apache that translated these for example:

http://www.jroller.com/page/fate/Weblog?catname=General into
http://www.jroller.com/static-content/fate/general/index.html

http://www.jroller.com/page/fate?entry=another_anniversary into
http://www.jroller.com/static-content/fate/entries/another_anniversary.html

and so on.

Of course, all the servlet endpoints would stay the same, like posting
comments, trackback and so forth. Most of the work would have to be on
the static content generation and checking which Velocity Macros
actually need HTTPRequest information. Most of them should work,
because pages are getting cached already anyways, so it's not like
those macros are dependent on being called everytime and besides the
URLs would look the same to them. All we would need to do is fake the
HTTPRequest when running the Velocity templates.

Let me know what do you think,

Elias

On 8/15/05, Allen Gilliland <Al...@sun.com> wrote:
> On Thu, 2005-08-11 at 14:13, Elias Torres wrote:
> > I'm not sure we would want J2EE container serving files though. Also,
> > just like wordpress we don't have to match the file structure, because
> > we can have a set of URLRewrites to map to whichever structure we
> > please on the filesystem. I mean MovableType, Blogger works this way,
> > why can't we do the same for Roller. We are right now in the process
> > of deciding what our solution will be to replace our existing server,
> > but those limits we see for Roller will hurt us for a company of the
> > size of IBM. Nothing can beat static content performance. What do you
> > guys think?
> 
> I'd like to hear more about how you see the static content being served up.  I've used MT quite a bit, but never with any url rewriting.
> 
> Personally, I still think that by default we would want to make the whole system run in a pure j2ee container.  Remember that while some of us run very large Roller installations, most people will likely have very moderate sized sites.  In those cases a pure j2ee container should be fine.
> 
> I would also not be a fan of requiring another piece of software just to make a given feature work.  i.e. to *require* Apache to use the static content would be lame in my opinion.  I think that static content should be disabled by default, yet easily enabled via the Roller config.  Once it's enabled the site owner should have a few options on how to use it.  namely, run it in their current j2ee container with some servlets/filters doing url mapping.  or if they want, they can disable the built in url mapping and implement their own way of doing the url rewriting via apache, or anything else.
> 
> -- Allen
> 
> 
> >
> > > Matt, if you are curious about your cache performance then you can turn
> > > up the debugging on the LRUCacheHandler2 class (i believe that's the
> > > right one).  This will flood your logs with lots of messages about cache
> > > hits and misses so make sure and watch your log files sizes, but it'll
> > > give you the info you need.  Another good idea is to turn on garbage
> > > collection debugging messages so you can see how much of your heap you
> > > are using.  With 9000 blogs my guess is that your caches are pretty
> > > overwhelmed, but I would also guess that if you check your the garbage
> > > collection after a Full GC that you probably have a little more room in
> > > your heap to increase the sizes.
> > >
> > > -- Allen
> > >
> > >
> > > Matthew P. Schmidt wrote:
> > >
> > > > I'll share.  We have about 9000 blogs with rapid growth.  Its running
> > > > on one dual xeon, on MySQL and Resin and uses about a 1.6G heap with 3
> > > > 3000 item caches (page, rss, last modified).  I'm not sure how much
> > > > they're actually being used.  Load is generally pretty manageable,
> > > > especially with the latest version of Roller.   As for hits, most of
> > > > it is RSS, with several million hits of that per month.  There are
> > > > also a million or more blog views per month and the server doesn't
> > > > generally have to restart that often.  Before merging our fork with
> > > > Roller 1.2, we were restarting every night due to a memory leak.  Our
> > > > biggest problem is probably the amount of referrer spam, even with a
> > > > healthy blacklist of dirty words.  I think static HTML for the pages
> > > > (which they basically are now if your cache is big enough) and a
> > > > better referrer filter would be two big helpers for us.
> > > > Matthew P. Schmidt
> > > > Vice President of Technology
> > > > Javalobby.org
> > > > Email: matt@javalobby.org
> > > > Phone: 919.678.0300
> > > >
> > > >
> > > >
> > > > Elias Torres wrote:
> > > >
> > > >> We have also around 1800 blogs and it's growing rapidly. Also, around
> > > >> 12K people make use of the system in total and this we know because we
> > > >> don't allow anonymous comments. You need to be authenticated for
> > > >> someone to comment/post.
> > > >>
> > > >> I wonder why you are not allowed to give out server info. Maybe I'll
> > > >> hold off on that too for now.
> > > >>
> > > >> I'm sure others have asked this before, but is there a plan of turning
> > > >> Roller blogs into static HTML? I'd be interested in hearing your
> > > >> thoughts on this. I'm sure this would alleviate many of the caching
> > > >> performance problems.
> > > >>
> > > >> Elias
> > > >>
> > > >> On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> > > >>
> > > >>
> > > >>> I am diverging from the deployments discussion for a second because
> > > >>> Elias comment sparked a question.  I'm interested in anything that
> > > >>> anyone wants to share about their roller installation ...
> > > >>>
> > > >>> how many blogs does it have?
> > > >>> what is your performance like?
> > > >>> what are your cache size settings?
> > > >>> how good is your caching efficiency on average?
> > > >>> any numbers on how much activity the site gets? hits/visits? load?
> > > >>> server info?  processors?  ram?  OS?  webserver?  database?
> > > >>> how is stability?  does the server require restarts often?
> > > >>>
> > > >>> anything that can be shared would be cool.  i'd like to keep some
> > > >>> info on who is running roller and in what kind of environments so
> > > >>> that we can hopefully make sure we are keeping roller well suited
> > > >>> for various situations.
> > > >>>
> > > >>> blogs.sun.com currently has almost 1600 blogs on it and our
> > > >>> stability is quite good.  i would give out server info, but i'm not
> > > >>> allowed to.  probably our biggest performance concern is page
> > > >>> caching, which has gotten worse and worse as more people start
> > > >>> blogging.  i think out cache size is 4000 right now and that is
> > > >>> plenty for the rss cache, but the page cache is still overwhelmed :/
> > > >>>
> > > >>> anyways ... how about others?
> > > >>>
> > > >>> -- Allen
> > > >>>
> > > >>>
> > > >>> On Tue, 2005-08-09 at 13:59, Elias Torres wrote:
> > > >>>
> > > >>>
> > > >>>> I'm also not an official part of the project, but I might be running
> > > >>>> the second or third largest Roller-based website ;-) and my opinion if
> > > >>>> it counts at all, is that if Dave/Allen can handle the heat in the
> > > >>>> kitchen, let them stay in the kitchen. I'm sure that's why they pay
> > > >>>> them the big bucks.
> > > >>>>
> > > >>>
> > > >>>
> > > >>
> > >
> 
>

Re: Sharing some stats

[Allen Gilliland <Al...@Sun.COM>]

On Thu, 2005-08-11 at 14:13, Elias Torres wrote:
> I'm not sure we would want J2EE container serving files though. Also,
> just like wordpress we don't have to match the file structure, because
> we can have a set of URLRewrites to map to whichever structure we
> please on the filesystem. I mean MovableType, Blogger works this way,
> why can't we do the same for Roller. We are right now in the process
> of deciding what our solution will be to replace our existing server,
> but those limits we see for Roller will hurt us for a company of the
> size of IBM. Nothing can beat static content performance. What do you
> guys think?

I'd like to hear more about how you see the static content being served up.  I've used MT quite a bit, but never with any url rewriting.

Personally, I still think that by default we would want to make the whole system run in a pure j2ee container.  Remember that while some of us run very large Roller installations, most people will likely have very moderate sized sites.  In those cases a pure j2ee container should be fine.

I would also not be a fan of requiring another piece of software just to make a given feature work.  i.e. to *require* Apache to use the static content would be lame in my opinion.  I think that static content should be disabled by default, yet easily enabled via the Roller config.  Once it's enabled the site owner should have a few options on how to use it.  namely, run it in their current j2ee container with some servlets/filters doing url mapping.  or if they want, they can disable the built in url mapping and implement their own way of doing the url rewriting via apache, or anything else.

-- Allen


> 
> > Matt, if you are curious about your cache performance then you can turn
> > up the debugging on the LRUCacheHandler2 class (i believe that's the
> > right one).  This will flood your logs with lots of messages about cache
> > hits and misses so make sure and watch your log files sizes, but it'll
> > give you the info you need.  Another good idea is to turn on garbage
> > collection debugging messages so you can see how much of your heap you
> > are using.  With 9000 blogs my guess is that your caches are pretty
> > overwhelmed, but I would also guess that if you check your the garbage
> > collection after a Full GC that you probably have a little more room in
> > your heap to increase the sizes.
> > 
> > -- Allen
> > 
> > 
> > Matthew P. Schmidt wrote:
> > 
> > > I'll share.  We have about 9000 blogs with rapid growth.  Its running
> > > on one dual xeon, on MySQL and Resin and uses about a 1.6G heap with 3
> > > 3000 item caches (page, rss, last modified).  I'm not sure how much
> > > they're actually being used.  Load is generally pretty manageable,
> > > especially with the latest version of Roller.   As for hits, most of
> > > it is RSS, with several million hits of that per month.  There are
> > > also a million or more blog views per month and the server doesn't
> > > generally have to restart that often.  Before merging our fork with
> > > Roller 1.2, we were restarting every night due to a memory leak.  Our
> > > biggest problem is probably the amount of referrer spam, even with a
> > > healthy blacklist of dirty words.  I think static HTML for the pages
> > > (which they basically are now if your cache is big enough) and a
> > > better referrer filter would be two big helpers for us.
> > > Matthew P. Schmidt
> > > Vice President of Technology
> > > Javalobby.org
> > > Email: matt@javalobby.org
> > > Phone: 919.678.0300
> > >
> > >
> > >
> > > Elias Torres wrote:
> > >
> > >> We have also around 1800 blogs and it's growing rapidly. Also, around
> > >> 12K people make use of the system in total and this we know because we
> > >> don't allow anonymous comments. You need to be authenticated for
> > >> someone to comment/post.
> > >>
> > >> I wonder why you are not allowed to give out server info. Maybe I'll
> > >> hold off on that too for now.
> > >>
> > >> I'm sure others have asked this before, but is there a plan of turning
> > >> Roller blogs into static HTML? I'd be interested in hearing your
> > >> thoughts on this. I'm sure this would alleviate many of the caching
> > >> performance problems.
> > >>
> > >> Elias
> > >>
> > >> On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> > >>
> > >>
> > >>> I am diverging from the deployments discussion for a second because
> > >>> Elias comment sparked a question.  I'm interested in anything that
> > >>> anyone wants to share about their roller installation ...
> > >>>
> > >>> how many blogs does it have?
> > >>> what is your performance like?
> > >>> what are your cache size settings?
> > >>> how good is your caching efficiency on average?
> > >>> any numbers on how much activity the site gets? hits/visits? load?
> > >>> server info?  processors?  ram?  OS?  webserver?  database?
> > >>> how is stability?  does the server require restarts often?
> > >>>
> > >>> anything that can be shared would be cool.  i'd like to keep some
> > >>> info on who is running roller and in what kind of environments so
> > >>> that we can hopefully make sure we are keeping roller well suited
> > >>> for various situations.
> > >>>
> > >>> blogs.sun.com currently has almost 1600 blogs on it and our
> > >>> stability is quite good.  i would give out server info, but i'm not
> > >>> allowed to.  probably our biggest performance concern is page
> > >>> caching, which has gotten worse and worse as more people start
> > >>> blogging.  i think out cache size is 4000 right now and that is
> > >>> plenty for the rss cache, but the page cache is still overwhelmed :/
> > >>>
> > >>> anyways ... how about others?
> > >>>
> > >>> -- Allen
> > >>>
> > >>>
> > >>> On Tue, 2005-08-09 at 13:59, Elias Torres wrote:
> > >>>
> > >>>
> > >>>> I'm also not an official part of the project, but I might be running
> > >>>> the second or third largest Roller-based website ;-) and my opinion if
> > >>>> it counts at all, is that if Dave/Allen can handle the heat in the
> > >>>> kitchen, let them stay in the kitchen. I'm sure that's why they pay
> > >>>> them the big bucks.
> > >>>>
> > >>>
> > >>>
> > >>
> >

Re: Sharing some stats

[Elias Torres <el...@gmail.com>]

On 8/11/05, Allen Gilliland <Al...@sun.com> wrote:
> excellent, thanks for the info guys.
> 
> yeah ... 9000 blogs is a lot and in truth i'm not even sure any system
> could really handle much more than that in a truly dynamic fashion.  rss
> feeds are pretty easy to cache because they aren't as complex, but the
> pages themselves are more complicated and there are a number of possible
> views of the page data which makes caching even harder.
> 
> i am particularly intrigued that you both commented about the use of
> static html pages.  i think this would be a great option for Roller and
> it would be very cool if we could be pretty sneaky about it and actually
> use the same url structure that exists now, but just map to raw html
> files on the backend.  we should do some investigations on this, but i
> certainly like the idea of having the option to use static html pages.
> 

I'm not sure we would want J2EE container serving files though. Also,
just like wordpress we don't have to match the file structure, because
we can have a set of URLRewrites to map to whichever structure we
please on the filesystem. I mean MovableType, Blogger works this way,
why can't we do the same for Roller. We are right now in the process
of deciding what our solution will be to replace our existing server,
but those limits we see for Roller will hurt us for a company of the
size of IBM. Nothing can beat static content performance. What do you
guys think?

> Matt, if you are curious about your cache performance then you can turn
> up the debugging on the LRUCacheHandler2 class (i believe that's the
> right one).  This will flood your logs with lots of messages about cache
> hits and misses so make sure and watch your log files sizes, but it'll
> give you the info you need.  Another good idea is to turn on garbage
> collection debugging messages so you can see how much of your heap you
> are using.  With 9000 blogs my guess is that your caches are pretty
> overwhelmed, but I would also guess that if you check your the garbage
> collection after a Full GC that you probably have a little more room in
> your heap to increase the sizes.
> 
> -- Allen
> 
> 
> Matthew P. Schmidt wrote:
> 
> > I'll share.  We have about 9000 blogs with rapid growth.  Its running
> > on one dual xeon, on MySQL and Resin and uses about a 1.6G heap with 3
> > 3000 item caches (page, rss, last modified).  I'm not sure how much
> > they're actually being used.  Load is generally pretty manageable,
> > especially with the latest version of Roller.   As for hits, most of
> > it is RSS, with several million hits of that per month.  There are
> > also a million or more blog views per month and the server doesn't
> > generally have to restart that often.  Before merging our fork with
> > Roller 1.2, we were restarting every night due to a memory leak.  Our
> > biggest problem is probably the amount of referrer spam, even with a
> > healthy blacklist of dirty words.  I think static HTML for the pages
> > (which they basically are now if your cache is big enough) and a
> > better referrer filter would be two big helpers for us.
> > Matthew P. Schmidt
> > Vice President of Technology
> > Javalobby.org
> > Email: matt@javalobby.org
> > Phone: 919.678.0300
> >
> >
> >
> > Elias Torres wrote:
> >
> >> We have also around 1800 blogs and it's growing rapidly. Also, around
> >> 12K people make use of the system in total and this we know because we
> >> don't allow anonymous comments. You need to be authenticated for
> >> someone to comment/post.
> >>
> >> I wonder why you are not allowed to give out server info. Maybe I'll
> >> hold off on that too for now.
> >>
> >> I'm sure others have asked this before, but is there a plan of turning
> >> Roller blogs into static HTML? I'd be interested in hearing your
> >> thoughts on this. I'm sure this would alleviate many of the caching
> >> performance problems.
> >>
> >> Elias
> >>
> >> On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> >>
> >>
> >>> I am diverging from the deployments discussion for a second because
> >>> Elias comment sparked a question.  I'm interested in anything that
> >>> anyone wants to share about their roller installation ...
> >>>
> >>> how many blogs does it have?
> >>> what is your performance like?
> >>> what are your cache size settings?
> >>> how good is your caching efficiency on average?
> >>> any numbers on how much activity the site gets? hits/visits? load?
> >>> server info?  processors?  ram?  OS?  webserver?  database?
> >>> how is stability?  does the server require restarts often?
> >>>
> >>> anything that can be shared would be cool.  i'd like to keep some
> >>> info on who is running roller and in what kind of environments so
> >>> that we can hopefully make sure we are keeping roller well suited
> >>> for various situations.
> >>>
> >>> blogs.sun.com currently has almost 1600 blogs on it and our
> >>> stability is quite good.  i would give out server info, but i'm not
> >>> allowed to.  probably our biggest performance concern is page
> >>> caching, which has gotten worse and worse as more people start
> >>> blogging.  i think out cache size is 4000 right now and that is
> >>> plenty for the rss cache, but the page cache is still overwhelmed :/
> >>>
> >>> anyways ... how about others?
> >>>
> >>> -- Allen
> >>>
> >>>
> >>> On Tue, 2005-08-09 at 13:59, Elias Torres wrote:
> >>>
> >>>
> >>>> I'm also not an official part of the project, but I might be running
> >>>> the second or third largest Roller-based website ;-) and my opinion if
> >>>> it counts at all, is that if Dave/Allen can handle the heat in the
> >>>> kitchen, let them stay in the kitchen. I'm sure that's why they pay
> >>>> them the big bucks.
> >>>>
> >>>
> >>>
> >>
>

Re: Sharing some stats

[Allen Gilliland <Al...@Sun.COM>]

excellent, thanks for the info guys.

yeah ... 9000 blogs is a lot and in truth i'm not even sure any system 
could really handle much more than that in a truly dynamic fashion.  rss 
feeds are pretty easy to cache because they aren't as complex, but the 
pages themselves are more complicated and there are a number of possible 
views of the page data which makes caching even harder.

i am particularly intrigued that you both commented about the use of 
static html pages.  i think this would be a great option for Roller and 
it would be very cool if we could be pretty sneaky about it and actually 
use the same url structure that exists now, but just map to raw html 
files on the backend.  we should do some investigations on this, but i 
certainly like the idea of having the option to use static html pages.

Matt, if you are curious about your cache performance then you can turn 
up the debugging on the LRUCacheHandler2 class (i believe that's the 
right one).  This will flood your logs with lots of messages about cache 
hits and misses so make sure and watch your log files sizes, but it'll 
give you the info you need.  Another good idea is to turn on garbage 
collection debugging messages so you can see how much of your heap you 
are using.  With 9000 blogs my guess is that your caches are pretty 
overwhelmed, but I would also guess that if you check your the garbage 
collection after a Full GC that you probably have a little more room in 
your heap to increase the sizes.

-- Allen


Matthew P. Schmidt wrote:

> I'll share.  We have about 9000 blogs with rapid growth.  Its running 
> on one dual xeon, on MySQL and Resin and uses about a 1.6G heap with 3 
> 3000 item caches (page, rss, last modified).  I'm not sure how much 
> they're actually being used.  Load is generally pretty manageable, 
> especially with the latest version of Roller.   As for hits, most of 
> it is RSS, with several million hits of that per month.  There are 
> also a million or more blog views per month and the server doesn't 
> generally have to restart that often.  Before merging our fork with 
> Roller 1.2, we were restarting every night due to a memory leak.  Our 
> biggest problem is probably the amount of referrer spam, even with a 
> healthy blacklist of dirty words.  I think static HTML for the pages 
> (which they basically are now if your cache is big enough) and a 
> better referrer filter would be two big helpers for us. 
> Matthew P. Schmidt
> Vice President of Technology
> Javalobby.org
> Email: matt@javalobby.org
> Phone: 919.678.0300
>
>
>
> Elias Torres wrote:
>
>> We have also around 1800 blogs and it's growing rapidly. Also, around
>> 12K people make use of the system in total and this we know because we
>> don't allow anonymous comments. You need to be authenticated for
>> someone to comment/post.
>>
>> I wonder why you are not allowed to give out server info. Maybe I'll
>> hold off on that too for now.
>>
>> I'm sure others have asked this before, but is there a plan of turning
>> Roller blogs into static HTML? I'd be interested in hearing your
>> thoughts on this. I'm sure this would alleviate many of the caching
>> performance problems.
>>
>> Elias
>>
>> On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
>>  
>>
>>> I am diverging from the deployments discussion for a second because 
>>> Elias comment sparked a question.  I'm interested in anything that 
>>> anyone wants to share about their roller installation ...
>>>
>>> how many blogs does it have?
>>> what is your performance like?
>>> what are your cache size settings?
>>> how good is your caching efficiency on average?
>>> any numbers on how much activity the site gets? hits/visits? load?
>>> server info?  processors?  ram?  OS?  webserver?  database?
>>> how is stability?  does the server require restarts often?
>>>
>>> anything that can be shared would be cool.  i'd like to keep some 
>>> info on who is running roller and in what kind of environments so 
>>> that we can hopefully make sure we are keeping roller well suited 
>>> for various situations.
>>>
>>> blogs.sun.com currently has almost 1600 blogs on it and our 
>>> stability is quite good.  i would give out server info, but i'm not 
>>> allowed to.  probably our biggest performance concern is page 
>>> caching, which has gotten worse and worse as more people start 
>>> blogging.  i think out cache size is 4000 right now and that is 
>>> plenty for the rss cache, but the page cache is still overwhelmed :/
>>>
>>> anyways ... how about others?
>>>
>>> -- Allen
>>>
>>>
>>> On Tue, 2005-08-09 at 13:59, Elias Torres wrote:
>>>   
>>>
>>>> I'm also not an official part of the project, but I might be running
>>>> the second or third largest Roller-based website ;-) and my opinion if
>>>> it counts at all, is that if Dave/Allen can handle the heat in the
>>>> kitchen, let them stay in the kitchen. I'm sure that's why they pay
>>>> them the big bucks.
>>>>     
>>>
>>>   
>>

Re: Sharing some stats

["Matthew P. Schmidt" <ma...@javalobby.org>]

I'll share.  We have about 9000 blogs with rapid growth.  Its running on 
one dual xeon, on MySQL and Resin and uses about a 1.6G heap with 3 3000 
item caches (page, rss, last modified).  I'm not sure how much they're 
actually being used.  Load is generally pretty manageable, especially 
with the latest version of Roller.   As for hits, most of it is RSS, 
with several million hits of that per month.  There are also a million 
or more blog views per month and the server doesn't generally have to 
restart that often.  Before merging our fork with Roller 1.2, we were 
restarting every night due to a memory leak.  Our biggest problem is 
probably the amount of referrer spam, even with a healthy blacklist of 
dirty words.  I think static HTML for the pages (which they basically 
are now if your cache is big enough) and a better referrer filter would 
be two big helpers for us.  

Matthew P. Schmidt
Vice President of Technology
Javalobby.org
Email: matt@javalobby.org
Phone: 919.678.0300



Elias Torres wrote:

>We have also around 1800 blogs and it's growing rapidly. Also, around
>12K people make use of the system in total and this we know because we
>don't allow anonymous comments. You need to be authenticated for
>someone to comment/post.
>
>I wonder why you are not allowed to give out server info. Maybe I'll
>hold off on that too for now.
>
>I'm sure others have asked this before, but is there a plan of turning
>Roller blogs into static HTML? I'd be interested in hearing your
>thoughts on this. I'm sure this would alleviate many of the caching
>performance problems.
>
>Elias
>
>On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
>  
>
>>I am diverging from the deployments discussion for a second because Elias comment sparked a question.  I'm interested in anything that anyone wants to share about their roller installation ...
>>
>>how many blogs does it have?
>>what is your performance like?
>>what are your cache size settings?
>>how good is your caching efficiency on average?
>>any numbers on how much activity the site gets? hits/visits? load?
>>server info?  processors?  ram?  OS?  webserver?  database?
>>how is stability?  does the server require restarts often?
>>
>>anything that can be shared would be cool.  i'd like to keep some info on who is running roller and in what kind of environments so that we can hopefully make sure we are keeping roller well suited for various situations.
>>
>>blogs.sun.com currently has almost 1600 blogs on it and our stability is quite good.  i would give out server info, but i'm not allowed to.  probably our biggest performance concern is page caching, which has gotten worse and worse as more people start blogging.  i think out cache size is 4000 right now and that is plenty for the rss cache, but the page cache is still overwhelmed :/
>>
>>anyways ... how about others?
>>
>>-- Allen
>>
>>
>>On Tue, 2005-08-09 at 13:59, Elias Torres wrote:
>>    
>>
>>>I'm also not an official part of the project, but I might be running
>>>the second or third largest Roller-based website ;-) and my opinion if
>>>it counts at all, is that if Dave/Allen can handle the heat in the
>>>kitchen, let them stay in the kitchen. I'm sure that's why they pay
>>>them the big bucks.
>>>      
>>>
>>    
>>

Re: Sharing some stats

[Elias Torres <el...@gmail.com>]

We have also around 1800 blogs and it's growing rapidly. Also, around
12K people make use of the system in total and this we know because we
don't allow anonymous comments. You need to be authenticated for
someone to comment/post.

I wonder why you are not allowed to give out server info. Maybe I'll
hold off on that too for now.

I'm sure others have asked this before, but is there a plan of turning
Roller blogs into static HTML? I'd be interested in hearing your
thoughts on this. I'm sure this would alleviate many of the caching
performance problems.

Elias

On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> I am diverging from the deployments discussion for a second because Elias comment sparked a question.  I'm interested in anything that anyone wants to share about their roller installation ...
> 
> how many blogs does it have?
> what is your performance like?
> what are your cache size settings?
> how good is your caching efficiency on average?
> any numbers on how much activity the site gets? hits/visits? load?
> server info?  processors?  ram?  OS?  webserver?  database?
> how is stability?  does the server require restarts often?
> 
> anything that can be shared would be cool.  i'd like to keep some info on who is running roller and in what kind of environments so that we can hopefully make sure we are keeping roller well suited for various situations.
> 
> blogs.sun.com currently has almost 1600 blogs on it and our stability is quite good.  i would give out server info, but i'm not allowed to.  probably our biggest performance concern is page caching, which has gotten worse and worse as more people start blogging.  i think out cache size is 4000 right now and that is plenty for the rss cache, but the page cache is still overwhelmed :/
> 
> anyways ... how about others?
> 
> -- Allen
> 
> 
> On Tue, 2005-08-09 at 13:59, Elias Torres wrote:
> > I'm also not an official part of the project, but I might be running
> > the second or third largest Roller-based website ;-) and my opinion if
> > it counts at all, is that if Dave/Allen can handle the heat in the
> > kitchen, let them stay in the kitchen. I'm sure that's why they pay
> > them the big bucks.
> 
>

Sharing some stats

[Allen Gilliland <Al...@Sun.COM>]

I am diverging from the deployments discussion for a second because Elias comment sparked a question.  I'm interested in anything that anyone wants to share about their roller installation ...

how many blogs does it have?
what is your performance like?
what are your cache size settings?
how good is your caching efficiency on average?
any numbers on how much activity the site gets? hits/visits? load?
server info?  processors?  ram?  OS?  webserver?  database?
how is stability?  does the server require restarts often?

anything that can be shared would be cool.  i'd like to keep some info on who is running roller and in what kind of environments so that we can hopefully make sure we are keeping roller well suited for various situations.

blogs.sun.com currently has almost 1600 blogs on it and our stability is quite good.  i would give out server info, but i'm not allowed to.  probably our biggest performance concern is page caching, which has gotten worse and worse as more people start blogging.  i think out cache size is 4000 right now and that is plenty for the rss cache, but the page cache is still overwhelmed :/

anyways ... how about others?

-- Allen


On Tue, 2005-08-09 at 13:59, Elias Torres wrote:
> I'm also not an official part of the project, but I might be running
> the second or third largest Roller-based website ;-) and my opinion if
> it counts at all, is that if Dave/Allen can handle the heat in the
> kitchen, let them stay in the kitchen. I'm sure that's why they pay
> them the big bucks.

Re: Monthly deployments, monthly releases? (long)

[Dave Johnson <da...@rollerweblogger.org>]

Allen gave some good responses to this stuff, I've added a couple below.


On Aug 9, 2005, at 4:59 PM, Elias Torres wrote:

> I'm also not an official part of the project, but I might be running
> the second or third largest Roller-based website ;-) and my opinion if
> it counts at all, is that if Dave/Allen can handle the heat in the
> kitchen, let them stay in the kitchen. I'm sure that's why they pay
> them the big bucks.
>
> Now, realistically speaking, I'm not really sure how long you can keep
> such schedule because I think that you'll either run out of
> "good/useful" ideas to implement or Roller will become like Word/Excel
> filled of features that people don't care about. Also, development
> machines for roller will need bigger hard drives to cope the billions
> of lines of code that will accumulate with such aggressive schedule.
>
> End of joking tone.

There is some truth to that humor.


> Start of serious tone.
>
> - Will monthly releases include a decent amount of bug fixing or will
> it only be new features?
> - Will Dave/Allen work at all on community requirements?

The features that we've added to Roller come from 1) our user community 
on blogs.sun.com and 2) our perceptions of what external Roller 
"customers" want. Group blogging is a good example of #2. We didn't 
have a great need for group blogging at BSC, but we heard many requests 
for group blogging from potential Roller customers.

- Dave

Re: Monthly deployments, monthly releases? (long)

[Elias Torres <el...@gmail.com>]

I'm also not an official part of the project, but I might be running
the second or third largest Roller-based website ;-) and my opinion if
it counts at all, is that if Dave/Allen can handle the heat in the
kitchen, let them stay in the kitchen. I'm sure that's why they pay
them the big bucks.

Now, realistically speaking, I'm not really sure how long you can keep
such schedule because I think that you'll either run out of
"good/useful" ideas to implement or Roller will become like Word/Excel
filled of features that people don't care about. Also, development
machines for roller will need bigger hard drives to cope the billions
of lines of code that will accumulate with such aggressive schedule.

End of joking tone.

Start of serious tone.

- Will monthly releases include a decent amount of bug fixing or will
it only be new features?
- Will Dave/Allen work at all on community requirements?
- What happens when the rest of the folks don't have the time
bandwidth to design/spec out common features between Sun/BSC and rest
of the community? Will you end up making all of the decisions
regarding feature X? I guess this is how OS works anyways, whoever is
writing the code makes the decisions. :-)
- Will every new feature *have* to be developed in branches to not
interrupt your monthly schedule?
- I can't think of any more questions at this moment.

Also, ditto on Allen's anal comment about design docs, etc. Allen and
I have had a thread going on authentication/user registry for a while
and I hadn't heard from Matt at all. Allen was suggesting to revisit
this and come out with a spec that then we could implement. I'm still
trying to get my head around the current state of the world in Roller
and I'm not sure whether Acegi is the right direction (I'm not
familiar with the technology, that's all). It'd be funky to all of the
sudden update from SVN and get everything reimplemented using Acegi.

Just my $0.02.

Regards,

Elias Torres

On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> On Tue, 2005-08-09 at 11:22, Matt Raible wrote:
> > Dave and Allen,
> >
> > You guys are obviously biased in your votes here - primarily because
> > Roller is your job and you've been mandated to schedule the releases
> > to more fit their work schedule.  I don't blame you.
> >
> > You guys are contributing the most code, and handling all release
> > aspects - so I believe the decision is up to you.  I'm in favor of
> > whatever you guys advocate.  If you are going to go through with this,
> > it'd be nice to see a release schedule so we know when it's best to
> > commit code.  I'd like to integrate Acegi this week or next, but if
> > there's a release coming out soon, I should probably wait.
> 
> Dave and I are certainly influenced by our commitments to our team here at Sun, but ultimately the decision should come from the community at large.
> 
> I think a release schedule is a good idea and as usual we will want to communicate to everyone on the team when a release is nearing so that we can coordinate changes to the repository.  This also gives commiters a chance to better guage what release they want to target certain code for.
> 
> About commiting the Acegi stuff, my biggest concern here is not where/when to commit it but rather that I don't recall any formal proposal being sent around.  I know we talked about this a few times, but I like to see some kind of document that at least talks about ...
> 
> - are there db schema changes required, and if so what changes.
> - very generally, what is the new code design.  what classes are new, changed, removed?  how do they fit together?
> - what changes would there be to the UI, if any?
> 
> Hopefully I am not coming off as anal, but I am generally of the opinion that our greatest opportunity for teamwork comes at design time, not implemenation time.  So to really collaborate on this project as effectively as possible I think we need to have good design docs that are reviewed by everyone before coding beings (or gets too far along).
> 
> -- Allen
> 
> 
> >
> > Matt
> >
> > On 8/9/05, Lance Lavandowska <la...@gmail.com> wrote:
> > > On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> > > >
> > > > > (2) Strict non-breakage policies on the trunk.  Successful build = full
> > > > > test passage.
> > > >
> > > > i'm not sure i agree here.  obviously we can't have ppl commiting code that is 25% complete or code that is completely broken, but who does that anyways?  i think most of us develop a feature in our own workspace and only commit it when we believe it's reasonably complete.
> > >
> > > Heh, Allen (as a relatively late-comer) isn't familiar with the
> > > Lavandowska "it's good enough" Principle.  I've often committed code
> > > that just-barely does what it is intended to do.  Often it's provided
> > > as a proof-of-concept, intended to elicit feedback and cooperation,
> > > that gets pushed into production.
> > >
> > > Now this mostly came about when we didn't do branches (I think because
> > > none of us were familiar/comfortable enough with them).  Now that I've
> > > trimmed my code contributions down to once-per-year I think there is
> > > much less danger from the Lavandowska Principle.
> > >
> > > Lance
> > >
> 
>

Re: Monthly deployments, monthly releases? (long)

[Allen Gilliland <Al...@Sun.COM>]

On Tue, 2005-08-09 at 11:22, Matt Raible wrote:
> Dave and Allen,
> 
> You guys are obviously biased in your votes here - primarily because
> Roller is your job and you've been mandated to schedule the releases
> to more fit their work schedule.  I don't blame you.
> 
> You guys are contributing the most code, and handling all release
> aspects - so I believe the decision is up to you.  I'm in favor of
> whatever you guys advocate.  If you are going to go through with this,
> it'd be nice to see a release schedule so we know when it's best to
> commit code.  I'd like to integrate Acegi this week or next, but if
> there's a release coming out soon, I should probably wait.

Dave and I are certainly influenced by our commitments to our team here at Sun, but ultimately the decision should come from the community at large.

I think a release schedule is a good idea and as usual we will want to communicate to everyone on the team when a release is nearing so that we can coordinate changes to the repository.  This also gives commiters a chance to better guage what release they want to target certain code for.

About commiting the Acegi stuff, my biggest concern here is not where/when to commit it but rather that I don't recall any formal proposal being sent around.  I know we talked about this a few times, but I like to see some kind of document that at least talks about ...

- are there db schema changes required, and if so what changes.
- very generally, what is the new code design.  what classes are new, changed, removed?  how do they fit together?
- what changes would there be to the UI, if any?

Hopefully I am not coming off as anal, but I am generally of the opinion that our greatest opportunity for teamwork comes at design time, not implemenation time.  So to really collaborate on this project as effectively as possible I think we need to have good design docs that are reviewed by everyone before coding beings (or gets too far along).

-- Allen


> 
> Matt  
> 
> On 8/9/05, Lance Lavandowska <la...@gmail.com> wrote:
> > On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> > >
> > > > (2) Strict non-breakage policies on the trunk.  Successful build = full
> > > > test passage.
> > >
> > > i'm not sure i agree here.  obviously we can't have ppl commiting code that is 25% complete or code that is completely broken, but who does that anyways?  i think most of us develop a feature in our own workspace and only commit it when we believe it's reasonably complete.
> > 
> > Heh, Allen (as a relatively late-comer) isn't familiar with the
> > Lavandowska "it's good enough" Principle.  I've often committed code
> > that just-barely does what it is intended to do.  Often it's provided
> > as a proof-of-concept, intended to elicit feedback and cooperation,
> > that gets pushed into production.
> > 
> > Now this mostly came about when we didn't do branches (I think because
> > none of us were familiar/comfortable enough with them).  Now that I've
> > trimmed my code contributions down to once-per-year I think there is
> > much less danger from the Lavandowska Principle.
> > 
> > Lance
> >

Re: Monthly deployments, monthly releases? (long)

[Allen Gilliland <Al...@Sun.COM>]

Seems reasonable to me.  I've updated the doc.

-- Allen


On Tue, 2005-08-09 at 20:43, Rudman Max wrote:
> Can we name release branches using .x instead of .0? (Eg: roller_1.x)  
> Having a branch named roller_1.0 is a bit confusing to me as I would  
> assume it contains just that (minor) release.
> 
> Max
> 
> On Aug 9, 2005, at 4:44 PM, Allen Gilliland wrote:
> 
> > I've put up some notes on how I think the release system could work  
> > so that it's somewhere more static than just buried in all this email.
> >
> > http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan
> >
> > Personally, I think this plan should work well for Roller and at  
> > the very least I think it's worth trying out.
> >
> > -- Allen
> >
> >
> > On Tue, 2005-08-09 at 12:36, Lance Lavandowska wrote:
> >
> >> I echo Matt's comments.  While I personally feel monthly might be too
> >> aggressive, you two are going to be feeling the heat (in the  
> >> kitchen),
> >> so in the end it's your decision to make.
> >>
> >> Lance
> >>
> >> On 8/9/05, Matt Raible <mr...@gmail.com> wrote:
> >>
> >>> Dave and Allen,
> >>>
> >>> You guys are obviously biased in your votes here - primarily because
> >>> Roller is your job and you've been mandated to schedule the releases
> >>> to more fit their work schedule.  I don't blame you.
> >>>
> >>> You guys are contributing the most code, and handling all release
> >>> aspects - so I believe the decision is up to you.  I'm in favor of
> >>> whatever you guys advocate.  If you are going to go through with  
> >>> this,
> >>> it'd be nice to see a release schedule so we know when it's best to
> >>> commit code.  I'd like to integrate Acegi this week or next, but if
> >>> there's a release coming out soon, I should probably wait.
> >>>
> >>> Matt
> >
> 

Re: Monthly deployments, monthly releases? (long)

[Rudman Max <mr...@steelbrick.com>]

Can we name release branches using .x instead of .0? (Eg: roller_1.x)  
Having a branch named roller_1.0 is a bit confusing to me as I would  
assume it contains just that (minor) release.

Max

On Aug 9, 2005, at 4:44 PM, Allen Gilliland wrote:

> I've put up some notes on how I think the release system could work  
> so that it's somewhere more static than just buried in all this email.
>
> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan
>
> Personally, I think this plan should work well for Roller and at  
> the very least I think it's worth trying out.
>
> -- Allen
>
>
> On Tue, 2005-08-09 at 12:36, Lance Lavandowska wrote:
>
>> I echo Matt's comments.  While I personally feel monthly might be too
>> aggressive, you two are going to be feeling the heat (in the  
>> kitchen),
>> so in the end it's your decision to make.
>>
>> Lance
>>
>> On 8/9/05, Matt Raible <mr...@gmail.com> wrote:
>>
>>> Dave and Allen,
>>>
>>> You guys are obviously biased in your votes here - primarily because
>>> Roller is your job and you've been mandated to schedule the releases
>>> to more fit their work schedule.  I don't blame you.
>>>
>>> You guys are contributing the most code, and handling all release
>>> aspects - so I believe the decision is up to you.  I'm in favor of
>>> whatever you guys advocate.  If you are going to go through with  
>>> this,
>>> it'd be nice to see a release schedule so we know when it's best to
>>> commit code.  I'd like to integrate Acegi this week or next, but if
>>> there's a release coming out soon, I should probably wait.
>>>
>>> Matt
>

Re: Allen's proposed RollerReleasePlan

[Matt Raible <mr...@gmail.com>]

Sounds reasonable to me.

Matt

On 8/10/05, Dave Johnson <da...@rollerweblogger.org> wrote:
> 
> > http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan
> 
> I like it. Do folks think this is a reasonable plan?
> 
> - Dave
> 
> 
> On Aug 9, 2005, at 4:44 PM, Allen Gilliland wrote:
> 
> > I've put up some notes on how I think the release system could work so
> > that it's somewhere more static than just buried in all this email.
> >
> > http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan
> >
> > Personally, I think this plan should work well for Roller and at the
> > very least I think it's worth trying out.
> >
> > -- Allen
> >
> >
> > On Tue, 2005-08-09 at 12:36, Lance Lavandowska wrote:
> >> I echo Matt's comments.  While I personally feel monthly might be too
> >> aggressive, you two are going to be feeling the heat (in the kitchen),
> >> so in the end it's your decision to make.
> >>
> >> Lance
> >>
> >> On 8/9/05, Matt Raible <mr...@gmail.com> wrote:
> >>> Dave and Allen,
> >>>
> >>> You guys are obviously biased in your votes here - primarily because
> >>> Roller is your job and you've been mandated to schedule the releases
> >>> to more fit their work schedule.  I don't blame you.
> >>>
> >>> You guys are contributing the most code, and handling all release
> >>> aspects - so I believe the decision is up to you.  I'm in favor of
> >>> whatever you guys advocate.  If you are going to go through with
> >>> this,
> >>> it'd be nice to see a release schedule so we know when it's best to
> >>> commit code.  I'd like to integrate Acegi this week or next, but if
> >>> there's a release coming out soon, I should probably wait.
> >>>
> >>> Matt
> >
> 
>

Allen's proposed RollerReleasePlan

[Dave Johnson <da...@rollerweblogger.org>]

> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan

I like it. Do folks think this is a reasonable plan?

- Dave


On Aug 9, 2005, at 4:44 PM, Allen Gilliland wrote:

> I've put up some notes on how I think the release system could work so 
> that it's somewhere more static than just buried in all this email.
>
> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan
>
> Personally, I think this plan should work well for Roller and at the 
> very least I think it's worth trying out.
>
> -- Allen
>
>
> On Tue, 2005-08-09 at 12:36, Lance Lavandowska wrote:
>> I echo Matt's comments.  While I personally feel monthly might be too
>> aggressive, you two are going to be feeling the heat (in the kitchen),
>> so in the end it's your decision to make.
>>
>> Lance
>>
>> On 8/9/05, Matt Raible <mr...@gmail.com> wrote:
>>> Dave and Allen,
>>>
>>> You guys are obviously biased in your votes here - primarily because
>>> Roller is your job and you've been mandated to schedule the releases
>>> to more fit their work schedule.  I don't blame you.
>>>
>>> You guys are contributing the most code, and handling all release
>>> aspects - so I believe the decision is up to you.  I'm in favor of
>>> whatever you guys advocate.  If you are going to go through with 
>>> this,
>>> it'd be nice to see a release schedule so we know when it's best to
>>> commit code.  I'd like to integrate Acegi this week or next, but if
>>> there's a release coming out soon, I should probably wait.
>>>
>>> Matt
>

Re: Monthly deployments, monthly releases? (long)

[Allen Gilliland <Al...@Sun.COM>]

I've put up some notes on how I think the release system could work so that it's somewhere more static than just buried in all this email.

http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan

Personally, I think this plan should work well for Roller and at the very least I think it's worth trying out.

-- Allen


On Tue, 2005-08-09 at 12:36, Lance Lavandowska wrote:
> I echo Matt's comments.  While I personally feel monthly might be too
> aggressive, you two are going to be feeling the heat (in the kitchen),
> so in the end it's your decision to make.
> 
> Lance
> 
> On 8/9/05, Matt Raible <mr...@gmail.com> wrote:
> > Dave and Allen,
> > 
> > You guys are obviously biased in your votes here - primarily because
> > Roller is your job and you've been mandated to schedule the releases
> > to more fit their work schedule.  I don't blame you.
> > 
> > You guys are contributing the most code, and handling all release
> > aspects - so I believe the decision is up to you.  I'm in favor of
> > whatever you guys advocate.  If you are going to go through with this,
> > it'd be nice to see a release schedule so we know when it's best to
> > commit code.  I'd like to integrate Acegi this week or next, but if
> > there's a release coming out soon, I should probably wait.
> > 
> > Matt

Re: Monthly deployments, monthly releases? (long)

[Lance Lavandowska <la...@gmail.com>]

I echo Matt's comments.  While I personally feel monthly might be too
aggressive, you two are going to be feeling the heat (in the kitchen),
so in the end it's your decision to make.

Lance

On 8/9/05, Matt Raible <mr...@gmail.com> wrote:
> Dave and Allen,
> 
> You guys are obviously biased in your votes here - primarily because
> Roller is your job and you've been mandated to schedule the releases
> to more fit their work schedule.  I don't blame you.
> 
> You guys are contributing the most code, and handling all release
> aspects - so I believe the decision is up to you.  I'm in favor of
> whatever you guys advocate.  If you are going to go through with this,
> it'd be nice to see a release schedule so we know when it's best to
> commit code.  I'd like to integrate Acegi this week or next, but if
> there's a release coming out soon, I should probably wait.
> 
> Matt

RE: Monthly deployments, monthly releases? (long)

["Noel J. Bergman" <no...@devtech.com>]

> it'd be nice to see a release schedule so we know when it's best to
> commit code.  I'd like to integrate Acegi this week or next, but if
> there's a release coming out soon, I should probably wait.

Collectively, you might want to leverage SVN to prevent this problem.

For example, when a Release Manager is getting ready to cut a release, they
can copy the trunk to a branch and work with polishing it up there.  You
commit to the trunk.  If there is something in the trunk that is desired for
the release, it can be copied over.  When the release is finished, move it
to a tag and cut the builds.

	--- Noel

Re: Monthly deployments, monthly releases? (long)

[Matt Raible <mr...@gmail.com>]

Dave and Allen,

You guys are obviously biased in your votes here - primarily because
Roller is your job and you've been mandated to schedule the releases
to more fit their work schedule.  I don't blame you.

You guys are contributing the most code, and handling all release
aspects - so I believe the decision is up to you.  I'm in favor of
whatever you guys advocate.  If you are going to go through with this,
it'd be nice to see a release schedule so we know when it's best to
commit code.  I'd like to integrate Acegi this week or next, but if
there's a release coming out soon, I should probably wait.

Matt  

On 8/9/05, Lance Lavandowska <la...@gmail.com> wrote:
> On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> >
> > > (2) Strict non-breakage policies on the trunk.  Successful build = full
> > > test passage.
> >
> > i'm not sure i agree here.  obviously we can't have ppl commiting code that is 25% complete or code that is completely broken, but who does that anyways?  i think most of us develop a feature in our own workspace and only commit it when we believe it's reasonably complete.
> 
> Heh, Allen (as a relatively late-comer) isn't familiar with the
> Lavandowska "it's good enough" Principle.  I've often committed code
> that just-barely does what it is intended to do.  Often it's provided
> as a proof-of-concept, intended to elicit feedback and cooperation,
> that gets pushed into production.
> 
> Now this mostly came about when we didn't do branches (I think because
> none of us were familiar/comfortable enough with them).  Now that I've
> trimmed my code contributions down to once-per-year I think there is
> much less danger from the Lavandowska Principle.
> 
> Lance
>

Re: Monthly deployments, monthly releases? (long)

[Lance Lavandowska <la...@gmail.com>]

On 8/9/05, Allen Gilliland <Al...@sun.com> wrote:
> 
> > (2) Strict non-breakage policies on the trunk.  Successful build = full
> > test passage.
> 
> i'm not sure i agree here.  obviously we can't have ppl commiting code that is 25% complete or code that is completely broken, but who does that anyways?  i think most of us develop a feature in our own workspace and only commit it when we believe it's reasonably complete.

Heh, Allen (as a relatively late-comer) isn't familiar with the
Lavandowska "it's good enough" Principle.  I've often committed code
that just-barely does what it is intended to do.  Often it's provided
as a proof-of-concept, intended to elicit feedback and cooperation,
that gets pushed into production.

Now this mostly came about when we didn't do branches (I think because
none of us were familiar/comfortable enough with them).  Now that I've
trimmed my code contributions down to once-per-year I think there is
much less danger from the Lavandowska Principle.

Lance

Re: Monthly deployments, monthly releases? (long)

[Allen Gilliland <Al...@Sun.COM>]

So, I am pretty much of the same opinion as Dave.  I think it would help us out a lot with our work on BSC if Roller was kept in sync, however I understand that in many ways it may not be best to force Roller into a monthly release cycle.

I would also like to add that nothing is set in stone, so if on a given month it just isn't going to work to do a Roller release, then fine, we don't do it.  

However, as an example, our latest code on BSC is the current trunk and we feel that this easily could have been a Roller 1.3 release.  It includes the new theme management code, the pojo wrappers, and some bug fixes.  It's been running very well for us and I believe it certainly includes enough new features to warrant an actual release, plus the upgrade process is nothing, just deploy the new code and you're done.

One of the proposed plans to make sure new releases are stable and easy to upgrade is to only allow schema changes for major releases (i.e. 1.x to 2.x).  We would then enforce the rule that any minor release does not contain actual schema changes and therefore the upgrade path for minor releases can be kept to an absolute minimum.  Under this plan we would schedule major releases roughly every 3 months or so, meaning that we would typically release a new major version like 2.0 and do 2-3 minor releases off that version before doing a new major release.  Of course we would also maintain each major version in it's own branch and we would commit bug fixes to old branches if needed, however the expectation for Roller customers/users is that to get the latest features you have to be on the latest major version.

So given our current situation I am suggesting this ...

- we continue to do 1.x releases off the trunk each month
- when 2.0 is ready the trunk gets branched into the 1.x branch and 2.0 goes to trunk
- after the first 2.0 release we create a 3.x branch where anyone can work on code that requires a schema change.
- we continue to do 2.x releases off the trunk until we are ready for 3.0
- any really important 1.x bug fixes can go into the old 1.x branch and we can do a new release from that

would people agree to that?

i also have a few comments on the points that Anil made below.

On Tue, 2005-08-09 at 07:25, Anil Gangolli wrote:
> (1) Much much better test automation and coverage, including the upgrade 
> path.  New code =>  new tests with good coverage.

i agree that we need good test automation, but it's also true that with smaller releases we introduce less chance errors and therefore testing becomes a smaller task as well.  we all hate testing huge code changes which is one of the reasons to support smaller and more incremental releases.

> (2) Strict non-breakage policies on the trunk.  Successful build = full 
> test passage.

i'm not sure i agree here.  obviously we can't have ppl commiting code that is 25% complete or code that is completely broken, but who does that anyways?  i think most of us develop a feature in our own workspace and only commit it when we believe it's reasonably complete.

> (3) Establishing a practice of developing new features very completely 
> on branches, followed by an integration/test cycle wholly on the branch 
> before integration back to the trunk.  Branch development could span 
> multiple release cycles on the trunk.

i think this is very reasonable.

-- Allen


> 
> One can argue these are healthy directions to push in anyway (I would 
> certainly support that), but the fact is we're not nearly good enough at 
> these now to make a jump to short release cycles right away.
> 
> --a.
> 
> 
> Matthew P. Schmidt wrote:
> 
> > Hi guys.  I don't have any voting rights in Apache, but I do run the 
> > largest public installation of Roller (to my knowledge), so I figued 
> > I'd chime in.  While I'm a strong believer in release early, release 
> > often (we do it at JL all the time), when there are others using your 
> > application who have to upgrade/migrate, it isn't always the best 
> > choice.  We all know that upgrades never go as smoothly as planned, 
> > even with the best designed software, and when things require database 
> > changes, it gets even worse.  It seems to me that you'll be leaving 
> > out a large group of users by not making bug fixes to old releases and 
> > by forcing them to deploy new versions every month if they want to 
> > stay with the supported and stable release.
> > I also have to agree with the problems listed for monthly 
> > deployments.  That's a pretty short lifecycle to be developing new 
> > features, testing them, and deploying them.  At that pace you'd almost 
> > have 1.1 and 2.0 back to back in a month (extreme I know, but could 
> > have been possible).
> >
> > Anyway, those are my thoughts, if I had a vote, I'd stick with 
> > slightly longer release cycles.
> >
> > Matthew P. Schmidt
> > Vice President of Technology
> > Javalobby.org
> > Email: matt@javalobby.org
> > Phone: 919.678.0300
> >
> >
> >
> > Dave Johnson wrote:
> >
> >> My group (the blogs.sun.com or BSC team) at Sun believes pretty  
> >> strongly that small incremental releases are easier to document and  
> >> deploy than large ones.  Following this philosophy, we deploy new  
> >> features to our sites on a monthly basis. This presents some 
> >> challenges  for us because work directly with the Roller code-base 
> >> and we don't  maintain a separate fork of Roller.
> >>
> >> I had been thinking that BSC would deploy each month, operating off 
> >> of  SVN HEAD, but the Roller project would make releases every couple 
> >> of  months -- when new features justify a release.  Each major 
> >> Roller  release (e.g. 1.2) would happen in a branch and would get one 
> >> or more  bug fixes releases (e.g. 1.2.1 and 1.2.2, etc.). I thought 
> >> monthly  releases were too frequent. My reasoning was this:
> >>
> >> * Nobody would want to track the monthly releases
> >> * Users who don't track will have more difficult upgrades
> >> * Users who have deployed existing releases expect bugs to be fixed 
> >> in  those releases
> >> * Users would want to stick with major releases for a long time
> >>
> >> But there are problems with that. One problem is limited resources.  
> >> Since BSC folks (Allen and I) are busy making monthly deployments, 
> >> we  have limited time to participate in the testing, documenting and  
> >> releasing of big every-couple-of-months releases. We also have 
> >> limited  time (and limited interest) to work on fixing bugs in old 
> >> releases of  Roller.
> >>
> >> Long story short, the BSC team is now pushing for monthly Roller  
> >> releases to match the monthly BSC deployments. As a BSC team member, 
> >> I  have to advocate this and that is what I'm doing by writing this 
> >> email.  But as an independent Roller team member, I'm undecided. I'm 
> >> not sure  how I'd vote, so please help me out with some lively 
> >> discussion.
> >>
> >> So, let's say the Roller project makes monthly releases. What are 
> >> the  implications?
> >>
> >> * The SVN HEAD must be very near stable at all times because a new  
> >> release is never more than a month away. Any large development that  
> >> takes more than a month must occur in a separate branch (as we're 
> >> doing  with Roller 2.0 / group blogging).
> >>
> >> * It is no longer feasible to make bug fixes to old releases of 
> >> Roller.  The way you get new bug fixes is by keeping current on Roller.
> >>
> >> * To make it easy for users to keep up with Roller we'll need to 
> >> limit  the frequency of database schema changes and when schema 
> >> changes do  occur, the database upgrade must be automated and trouble 
> >> free.
> >>
> >> The advantages of release early, release often are well known so I  
> >> won't cover them here. You can read what ESR has to say about the  
> >> philosophy here:
> >> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
> >> ar01s04.html
> >>
> >> So my questions are:
> >>
> >>    * How does the Roller community feel about monthly releases?
> >>    * Is there any Apache policy that is relevant to this discussion?
> >>    * How do we use the Apache voting rules to resolve this?
> >>
> >>
> >> - Dave
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> 

Re: Monthly deployments, monthly releases? (long)

[Anil Gangolli <an...@busybuddha.org>]

My 2 cents with obligatory dogma. 

Monthly release cycles are too short for us. 

I can see us doing short release cycles only with some additional 
investment in the following areas.

(1) Much much better test automation and coverage, including the upgrade 
path.  New code =>  new tests with good coverage.
(2) Strict non-breakage policies on the trunk.  Successful build = full 
test passage.
(3) Establishing a practice of developing new features very completely 
on branches, followed by an integration/test cycle wholly on the branch 
before integration back to the trunk.  Branch development could span 
multiple release cycles on the trunk.

One can argue these are healthy directions to push in anyway (I would 
certainly support that), but the fact is we're not nearly good enough at 
these now to make a jump to short release cycles right away.

--a.


Matthew P. Schmidt wrote:

> Hi guys.  I don't have any voting rights in Apache, but I do run the 
> largest public installation of Roller (to my knowledge), so I figued 
> I'd chime in.  While I'm a strong believer in release early, release 
> often (we do it at JL all the time), when there are others using your 
> application who have to upgrade/migrate, it isn't always the best 
> choice.  We all know that upgrades never go as smoothly as planned, 
> even with the best designed software, and when things require database 
> changes, it gets even worse.  It seems to me that you'll be leaving 
> out a large group of users by not making bug fixes to old releases and 
> by forcing them to deploy new versions every month if they want to 
> stay with the supported and stable release.
> I also have to agree with the problems listed for monthly 
> deployments.  That's a pretty short lifecycle to be developing new 
> features, testing them, and deploying them.  At that pace you'd almost 
> have 1.1 and 2.0 back to back in a month (extreme I know, but could 
> have been possible).
>
> Anyway, those are my thoughts, if I had a vote, I'd stick with 
> slightly longer release cycles.
>
> Matthew P. Schmidt
> Vice President of Technology
> Javalobby.org
> Email: matt@javalobby.org
> Phone: 919.678.0300
>
>
>
> Dave Johnson wrote:
>
>> My group (the blogs.sun.com or BSC team) at Sun believes pretty  
>> strongly that small incremental releases are easier to document and  
>> deploy than large ones.  Following this philosophy, we deploy new  
>> features to our sites on a monthly basis. This presents some 
>> challenges  for us because work directly with the Roller code-base 
>> and we don't  maintain a separate fork of Roller.
>>
>> I had been thinking that BSC would deploy each month, operating off 
>> of  SVN HEAD, but the Roller project would make releases every couple 
>> of  months -- when new features justify a release.  Each major 
>> Roller  release (e.g. 1.2) would happen in a branch and would get one 
>> or more  bug fixes releases (e.g. 1.2.1 and 1.2.2, etc.). I thought 
>> monthly  releases were too frequent. My reasoning was this:
>>
>> * Nobody would want to track the monthly releases
>> * Users who don't track will have more difficult upgrades
>> * Users who have deployed existing releases expect bugs to be fixed 
>> in  those releases
>> * Users would want to stick with major releases for a long time
>>
>> But there are problems with that. One problem is limited resources.  
>> Since BSC folks (Allen and I) are busy making monthly deployments, 
>> we  have limited time to participate in the testing, documenting and  
>> releasing of big every-couple-of-months releases. We also have 
>> limited  time (and limited interest) to work on fixing bugs in old 
>> releases of  Roller.
>>
>> Long story short, the BSC team is now pushing for monthly Roller  
>> releases to match the monthly BSC deployments. As a BSC team member, 
>> I  have to advocate this and that is what I'm doing by writing this 
>> email.  But as an independent Roller team member, I'm undecided. I'm 
>> not sure  how I'd vote, so please help me out with some lively 
>> discussion.
>>
>> So, let's say the Roller project makes monthly releases. What are 
>> the  implications?
>>
>> * The SVN HEAD must be very near stable at all times because a new  
>> release is never more than a month away. Any large development that  
>> takes more than a month must occur in a separate branch (as we're 
>> doing  with Roller 2.0 / group blogging).
>>
>> * It is no longer feasible to make bug fixes to old releases of 
>> Roller.  The way you get new bug fixes is by keeping current on Roller.
>>
>> * To make it easy for users to keep up with Roller we'll need to 
>> limit  the frequency of database schema changes and when schema 
>> changes do  occur, the database upgrade must be automated and trouble 
>> free.
>>
>> The advantages of release early, release often are well known so I  
>> won't cover them here. You can read what ESR has to say about the  
>> philosophy here:
>> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ 
>> ar01s04.html
>>
>> So my questions are:
>>
>>    * How does the Roller community feel about monthly releases?
>>    * Is there any Apache policy that is relevant to this discussion?
>>    * How do we use the Apache voting rules to resolve this?
>>
>>
>> - Dave
>>
>>
>>
>>
>>
>>
>>
>>
>
>

Re: Monthly deployments, monthly releases? (long)

["Matthew P. Schmidt" <ma...@javalobby.org>]

Hi guys.  I don't have any voting rights in Apache, but I do run the 
largest public installation of Roller (to my knowledge), so I figued I'd 
chime in.  While I'm a strong believer in release early, release often 
(we do it at JL all the time), when there are others using your 
application who have to upgrade/migrate, it isn't always the best 
choice.  We all know that upgrades never go as smoothly as planned, even 
with the best designed software, and when things require database 
changes, it gets even worse.  It seems to me that you'll be leaving out 
a large group of users by not making bug fixes to old releases and by 
forcing them to deploy new versions every month if they want to stay 
with the supported and stable release. 

I also have to agree with the problems listed for monthly deployments.  
That's a pretty short lifecycle to be developing new features, testing 
them, and deploying them.  At that pace you'd almost have 1.1 and 2.0 
back to back in a month (extreme I know, but could have been possible).

Anyway, those are my thoughts, if I had a vote, I'd stick with slightly 
longer release cycles.

Matthew P. Schmidt
Vice President of Technology
Javalobby.org
Email: matt@javalobby.org
Phone: 919.678.0300



Dave Johnson wrote:

> My group (the blogs.sun.com or BSC team) at Sun believes pretty  
> strongly that small incremental releases are easier to document and  
> deploy than large ones.  Following this philosophy, we deploy new  
> features to our sites on a monthly basis. This presents some 
> challenges  for us because work directly with the Roller code-base and 
> we don't  maintain a separate fork of Roller.
>
> I had been thinking that BSC would deploy each month, operating off 
> of  SVN HEAD, but the Roller project would make releases every couple 
> of  months -- when new features justify a release.  Each major Roller  
> release (e.g. 1.2) would happen in a branch and would get one or more  
> bug fixes releases (e.g. 1.2.1 and 1.2.2, etc.). I thought monthly  
> releases were too frequent. My reasoning was this:
>
> * Nobody would want to track the monthly releases
> * Users who don't track will have more difficult upgrades
> * Users who have deployed existing releases expect bugs to be fixed 
> in  those releases
> * Users would want to stick with major releases for a long time
>
> But there are problems with that. One problem is limited resources.  
> Since BSC folks (Allen and I) are busy making monthly deployments, we  
> have limited time to participate in the testing, documenting and  
> releasing of big every-couple-of-months releases. We also have 
> limited  time (and limited interest) to work on fixing bugs in old 
> releases of  Roller.
>
> Long story short, the BSC team is now pushing for monthly Roller  
> releases to match the monthly BSC deployments. As a BSC team member, 
> I  have to advocate this and that is what I'm doing by writing this 
> email.  But as an independent Roller team member, I'm undecided. I'm 
> not sure  how I'd vote, so please help me out with some lively 
> discussion.
>
> So, let's say the Roller project makes monthly releases. What are the  
> implications?
>
> * The SVN HEAD must be very near stable at all times because a new  
> release is never more than a month away. Any large development that  
> takes more than a month must occur in a separate branch (as we're 
> doing  with Roller 2.0 / group blogging).
>
> * It is no longer feasible to make bug fixes to old releases of 
> Roller.  The way you get new bug fixes is by keeping current on Roller.
>
> * To make it easy for users to keep up with Roller we'll need to 
> limit  the frequency of database schema changes and when schema 
> changes do  occur, the database upgrade must be automated and trouble 
> free.
>
> The advantages of release early, release often are well known so I  
> won't cover them here. You can read what ESR has to say about the  
> philosophy here:
> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ 
> ar01s04.html
>
> So my questions are:
>
>    * How does the Roller community feel about monthly releases?
>    * Is there any Apache policy that is relevant to this discussion?
>    * How do we use the Apache voting rules to resolve this?
>
>
> - Dave
>
>
>
>
>
>
>
>