You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by David M Johnson <Da...@Sun.COM> on 2006/02/14 20:30:00 UTC
VOTE: release Roller 2.1
I've tried it on MySQL and PostgreSQL. Henri did a sanity check too.
It's in production, docs are updated.
Let's release it.
- Dave
On Feb 11, 2006, at 10:32 AM, David M Johnson wrote:
> New release candidate with Acegi 1.0 RC2 thanks to Raible.
> http://people.apache.org/~snoopdave/release_candidates/
>
> - Dave
>
>
>
> On Feb 10, 2006, at 2:24 PM, Matt Raible wrote:
>> IMO, a security package should always be on the latest release.
>> Should I check out from:
>>
>> https://svn.apache.org/repos/asf/incubator/roller/branches/
>> roller_2.1/
>>
>> To make this change?
>>
>> Matt
>>
>> On 2/10/06, David M Johnson <Da...@sun.com> wrote:
>>> I'm +0 on that Matt, unless there's a change it will break
>>> something.
>>>
>>> If you want to do it and do a little testing, I'll re-spin the
>>> build.
>>>
>>> - Dave
>>>
>>>
>>> On Feb 10, 2006, at 1:59 PM, Matt Raible wrote:
>>>
>>>> Should we upgrade to Acegi 1.0 RC2 before the release?
>>>>
>>>> http://forum.springframework.org/showthread.php?t=22167
>>>>
>>>> On 2/10/06, David M Johnson <Da...@sun.com> wrote:
>>>>>
>>>>> On Feb 10, 2006, at 1:35 PM, Henri Yandell wrote:
>>>>>> My usual release process worked happily this time.
>>>>>> Are there release notes listing the new features/fixes?
>>>>>
>>>>> Yes, the CHANGES.txt file lists the issues and the what's new
>>>>> page on
>>>>> the wiki provides a more user-friendly write-up with screenshots.
>>>>>
>>>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller_2.1_WhatsNew
>>>>>
>>>>> Time for a final release vote?
>>>>>
>>>>> - Dave
>>>>>
>>>>>
>>>>>>
>>>>>> Hen
>>>>>>
>>>>>> On 2/9/06, David M Johnson <Da...@sun.com> wrote:
>>>>>>>
>>>>>>> Roller 2.1-incubating RC3 is available. The only change since
>>>>>>> RC2 is
>>>>>>> a fix for the PostgreSQL issue that Henri identified (see
>>>>>>> below). I
>>>>>>> did some testing with PostgreSQL and check the 2.0.1 to 2.1
>>>>>>> upgrade
>>>>>>> path.
>>>>>>>
>>>>>>> Release files are here:
>>>>>>> http://people.apache.org/~snoopdave/release_candidates/
>>>>>>>
>>>>>>> Documentation drafts are here:
>>>>>>> http://people.apache.org/~snoopdave/doc_drafts/
>>>>>
>>>>>
>>>
>>>
Re: VOTE: release Roller 2.1
Posted by Henri Yandell <fl...@gmail.com>.
(Back online - took a while to figure out this hotel's network setup)
On 2/25/06, Ted Husted <te...@gmail.com> wrote:
> > I presume that's every PMC vote that was on a public list? Rather than
> > every PMC vote? Seems that it would largely be a history of release
> > discussions.
>
> It's even more important to log the *outcome* of the occaisonal
> PMC-list votes because they are not public. The discussions are
> sensitive, but the tally of the vote should not be. We want our
> process to be as transparent as possible (since this is how we teach
> developers to become committers).
So I see four constructs of a private vote on a PMC list - the issue,
the discussion, the votes, the result. There are two main reasons to
have a private discussion - security (be it legal or software) and
social (ie: it'd be impolite to site there throwing out -1's on a
public list).
In both cases, I can't see any reason why any one of the four should
become public - and in both cases I can't see why the discussion is
more important to keep private than the other three. If a PMC is able
to publicize 3 of the 4, it seems to me that it should just be having
the votes on the -dev list.
> > What are advantages are you finding of recording that? Again,
> > nitpicking rather than being against the idea, seems better just to
> > put in a link to the RESULT email in mail-archives. Only one I can
> > think of is that it helps to maintain the dynamic charter of a project
> > - as with all docs, the real charter gets set in stone and becomes
> > untouchable.
>
> Posting the tally in the STATUS file can serve as the RESULT email.
> The change to the STATUS goes out over the list, so everyone sees it.
> Now two goals are accomplished with one action. We have closure on the
> vote, and we have a summary of the votes for future reference.
One big disadvantage; the result is not a part of the vote thread -
chances are it's not even been sent to the same mailing list.
Minor nitpick - STATUS seems like a bad name - it implies the current
and what you're describing sounds more like an equivalent to the US
constitution's amendments - except with the noise of unimportant
issues (for the communities collective understanding) such as release
votes and pmc/committer votes.
Hen
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Allen Gilliland <Al...@Sun.COM>.
Ted Husted wrote:
>On 2/26/06, David M Johnson <Da...@sun.com> wrote:
>
>
>>1) Release planning
>>- If you want to add a feature to a release, you assign it to
>>yourself and set the "fix-for" field for the release you want. (see
>>the roadmap view in JIRA).
>>
>>2) Development
>>- If you are working on a feature you mark it as "ongoing" in JIRA
>>
>>3) Monthly RC1: second to last thursday of each month
>>- If anybody thinks this month's changes warrant a release, they
>>ensure that user docs, install docs, change lists and database
>>scripts are updated and they create RC1.
>>
>>
>
>3) Monthly Milestone ... and they tag the repository for X_Y_# and
>create the X.Y.# build.
>
>3b) They also create a X_Y_#+1 release target in JIRA, and update the
>nightly build to reference X_Y_(#+1)-SNAPSHOT
>
>Meanwhile, mainline development continues in the trunk, and we mark
>issues "resolved" in X_Y_(#+1) as soon as the fix is committed, citing
>the SVN revision number for good measure.
>
>
my opinion is still that this sounds overly complex for Roller's
situation. i think our current system using release candidates is
working fine and doesn't need to change right now. maybe in the future
as the project continues to grow we will decide this milestone approach
is better, but for now I would say that I haven't seen a sufficient
reason to change our current system.
-- Allen
>
>
>
>>4) Test week
>>- Testing focuses on those features marked "ongoing" those that pass
>>testing are marked as "resolved"
>>
>>
>
>Testing focuses on those features marked as resolved in X_Y_#. If
>testing fails, the issue is reopened with an appropriate comment.
>
>
>
>>5) Monthly RC2: last thursday of each month
>>- If somebody rolled an RC last week and testing/fixing went well,
>>then they create a branch for the release, create RC2 from it and
>>call for a release vote. We iterate on RCs until voters are satisfied
>>- While that is happening, mainline development continues in the trunk
>>- Once release is made, the "resolved" issues are marked as "closed"
>>in JIRA
>>
>>
>
>If somebody rolled a Milestone last week, and testing/fixing went
>well, then they call for a quality vote on the milestone. If the vote
>comes back "GA", we update the website to announce a new "best
>available" release.
>
>If mainline development is ready to commence on to the next minor or
>major release, we tag and branch the current repository for
>"X_Y_BRANCH" and designate the HEAD X_Z or Y_A.
>
>-Ted.
>
>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by David M Johnson <Da...@Sun.COM>.
I added a section called "The monthly release cycle" to the Roller
release plan document on the wiki with what I believe to be the
consensus on this issue.
http://rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan
Comments?
- Dave
On Feb 27, 2006, at 1:04 PM, Matt Raible wrote:
> On 2/27/06, David M Johnson <Da...@sun.com> wrote:
>>
>> On Feb 26, 2006, at 12:17 PM, Ted Husted wrote:
>>> On 2/26/06, David M Johnson <Da...@sun.com> wrote:
>>>> 3) Monthly RC1: second to last thursday of each month
>>>> - If anybody thinks this month's changes warrant a release, they
>>>> ensure that user docs, install docs, change lists and database
>>>> scripts are updated and they create RC1.
>>>
>>> 3) Monthly Milestone ... and they tag the repository for X_Y_# and
>>> create the X.Y.# build.
>>>
>>> 3b) They also create a X_Y_#+1 release target in JIRA, and
>>> update the
>>> nightly build to reference X_Y_(#+1)-SNAPSHOT
>>>
>>> Meanwhile, mainline development continues in the trunk, and we mark
>>> issues "resolved" in X_Y_(#+1) as soon as the fix is committed,
>>> citing
>>> the SVN revision number for good measure.
>>
>>
>> I understand now how this could work for us, but I guess I don't see
>> a good reason to change and it does seem more complex. Nobody has
>> spoken up on the cycle other than Ted, Allen and I have responded
>> about the release cycle. This could mean that folks are happy with
>> release cycle as is.
>
> I'm happy with it - but I also pull all my releases from SVN. In
> addition, when I have someone else install Roller - I wait for a
> release, not an RC.
>
>>
>> The repeat voting and "are we there yet" queries were irritating (and
>> my fault). I think the main problem with the voting has been that I
>> called for votes too early. We need to release an RC or two, get
>> positive feedback/testing and only call for a vote when it appears
>> that a vote can be won. Otherwise we get in a cycle.
>
> Release candidates are good - but you could also do a "pull from SVN
> when you get a chance". It's less formal, but would likely achieve
> the same results.
>
>>
>> Anybody else want to comment on the de facto release cycle that I
>> documented in the previous email?
>
> As a release manager on other projects, having a consistent release
> process is important if you plan on handing it off to someone.
> Otherwise, I'd recommend keeping your current system. That being
> said, it might be a good idea to hand it off to someone. ;-) Getting
> volunteers is the hard part.
>
> Matt
>
>>
>> - Dave
>>
>>
>>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Matt Raible <mr...@gmail.com>.
On 2/27/06, David M Johnson <Da...@sun.com> wrote:
>
> On Feb 26, 2006, at 12:17 PM, Ted Husted wrote:
> > On 2/26/06, David M Johnson <Da...@sun.com> wrote:
> >> 3) Monthly RC1: second to last thursday of each month
> >> - If anybody thinks this month's changes warrant a release, they
> >> ensure that user docs, install docs, change lists and database
> >> scripts are updated and they create RC1.
> >
> > 3) Monthly Milestone ... and they tag the repository for X_Y_# and
> > create the X.Y.# build.
> >
> > 3b) They also create a X_Y_#+1 release target in JIRA, and update the
> > nightly build to reference X_Y_(#+1)-SNAPSHOT
> >
> > Meanwhile, mainline development continues in the trunk, and we mark
> > issues "resolved" in X_Y_(#+1) as soon as the fix is committed, citing
> > the SVN revision number for good measure.
>
>
> I understand now how this could work for us, but I guess I don't see
> a good reason to change and it does seem more complex. Nobody has
> spoken up on the cycle other than Ted, Allen and I have responded
> about the release cycle. This could mean that folks are happy with
> release cycle as is.
I'm happy with it - but I also pull all my releases from SVN. In
addition, when I have someone else install Roller - I wait for a
release, not an RC.
>
> The repeat voting and "are we there yet" queries were irritating (and
> my fault). I think the main problem with the voting has been that I
> called for votes too early. We need to release an RC or two, get
> positive feedback/testing and only call for a vote when it appears
> that a vote can be won. Otherwise we get in a cycle.
Release candidates are good - but you could also do a "pull from SVN
when you get a chance". It's less formal, but would likely achieve
the same results.
>
> Anybody else want to comment on the de facto release cycle that I
> documented in the previous email?
As a release manager on other projects, having a consistent release
process is important if you plan on handing it off to someone.
Otherwise, I'd recommend keeping your current system. That being
said, it might be a good idea to hand it off to someone. ;-) Getting
volunteers is the hard part.
Matt
>
> - Dave
>
>
>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by David M Johnson <Da...@Sun.COM>.
On Feb 26, 2006, at 12:17 PM, Ted Husted wrote:
> On 2/26/06, David M Johnson <Da...@sun.com> wrote:
>> 3) Monthly RC1: second to last thursday of each month
>> - If anybody thinks this month's changes warrant a release, they
>> ensure that user docs, install docs, change lists and database
>> scripts are updated and they create RC1.
>
> 3) Monthly Milestone ... and they tag the repository for X_Y_# and
> create the X.Y.# build.
>
> 3b) They also create a X_Y_#+1 release target in JIRA, and update the
> nightly build to reference X_Y_(#+1)-SNAPSHOT
>
> Meanwhile, mainline development continues in the trunk, and we mark
> issues "resolved" in X_Y_(#+1) as soon as the fix is committed, citing
> the SVN revision number for good measure.
I understand now how this could work for us, but I guess I don't see
a good reason to change and it does seem more complex. Nobody has
spoken up on the cycle other than Ted, Allen and I have responded
about the release cycle. This could mean that folks are happy with
release cycle as is.
The repeat voting and "are we there yet" queries were irritating (and
my fault). I think the main problem with the voting has been that I
called for votes too early. We need to release an RC or two, get
positive feedback/testing and only call for a vote when it appears
that a vote can be won. Otherwise we get in a cycle.
Anybody else want to comment on the de facto release cycle that I
documented in the previous email?
- Dave
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Ted Husted <te...@gmail.com>.
On 2/26/06, David M Johnson <Da...@sun.com> wrote:
> 1) Release planning
> - If you want to add a feature to a release, you assign it to
> yourself and set the "fix-for" field for the release you want. (see
> the roadmap view in JIRA).
>
> 2) Development
> - If you are working on a feature you mark it as "ongoing" in JIRA
>
> 3) Monthly RC1: second to last thursday of each month
> - If anybody thinks this month's changes warrant a release, they
> ensure that user docs, install docs, change lists and database
> scripts are updated and they create RC1.
3) Monthly Milestone ... and they tag the repository for X_Y_# and
create the X.Y.# build.
3b) They also create a X_Y_#+1 release target in JIRA, and update the
nightly build to reference X_Y_(#+1)-SNAPSHOT
Meanwhile, mainline development continues in the trunk, and we mark
issues "resolved" in X_Y_(#+1) as soon as the fix is committed, citing
the SVN revision number for good measure.
> 4) Test week
> - Testing focuses on those features marked "ongoing" those that pass
> testing are marked as "resolved"
Testing focuses on those features marked as resolved in X_Y_#. If
testing fails, the issue is reopened with an appropriate comment.
> 5) Monthly RC2: last thursday of each month
> - If somebody rolled an RC last week and testing/fixing went well,
> then they create a branch for the release, create RC2 from it and
> call for a release vote. We iterate on RCs until voters are satisfied
> - While that is happening, mainline development continues in the trunk
> - Once release is made, the "resolved" issues are marked as "closed"
> in JIRA
If somebody rolled a Milestone last week, and testing/fixing went
well, then they call for a quality vote on the milestone. If the vote
comes back "GA", we update the website to announce a new "best
available" release.
If mainline development is ready to commence on to the next minor or
major release, we tag and branch the current repository for
"X_Y_BRANCH" and designate the HEAD X_Z or Y_A.
-Ted.
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Ted Husted <te...@gmail.com>.
On 2/26/06, David M Johnson <Da...@sun.com> wrote:
> Milestones
> May - Roller X.Y.1 good release, voted up to GA status
> June - Roller X.Y.2 not so good, just considered a alpha
> July - Roller X.Y.3 not so good, just considered a beta
> August - Roller X.Y.4 good release, voted up to GA status
>
> A user upgrading from X.Y.1 to X.Y.4 needs to incorporate database
> schema changes that were made in releases that never got the
> official seal of approval. Isn't that a problem?
Not that I can see. Each of these distributions would have contained
the scripts current to that build. The user would just use whatever
script came in the distribution.
By the time we got to
* September - Roller X.Y.5
usually, we would already know if X.Y.4 made the grade or not.
* If not, we could rename X.W-to-X.Y.4 to X.W-to-X.Y.5.
* If it did go GA, and the database changes continued, we could just
start a new X.Y.4-to-X.Y.5 file.
One of the reasons that HTTPD started to use this scheme is because it
lessens the need to freeze the codebase. Each milestone is a snapshot,
we roll the milestone, and we get back to work on the next milestone.
-Ted.
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by David M Johnson <Da...@Sun.COM>.
On Feb 25, 2006, at 9:42 PM, Ted Husted wrote:
> On 2/25/06, David M Johnson <Da...@sun.com> wrote:
>> I agree that's a problem with the milestone approach.
>
> I'm not seeing the problem. Could someone explain it again in
> different terms?
I think the problem is this. Each monthly release adds new features
and usually database schema changes. If each month's release is just
a milestone that may or may not be voted as an official "GA" release
then users will miss important database changes.
Milestones
May - Roller X.Y.1 good release, voted up to GA status
June - Roller X.Y.2 not so good, just considered a alpha
July - Roller X.Y.3 not so good, just considered a beta
August - Roller X.Y.4 good release, voted up to GA status
A user upgrading from X.Y.1 to X.Y.4 needs to incorporate database
schema changes that were made in releases that never got the
official seal of approval. Isn't that a problem?
Maybe we're not in search of a release cycle. Maybe the one we have
is fine. Here's the release cycle that has been in-effect recently
(i.e. this is what Allen and I have been doing).
1) Release planning
- If you want to add a feature to a release, you assign it to
yourself and set the "fix-for" field for the release you want. (see
the roadmap view in JIRA).
2) Development
- If you are working on a feature you mark it as "ongoing" in JIRA
3) Monthly RC1: second to last thursday of each month
- If anybody thinks this month's changes warrant a release, they
ensure that user docs, install docs, change lists and database
scripts are updated and they create RC1.
4) Test week
- Testing focuses on those features marked "ongoing" those that pass
testing are marked as "resolved"
5) Monthly RC2: last thursday of each month
- If somebody rolled an RC last week and testing/fixing went well,
then they create a branch for the release, create RC2 from it and
call for a release vote. We iterate on RCs until voters are satisfied
- While that is happening, mainline development continues in the trunk
- Once release is made, the "resolved" issues are marked as "closed"
in JIRA
- Dave
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Allen Gilliland <Al...@Sun.COM>.
that still sounds like a far more complex process than Roller needs.
I still support our current process where the community decides when
it's time to create a release and at the time we start the RC process.
-- Allen
Ted Husted wrote:
>On 2/25/06, Allen Gilliland <Al...@sun.com> wrote:
>
>
>>this sounds much more complicated to me. i prefer the RC approach that
>>we are using now.
>>
>>
>
>I'm probably not describing it well enough. Here's how HTTPD explains
>the system:
>
>* http://httpd.apache.org/dev/release.html
>
>-T.
>
>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Ted Husted <te...@gmail.com>.
On 2/25/06, Allen Gilliland <Al...@sun.com> wrote:
> this sounds much more complicated to me. i prefer the RC approach that
> we are using now.
I'm probably not describing it well enough. Here's how HTTPD explains
the system:
* http://httpd.apache.org/dev/release.html
-T.
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Allen Gilliland <Al...@Sun.COM>.
Ted Husted wrote:
>On 2/25/06, Allen Gilliland <Al...@sun.com> wrote:
>
>
>> As Ted said, we should be
>>working to meet the needs of our frontline customers and I believe that
>>means blogs.sun.com followed by IBM, jRoller, and on.
>>
>>
>
>Customer is an interesting word when applied to an open source
>project. The dictionary definition is "One that buys goods or
>services", but the ASF isn't selling anything. All of our software is
>provided to the public at no charge.
>
>Looking beyond "buy", customers are the people who make the product
>possible. In the context of an open source project, the people who
>make the project possible are people like Dave, and Allen, and Avil,
>and Henri, and Matt, and all other other committers and contributors.
>
>Our customers are the people who provide patches and posts. Other
>people who simply download and use the software are *potential*
>customers (or "users"). From an ASF perspective, the core customer is
>the PMC.
>
>
I am new to the ASF so I apologize for my ignorance, but how is the PMC
our core customer? Who is the PMC you are talking about?
>Now, if it is important to Allen and Dave, two of our best customers,
>that Roller meet the needs of blogs.sun.com then it should be
>important to the rest of the community too. But, blogs.sun.com is only
>important because it is important to Allen and Dave. Sun cannot be a
>committer, and so Sun can never be a true customer. Only individuals
>can be committers, and ASF committer rights are *never* contingent on
>employment. If Sun hired another developer to work on Roller, that
>individual would have to earn his or her karma in the usual way.
>
>
that sounds right to me. Dave was basically the start of the community,
but I joined just like anyone else and if someone else from Sun wanted
to contribute they would go through the same process.
>The goal of an ASF project is to create the software that the members
>of the PMC want to use in their own projects. We do want to attract
>new users, because that's how we recruit new PMC members, but users
>are a means to an end.
>
>
at this point i am unsure of what this has to do with our release
process. i think we would all agree that our goal is to provide a
valuable product for the people who use Roller. i'm not sure i
understand exactly how the PMC fits into that, but in any case my only
goal is to provide quality blogging software. personally, my motives
are inspired by blogs.sun.com, but not limited to or entirely controlled
by blogs.sun.com.
-- Allen
>-Ted.
>
>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Ted Husted <te...@gmail.com>.
On 2/25/06, Allen Gilliland <Al...@sun.com> wrote:
> As Ted said, we should be
> working to meet the needs of our frontline customers and I believe that
> means blogs.sun.com followed by IBM, jRoller, and on.
Customer is an interesting word when applied to an open source
project. The dictionary definition is "One that buys goods or
services", but the ASF isn't selling anything. All of our software is
provided to the public at no charge.
Looking beyond "buy", customers are the people who make the product
possible. In the context of an open source project, the people who
make the project possible are people like Dave, and Allen, and Avil,
and Henri, and Matt, and all other other committers and contributors.
Our customers are the people who provide patches and posts. Other
people who simply download and use the software are *potential*
customers (or "users"). From an ASF perspective, the core customer is
the PMC.
Now, if it is important to Allen and Dave, two of our best customers,
that Roller meet the needs of blogs.sun.com then it should be
important to the rest of the community too. But, blogs.sun.com is only
important because it is important to Allen and Dave. Sun cannot be a
committer, and so Sun can never be a true customer. Only individuals
can be committers, and ASF committer rights are *never* contingent on
employment. If Sun hired another developer to work on Roller, that
individual would have to earn his or her karma in the usual way.
The goal of an ASF project is to create the software that the members
of the PMC want to use in their own projects. We do want to attract
new users, because that's how we recruit new PMC members, but users
are a means to an end.
-Ted.
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Allen Gilliland <Al...@Sun.COM>.
Ted Husted wrote:
>On 2/25/06, David M Johnson <Da...@sun.com> wrote:
>
>
>>I agree that's a problem with the milestone approach.
>>
>>
>
>I'm not seeing the problem. Could someone explain it again in different terms?
>
>The only real difference is that instead of making a predetermination
>that a build will NOT be a release, but only a release candidate, we
>wait and make the determination after it is released. This simplifies
>the nomenclature and reduces the work of recasting the final release
>candidate as the final release. We just announce that a certain
>milestone is ready for primetime.
>
>As for things like database upgrade scripts, once a milestone runs,
>the scripts are frozen in the distribution, we can just rename the
>script for the next milestone. So the 2.0-2.1.4 script becomes the
>2.0-2.1.5 script. And with SVN, we can actually rename the file!
>
>Teams like HTTPD, Tomcat, Struts, and MyFaces have been using this
>scheme for a long time, and it seems to work well. Once the 2.1.4
>milestone is rolled, the nightly build becomes the 2.1.5-SNAPSHOT, so
>there is no ambiguity about what comes next.
>
>
>
this sounds much more complicated to me. i prefer the RC approach that
we are using now.
>
>
>>And I definitely agree that we need a more systematic approach to
>>making releases.
>>
>>I don't have an answer, but maybe by sharing some information about
>>our development and deployment cycles we can find come common ground
>>here.
>>
>>How often do customers and contributors like Javalobby, IBM and
>>others want to deploy new features?
>>
>>
>
>With the milestone approach, people have the option. It's not uncommon
>for there to be several GA releases with in the same version series.
>If the changes to 2.1.5 are not compelling, they can wait until
>another milestone, and jump in at say, 2.1.12.
>
>Whether a milestone contains only bugfixes or includes new
>backwardly-compatible features is something people can decide in a
>release plan for each milestone. We've been using a checklist format
>for the Struts release plans, which seems to be working well.
>
>* http://wiki.apache.org/struts/StrutsRelease128
>
>
again, sounds overly complicated to me. i think our current release
conventions are fine.
>
>
>
>>At blogs.sun.com, we like to make changes in small, incremental, easy
>>to test and easy to document chunks. Allen and I make monthly
>>deployments like so:
>> a) Second to last Thursday of month - code freeze / deploy to
>>production
>> b) Last Thursday of month - deploy to production
>>
>>Monthly works well for us (except for large feautures like group
>>blogging), but I've never thought that monthly Apache Rollerser release
>>make sense because other contributors don't have time to test every
>>month and I doubt customers want to upgrade on a monthly basis (or
>>the alternative, which is to fall behind).
>>
>>
>
>Oh, people always fall behind. Struts has a 18-month release cycle,
>and we still have a lot of people who want to migrate from 1.0 to 1.2,
>or from 1.1 to 1.3, or from 1.0 to 1.3.The curse of distributing
>reliable high-quality software is that makes it easier for users to
>stay the course!
>
>The important thing is that we have a release process that suits our
>core customers: the Roller PMC. It's nice that other people use our
>software, and hopefully some of these people will become contributors
>and committers, but the people we need to please first are the
>frontline volunteers who make the software possible.
>
>
i think we should release as fast as the developers are willing and able
to. this may sound a bit bastardly, but who cares if customers don't
want to keep up with our release pace? that's their problem, not ours.
as Dave said, at Sun we are doing monthly releases and I believe we are
delivering enough code in each month to warrant a new release. we also
test each release on blogs.sun.com before calling for a Roller release,
so i think that is plenty of "production" testing. i don't see any
reason not to do a Roller release each month if we are delivering
valuable new code which is production tested. As Ted said, we should be
working to meet the needs of our frontline customers and I believe that
means blogs.sun.com followed by IBM, jRoller, and on.
speaking more generally, i think the longer the development cycle the
harder we make things on ourselves, so i have always advocated for short
and compact release cycles. also note that short doesn't mean short
time, it means short on code. if we are delivering valuable and well
tested code every 2 weeks then lets release every 2 weeks, if it's once
a month then lets release once a month, and if its once every 2-3 months
then we should release then. so to make my point as blatenly obvious
and repetative as possible, i think we should be doing releases based on
how often we are delivering valuable new code that has been properly
tested. IMO we are doing that once a month, so i vote for monthly releases.
-- Allen
>-Ted.
>
>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Ted Husted <te...@gmail.com>.
On 2/25/06, David M Johnson <Da...@sun.com> wrote:
> I agree that's a problem with the milestone approach.
I'm not seeing the problem. Could someone explain it again in different terms?
The only real difference is that instead of making a predetermination
that a build will NOT be a release, but only a release candidate, we
wait and make the determination after it is released. This simplifies
the nomenclature and reduces the work of recasting the final release
candidate as the final release. We just announce that a certain
milestone is ready for primetime.
As for things like database upgrade scripts, once a milestone runs,
the scripts are frozen in the distribution, we can just rename the
script for the next milestone. So the 2.0-2.1.4 script becomes the
2.0-2.1.5 script. And with SVN, we can actually rename the file!
Teams like HTTPD, Tomcat, Struts, and MyFaces have been using this
scheme for a long time, and it seems to work well. Once the 2.1.4
milestone is rolled, the nightly build becomes the 2.1.5-SNAPSHOT, so
there is no ambiguity about what comes next.
> And I definitely agree that we need a more systematic approach to
> making releases.
>
> I don't have an answer, but maybe by sharing some information about
> our development and deployment cycles we can find come common ground
> here.
>
> How often do customers and contributors like Javalobby, IBM and
> others want to deploy new features?
With the milestone approach, people have the option. It's not uncommon
for there to be several GA releases with in the same version series.
If the changes to 2.1.5 are not compelling, they can wait until
another milestone, and jump in at say, 2.1.12.
Whether a milestone contains only bugfixes or includes new
backwardly-compatible features is something people can decide in a
release plan for each milestone. We've been using a checklist format
for the Struts release plans, which seems to be working well.
* http://wiki.apache.org/struts/StrutsRelease128
> At blogs.sun.com, we like to make changes in small, incremental, easy
> to test and easy to document chunks. Allen and I make monthly
> deployments like so:
> a) Second to last Thursday of month - code freeze / deploy to
> production
> b) Last Thursday of month - deploy to production
>
> Monthly works well for us (except for large feautures like group
> blogging), but I've never thought that monthly Apache Rollerser release
> make sense because other contributors don't have time to test every
> month and I doubt customers want to upgrade on a monthly basis (or
> the alternative, which is to fall behind).
Oh, people always fall behind. Struts has a 18-month release cycle,
and we still have a lot of people who want to migrate from 1.0 to 1.2,
or from 1.1 to 1.3, or from 1.0 to 1.3.The curse of distributing
reliable high-quality software is that makes it easier for users to
stay the course!
The important thing is that we have a release process that suits our
core customers: the Roller PMC. It's nice that other people use our
software, and hopefully some of these people will become contributors
and committers, but the people we need to please first are the
frontline volunteers who make the software possible.
-Ted.
In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by David M Johnson <Da...@Sun.COM>.
Comments below...
On Feb 25, 2006, at 12:20 AM, Henri Yandell wrote:
> On 2/24/06, Ted Husted <te...@gmail.com> wrote:
>> On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
>>> Personally, I think it gets silly to have to vote each time.
>
> The danger of a bombastic statement; everyone includes that one line
> in their replies and not the "however here's why we should" bit
> afterwards :)
>
>> Well, we really shouldn't cast a binding vote on a release until we
>> put into production ourselves. ("Eat our own dog food.") Since
>> this is
>> a new roll, we have to unroll it, put it up, and run the binary
>> through its paces. just to be certain all the bits are there.
>
> Biggest problem I find with that is that it means following tests
> aren't possible.
>
> If I migrated production from 2.0 to 2.1-rc1; my next install is
> 2.1-rc1 to 2.1-rc2 and not 2.0 to 2.1-rc2 at the database level. So I
> just run a test server until the real one is released.
>
> Dave, Elias and others work more at the bleeding edge; but that means
> their production servers tend to be on 2.1-pre-rc1 and that migration
> tends to kick off the release discussions. Unsure where Matt
> (JavaLobby) fits in on things release-wise.
I agree that's a problem with the milestone approach.
And I definitely agree that we need a more systematic approach to
making releases.
I don't have an answer, but maybe by sharing some information about
our development and deployment cycles we can find come common ground
here.
How often do customers and contributors like Javalobby, IBM and
others want to deploy new features?
At blogs.sun.com, we like to make changes in small, incremental, easy
to test and easy to document chunks. Allen and I make monthly
deployments like so:
a) Second to last Thursday of month - code freeze / deploy to
production
b) Last Thursday of month - deploy to production
Monthly works well for us (except for large features like group
blogging), but I've never thought that monthly Apache Roller release
make sense because other contributors don't have time to test every
month and I doubt customers want to upgrade on a monthly basis (or
the alternative, which is to fall behind).
- Dave
Re: VOTE: release Roller 2.1
Posted by Ted Husted <te...@gmail.com>.
> I presume that's every PMC vote that was on a public list? Rather than
> every PMC vote? Seems that it would largely be a history of release
> discussions.
It's even more important to log the *outcome* of the occaisonal
PMC-list votes because they are not public. The discussions are
sensitive, but the tally of the vote should not be. We want our
process to be as transparent as possible (since this is how we teach
developers to become committers).
> What are advantages are you finding of recording that? Again,
> nitpicking rather than being against the idea, seems better just to
> put in a link to the RESULT email in mail-archives. Only one I can
> think of is that it helps to maintain the dynamic charter of a project
> - as with all docs, the real charter gets set in stone and becomes
> untouchable.
Posting the tally in the STATUS file can serve as the RESULT email.
The change to the STATUS goes out over the list, so everyone sees it.
Now two goals are accomplished with one action. We have closure on the
vote, and we have a summary of the votes for future reference.
-Ted.
Re: VOTE: release Roller 2.1
Posted by Henri Yandell <fl...@gmail.com>.
On 2/24/06, Ted Husted <te...@gmail.com> wrote:
> On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
> > Personally, I think it gets silly to have to vote each time.
The danger of a bombastic statement; everyone includes that one line
in their replies and not the "however here's why we should" bit
afterwards :)
> Well, we really shouldn't cast a binding vote on a release until we
> put into production ourselves. ("Eat our own dog food.") Since this is
> a new roll, we have to unroll it, put it up, and run the binary
> through its paces. just to be certain all the bits are there.
Biggest problem I find with that is that it means following tests
aren't possible.
If I migrated production from 2.0 to 2.1-rc1; my next install is
2.1-rc1 to 2.1-rc2 and not 2.0 to 2.1-rc2 at the database level. So I
just run a test server until the real one is released.
Dave, Elias and others work more at the bleeding edge; but that means
their production servers tend to be on 2.1-pre-rc1 and that migration
tends to kick off the release discussions. Unsure where Matt
(JavaLobby) fits in on things release-wise.
> After doing that, voting is the least of it :)
>
> One way to streamline the process is to using numbered milestones
> rather than beta's and RCs. Under this scheme, this distribution would
> be Roller 2.1.4. We start by releasing it as an Alpha, and then decide
> to vote it up to a Beta or GA.
>
> The benefit is that we don't have to touch the distribution pr
> repository, even just to rename things. We can tag the repository once
> as _2_1_4 and roll that milestone once and for all. If it doesn't make
> the grade, we just go onto the next milestone. Right now, if we decide
> RC5 is ready for primetime, the same set of bits might have two names
> "RC5" and "2.1".
>
> Another benefit is that we can also downgrade a release. If we later
> find a security issue, we can bring out a new milestone and change the
> quality of "2.1.4" to beta.
>
> This is the scheme that Apache HTTP, Tomcat, Struts, and others use.
Downside is that it creates unreleased versions. It really should be a
4 digit version at that point, as what you're describing is:
<major>.<minor>.<build number>
as opposed to:
<major>.<minor>.<bugfix>
Said projects are overloading their bugfix and build numbers.
Not that I'm -1; the build-admin in me thinks it should go further,
the realist thinks it's unlikely I'll have time to do what I think
should be done anytime soon.
> Incidentally, it's a good practice to record every PMC vote in a
> STATUS file. Here's the one we use with iBATIS.
>
> * http://svn.apache.org/repos/asf/ibatis/trunk/STATUS.txt
I presume that's every PMC vote that was on a public list? Rather than
every PMC vote? Seems that it would largely be a history of release
discussions.
What are advantages are you finding of recording that? Again,
nitpicking rather than being against the idea, seems better just to
put in a link to the RESULT email in mail-archives. Only one I can
think of is that it helps to maintain the dynamic charter of a project
- as with all docs, the real charter gets set in stone and becomes
untouchable.
Again, apologies if a disjoint reply - need to sleep and catch a plane
hideously early tomorrow morning,
Hen
RE: VOTE: release Roller 2.1
Posted by "Noel J. Bergman" <no...@devtech.com>.
David,
Not yet ...
> +1 2/23 Henri Yandell
> +1 2/24 Ted Husted
Are the only two binding votes. You need three.
+1
Now you have three. :-)
--- Noel
Re: VOTE: release Roller 2.1
Posted by David M Johnson <Da...@Sun.COM>.
Roller 2.1 RC5 was made available on 2/23, since then:
+1 2/23 Henri Yandell
+1 2/24 Matt Raible
+1 2/24 Ted Husted
+1 2/24 Allen Gilliland
+0 2/24 Anil Gangolli
Sorry I did not follow up earlier. Looks like Roller 2.1 is cleared
for take off.
- Dave
On Feb 24, 2006, at 12:50 PM, Matt Raible wrote:
> +1
>
> On 2/24/06, Anil Gangolli <an...@busybuddha.org> wrote:
>> This was a local issue on my end.
>>
>> --a.
>>
>> Anil Gangolli wrote:
>>>
>>> Apologies again. I'm still +0. I built the latest off of trunk and
>>> installed on a freshly created db and ran into immediate problems
>>> trying to access the app which appears to have deployed
>>> successfully.
>>> Something is getting the request into our errors.jsp and eventually
>>> triggering an IllegalStateException in Tomcat. I'm on Windows XP,
>>> Tomcat 5.5.7 and Sun JDK 1.5.0_04. I now need to debug. This could
>>> well be a local issue of mine, so if you are confident, I have no
>>> objections, but I'm not ready to throw in a +1 myself.
>>> --a.
>>>
>>
>>
Re: VOTE: release Roller 2.1
Posted by Matt Raible <mr...@gmail.com>.
+1
On 2/24/06, Anil Gangolli <an...@busybuddha.org> wrote:
> This was a local issue on my end.
>
> --a.
>
> Anil Gangolli wrote:
> >
> > Apologies again. I'm still +0. I built the latest off of trunk and
> > installed on a freshly created db and ran into immediate problems
> > trying to access the app which appears to have deployed successfully.
> > Something is getting the request into our errors.jsp and eventually
> > triggering an IllegalStateException in Tomcat. I'm on Windows XP,
> > Tomcat 5.5.7 and Sun JDK 1.5.0_04. I now need to debug. This could
> > well be a local issue of mine, so if you are confident, I have no
> > objections, but I'm not ready to throw in a +1 myself.
> > --a.
> >
>
>
Re: VOTE: release Roller 2.1
Posted by Allen Gilliland <Al...@Sun.COM>.
I am +1
-- Allen
On Fri, 2006-02-24 at 08:22, Anil Gangolli wrote:
> Apologies again. I'm still +0. I built the latest off of trunk and
> installed on a freshly created db and ran into immediate problems trying
> to access the app which appears to have deployed successfully.
> Something is getting the request into our errors.jsp and eventually
> triggering an IllegalStateException in Tomcat. I'm on Windows XP,
> Tomcat 5.5.7 and Sun JDK 1.5.0_04. I now need to debug. This could
> well be a local issue of mine, so if you are confident, I have no
> objections, but I'm not ready to throw in a +1 myself.
>
> --a.
>
>
> Ted Husted wrote [excerpt; lots of stuff removed by me]:
> >
> > Right now, the
> > votes stands at
> >
> > Roller PPMC
> > * Dave J +1
> > * Henri Y +1
> >
> > Incubator PMC
> > * Henri Y +1
> > * Ted H +1
> >
>
Re: VOTE: release Roller 2.1
Posted by Anil Gangolli <an...@busybuddha.org>.
This was a local issue on my end.
--a.
Anil Gangolli wrote:
>
> Apologies again. I'm still +0. I built the latest off of trunk and
> installed on a freshly created db and ran into immediate problems
> trying to access the app which appears to have deployed successfully.
> Something is getting the request into our errors.jsp and eventually
> triggering an IllegalStateException in Tomcat. I'm on Windows XP,
> Tomcat 5.5.7 and Sun JDK 1.5.0_04. I now need to debug. This could
> well be a local issue of mine, so if you are confident, I have no
> objections, but I'm not ready to throw in a +1 myself.
> --a.
>
Re: VOTE: release Roller 2.1
Posted by Anil Gangolli <an...@busybuddha.org>.
Apologies again. I'm still +0. I built the latest off of trunk and
installed on a freshly created db and ran into immediate problems trying
to access the app which appears to have deployed successfully.
Something is getting the request into our errors.jsp and eventually
triggering an IllegalStateException in Tomcat. I'm on Windows XP,
Tomcat 5.5.7 and Sun JDK 1.5.0_04. I now need to debug. This could
well be a local issue of mine, so if you are confident, I have no
objections, but I'm not ready to throw in a +1 myself.
--a.
Ted Husted wrote [excerpt; lots of stuff removed by me]:
>
> Right now, the
> votes stands at
>
> Roller PPMC
> * Dave J +1
> * Henri Y +1
>
> Incubator PMC
> * Henri Y +1
> * Ted H +1
>
Re: VOTE: release Roller 2.1
Posted by Ted Husted <te...@gmail.com>.
On 2/23/06, David M Johnson <Da...@sun.com> wrote:
> Roller 2.1-incubating RC5 is available for your review.
> http://people.apache.org/~snoopdave/release_candidates/
>
> The only changes:
> - (Security) fix for ResourceServlet to disallow .. paths
> - Fix for ROL-1051 to allow spaces in uploaded file names
+1 (Bindong as a member of the Incubator PMC only)
> How many more votes do we need to release this puppy?
Well, as an ASF PMC, your first official action would be to adopt a
set of guidelines that outlined the decision making process. :)
In the meantime, the usual protocol to stamp something as an "ASF
release" is to hold a a majority vote, which means we need at least
three binding +1s (to establish quorum), and more binding +1s than
-1s.
In the normal course, the PMC member votes are binding (which means
they count). In pratice, binding also means that you are using the
release yourself, and that you pledge to support the release, with
patches and posts to the User list (at least to the extent your
volunteer schedule permits).
In this case, Roller is a podling and can't release software yet. But,
the Incubator PMC can. So, as a compromise, first the Podling PMC
votes in the usual way. And then the Incubator PMC also votes in the
usual way. After you get a valid majority vote of the PPMC here, you
should bring another vote up on general@incubator.
Henri's vote is binding as both a PPMC member and a Incubator PMC
member. Mine is only binding as a Incubator PMC member. Right now, the
votes stands at
Roller PPMC
* Dave J +1
* Henri Y +1
Incubator PMC
* Henri Y +1
* Ted H +1
The latest published Incubator policy on releases is here:
* http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
Of course, once Roller graduates, you can release ASF software on your
own authority, and need only the one majority vote.
The Apache Struts decision making guidelines are a typical example of
what Roller might adopt for itself.
* http://struts.apache.org/bylaws.html
-Ted.
RE: VOTE: release Roller 2.1
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Personally, I think it gets silly to have to vote each time.
See, for example, http://httpd.apache.org/dev/release.html under "Oops. We
found a problem." Every release gets voted upon. A change means a new
release.
--- Noel
Re: VOTE: release Roller 2.1
Posted by Ted Husted <te...@gmail.com>.
On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
> Personally, I think it gets silly to have to vote each time.
Well, we really shouldn't cast a binding vote on a release until we
put into production ourselves. ("Eat our own dog food.") Since this is
a new roll, we have to unroll it, put it up, and run the binary
through its paces. just to be certain all the bits are there.
After doing that, voting is the least of it :)
One way to streamline the process is to using numbered milestones
rather than beta's and RCs. Under this scheme, this distribution would
be Roller 2.1.4. We start by releasing it as an Alpha, and then decide
to vote it up to a Beta or GA.
The benefit is that we don't have to touch the distribution pr
repository, even just to rename things. We can tag the repository once
as _2_1_4 and roll that milestone once and for all. If it doesn't make
the grade, we just go onto the next milestone. Right now, if we decide
RC5 is ready for primetime, the same set of bits might have two names
"RC5" and "2.1".
Another benefit is that we can also downgrade a release. If we later
find a security issue, we can bring out a new milestone and change the
quality of "2.1.4" to beta.
This is the scheme that Apache HTTP, Tomcat, Struts, and others use.
Incidentally, it's a good practice to record every PMC vote in a
STATUS file. Here's the one we use with iBATIS.
* http://svn.apache.org/repos/asf/ibatis/trunk/STATUS.txt
-Ted..
Re: VOTE: release Roller 2.1
Posted by Henri Yandell <fl...@gmail.com>.
On 2/23/06, David M Johnson <Da...@sun.com> wrote:
> Roller 2.1-incubating RC5 is available for your review.
> http://people.apache.org/~snoopdave/release_candidates/
>
> The only changes:
> - (Security) fix for ResourceServlet to disallow .. paths
> - Fix for ROL-1051 to allow spaces in uploaded file names
Also the README.txt fix :)
Looked good to me, did a full test upgrade without problems.
> How many more votes do we need to release this puppy?
Personally, I think it gets silly to have to vote each time.
Effectively I was a -1 on the previous release (based on the
README.txt) and now am removing that -1. However, we also have to make
sure that people have checked your rc5; you could have screwed
something up due to the boredom of doing this for the 5th time.
So the usual rules make sense:
3 +1s over a 72 hour period.
You've got my +1. It's customary to not count your own. So 2 to go.
Hen
Re: VOTE: release Roller 2.1
Posted by David M Johnson <Da...@Sun.COM>.
Roller 2.1-incubating RC5 is available for your review.
http://people.apache.org/~snoopdave/release_candidates/
The only changes:
- (Security) fix for ResourceServlet to disallow .. paths
- Fix for ROL-1051 to allow spaces in uploaded file names
How many more votes do we need to release this puppy?
- Dave
On Feb 23, 2006, at 11:59 AM, Ted Husted wrote:
> On 2/23/06, David M Johnson <Da...@sun.com> wrote:
>> Try deleting your TOMCAT/work directory.
>
> <head-slap/>
>
> * Unpack RC4 to a folder in my home directory
> * Run through the installation guide and make the change to the
> security.xml
> * Copy over the roller-custom.properties from the 2.0 installation
> * Stop Tomcat
> + * Delete work directory
> * Back up the 2.0 database
> * Apply the database upgrade script
> * Moved the 2.0 roller folder elsewhere and replace it with the
> 2.1 version
> * Start Tomcat
>
> And it's alive!
>
> -Ted.
Re: VOTE: release Roller 2.1
Posted by Ted Husted <te...@gmail.com>.
On 2/23/06, David M Johnson <Da...@sun.com> wrote:
> Try deleting your TOMCAT/work directory.
<head-slap/>
* Unpack RC4 to a folder in my home directory
* Run through the installation guide and make the change to the security.xml
* Copy over the roller-custom.properties from the 2.0 installation
* Stop Tomcat
+ * Delete work directory
* Back up the 2.0 database
* Apply the database upgrade script
* Moved the 2.0 roller folder elsewhere and replace it with the 2.1 version
* Start Tomcat
And it's alive!
-Ted.
Re: VOTE: release Roller 2.1
Posted by David M Johnson <Da...@Sun.COM>.
Cool. Nice to PlanetStruts coming to life.
On Feb 23, 2006, at 9:44 AM, Ted Husted wrote:
> The Roller page started to display but stopped after the logo. The
> roller.log reports
>
> ERROR 2006-02-23 06:13:25,523 ApplicationDispatcher:invoke -
> Servlet.service() for servlet jsp threw exception
> java.lang.NoSuchMethodError:
> org.roller.presentation.RollerContext.getRollerContext(Ljavax/
> servlet/http/HttpServletRequest;)Lo
> rg/roller/presentation/RollerContext;
> at org.apache.jsp.theme.bannerStatus_jsp._jspService
> (org.apache.jsp.theme.bannerStatus_jsp:135)
Try deleting your TOMCAT/work directory.
> The catalina.out log seems nominal.
>
> It's being run under Tomcat 5.5.9
>
> I haven't done that much, and I could just try starting over, but I
> thought upgrading what I've done so far would be a way to judge the
> quality of the release. Since I'm on the Incubator PMC, my vote could
> be binding, once I get an installation in production!
>
> Here's something that confuses me about the RC4 distribution. There
> seem to be dbscripts in the distribution than we have in the
> repository.
>
> * https://svn.apache.org/repos/asf/incubator/roller/trunk/web/WEB-
> INF/dbscripts/
We switched to a new mechanism for generating database scripts. Look
in metadata/database for the source scripts. The scripts in web/WEB-
INF are the older scripts (ones that we no longer generate).
- Dave
Re: VOTE: release Roller 2.1
Posted by Ted Husted <te...@gmail.com>.
On 2/14/06, David M Johnson <Da...@sun.com> wrote:
> I've tried it on MySQL and PostgreSQL. Henri did a sanity check too.
> It's in production, docs are updated.
Do we have any notes for upgraders?
Since I finally got my PlanetStruts.org site running on Kattare last
night <happy-dance/>, the first thing I did this morning was break it
by trying to upgrade from 2.0.1 to 2.1-RC4.
So far, I
* Unpacked RC4 to a folder in my home directory
* Ran through the installation guide and made the change to the security.xml
* Copied over the roller-custom.properties from the 2.0 installation
* Stopped Tomcat
* Backed up the 2.0 database
* Applied the database upgrade script
* Moved the 2.0 roller folder elsewhere and replaced it with the 2.1 version
* Restarted Tomcat
The Roller page started to display but stopped after the logo. The
roller.log reports
ERROR 2006-02-23 06:13:25,523 ApplicationDispatcher:invoke -
Servlet.service() for servlet jsp threw exception
java.lang.NoSuchMethodError:
org.roller.presentation.RollerContext.getRollerContext(Ljavax/servlet/http/HttpServletRequest;)Lo
rg/roller/presentation/RollerContext;
at org.apache.jsp.theme.bannerStatus_jsp._jspService(org.apache.jsp.theme.bannerStatus_jsp:135)
The catalina.out log seems nominal.
It's being run under Tomcat 5.5.9
I haven't done that much, and I could just try starting over, but I
thought upgrading what I've done so far would be a way to judge the
quality of the release. Since I'm on the Incubator PMC, my vote could
be binding, once I get an installation in production!
Here's something that confuses me about the RC4 distribution. There
seem to be dbscripts in the distribution than we have in the
repository.
* https://svn.apache.org/repos/asf/incubator/roller/trunk/web/WEB-INF/dbscripts/
For example, I don't see the "mysql/200-to-210-migration.sql" in the
repository. I wanted to submit a patch for the end of the query so
that "create index we_status_idx on weblogentry(status);" comes last,
in case it was already done. (As it was for me.)
Am I looking in the wrong place?
-Ted.
Re: VOTE: release Roller 2.1
Posted by Matt Raible <mr...@gmail.com>.
+1
On 2/14/06, David M Johnson <Da...@sun.com> wrote:
> I've tried it on MySQL and PostgreSQL. Henri did a sanity check too.
> It's in production, docs are updated.
>
> Let's release it.
>
> - Dave
>
>
> On Feb 11, 2006, at 10:32 AM, David M Johnson wrote:
> > New release candidate with Acegi 1.0 RC2 thanks to Raible.
> > http://people.apache.org/~snoopdave/release_candidates/
> >
> > - Dave
> >
> >
> >
> > On Feb 10, 2006, at 2:24 PM, Matt Raible wrote:
> >> IMO, a security package should always be on the latest release.
> >> Should I check out from:
> >>
> >> https://svn.apache.org/repos/asf/incubator/roller/branches/
> >> roller_2.1/
> >>
> >> To make this change?
> >>
> >> Matt
> >>
> >> On 2/10/06, David M Johnson <Da...@sun.com> wrote:
> >>> I'm +0 on that Matt, unless there's a change it will break
> >>> something.
> >>>
> >>> If you want to do it and do a little testing, I'll re-spin the
> >>> build.
> >>>
> >>> - Dave
> >>>
> >>>
> >>> On Feb 10, 2006, at 1:59 PM, Matt Raible wrote:
> >>>
> >>>> Should we upgrade to Acegi 1.0 RC2 before the release?
> >>>>
> >>>> http://forum.springframework.org/showthread.php?t=22167
> >>>>
> >>>> On 2/10/06, David M Johnson <Da...@sun.com> wrote:
> >>>>>
> >>>>> On Feb 10, 2006, at 1:35 PM, Henri Yandell wrote:
> >>>>>> My usual release process worked happily this time.
> >>>>>> Are there release notes listing the new features/fixes?
> >>>>>
> >>>>> Yes, the CHANGES.txt file lists the issues and the what's new
> >>>>> page on
> >>>>> the wiki provides a more user-friendly write-up with screenshots.
> >>>>>
> >>>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller_2.1_WhatsNew
> >>>>>
> >>>>> Time for a final release vote?
> >>>>>
> >>>>> - Dave
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Hen
> >>>>>>
> >>>>>> On 2/9/06, David M Johnson <Da...@sun.com> wrote:
> >>>>>>>
> >>>>>>> Roller 2.1-incubating RC3 is available. The only change since
> >>>>>>> RC2 is
> >>>>>>> a fix for the PostgreSQL issue that Henri identified (see
> >>>>>>> below). I
> >>>>>>> did some testing with PostgreSQL and check the 2.0.1 to 2.1
> >>>>>>> upgrade
> >>>>>>> path.
> >>>>>>>
> >>>>>>> Release files are here:
> >>>>>>> http://people.apache.org/~snoopdave/release_candidates/
> >>>>>>>
> >>>>>>> Documentation drafts are here:
> >>>>>>> http://people.apache.org/~snoopdave/doc_drafts/
> >>>>>
> >>>>>
> >>>
> >>>
>
>
Re: VOTE: release Roller 2.1
Posted by Anil Gangolli <an...@busybuddha.org>.
+0 No objection to releasing it. Frankly, I haven't had a chance to
do a recent build and install myself due to work obligations. I
probably won't get a chance until the weekend if that. If we need a +1,
I feel obligated to at least do a build and install myself and that will
hold things up.
--a.
Allen Gilliland wrote:
> +1
>
> On Tue, 2006-02-14 at 11:30, David M Johnson wrote:
>
>> I've tried it on MySQL and PostgreSQL. Henri did a sanity check too.
>> It's in production, docs are updated.
>>
>> Let's release it.
>>
>> - Dave
>>
>>
>> On Feb 11, 2006, at 10:32 AM, David M Johnson wrote:
>>
>>> New release candidate with Acegi 1.0 RC2 thanks to Raible.
>>> http://people.apache.org/~snoopdave/release_candidates/
>>>
>>> - Dave
>>>
>>>
>>>
>>> On Feb 10, 2006, at 2:24 PM, Matt Raible wrote:
>>>
>>>> IMO, a security package should always be on the latest release.
>>>> Should I check out from:
>>>>
>>>> https://svn.apache.org/repos/asf/incubator/roller/branches/
>>>> roller_2.1/
>>>>
>>>> To make this change?
>>>>
>>>> Matt
>>>>
>>>> On 2/10/06, David M Johnson <Da...@sun.com> wrote:
>>>>
>>>>> I'm +0 on that Matt, unless there's a change it will break
>>>>> something.
>>>>>
>>>>> If you want to do it and do a little testing, I'll re-spin the
>>>>> build.
>>>>>
>>>>> - Dave
>>>>>
>>>>>
>>>>> On Feb 10, 2006, at 1:59 PM, Matt Raible wrote:
>>>>>
>>>>>
>>>>>> Should we upgrade to Acegi 1.0 RC2 before the release?
>>>>>>
>>>>>> http://forum.springframework.org/showthread.php?t=22167
>>>>>>
>>>>>> On 2/10/06, David M Johnson <Da...@sun.com> wrote:
>>>>>>
>>>>>>> On Feb 10, 2006, at 1:35 PM, Henri Yandell wrote:
>>>>>>>
>>>>>>>> My usual release process worked happily this time.
>>>>>>>> Are there release notes listing the new features/fixes?
>>>>>>>>
>>>>>>> Yes, the CHANGES.txt file lists the issues and the what's new
>>>>>>> page on
>>>>>>> the wiki provides a more user-friendly write-up with screenshots.
>>>>>>>
>>>>>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller_2.1_WhatsNew
>>>>>>>
>>>>>>> Time for a final release vote?
>>>>>>>
>>>>>>> - Dave
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hen
>>>>>>>>
>>>>>>>> On 2/9/06, David M Johnson <Da...@sun.com> wrote:
>>>>>>>>
>>>>>>>>> Roller 2.1-incubating RC3 is available. The only change since
>>>>>>>>> RC2 is
>>>>>>>>> a fix for the PostgreSQL issue that Henri identified (see
>>>>>>>>> below). I
>>>>>>>>> did some testing with PostgreSQL and check the 2.0.1 to 2.1
>>>>>>>>> upgrade
>>>>>>>>> path.
>>>>>>>>>
>>>>>>>>> Release files are here:
>>>>>>>>> http://people.apache.org/~snoopdave/release_candidates/
>>>>>>>>>
>>>>>>>>> Documentation drafts are here:
>>>>>>>>> http://people.apache.org/~snoopdave/doc_drafts/
>>>>>>>>>
>>>>>>>
>>>>>
>
>
>
Re: VOTE: release Roller 2.1
Posted by Allen Gilliland <Al...@Sun.COM>.
+1
On Tue, 2006-02-14 at 11:30, David M Johnson wrote:
> I've tried it on MySQL and PostgreSQL. Henri did a sanity check too.
> It's in production, docs are updated.
>
> Let's release it.
>
> - Dave
>
>
> On Feb 11, 2006, at 10:32 AM, David M Johnson wrote:
> > New release candidate with Acegi 1.0 RC2 thanks to Raible.
> > http://people.apache.org/~snoopdave/release_candidates/
> >
> > - Dave
> >
> >
> >
> > On Feb 10, 2006, at 2:24 PM, Matt Raible wrote:
> >> IMO, a security package should always be on the latest release.
> >> Should I check out from:
> >>
> >> https://svn.apache.org/repos/asf/incubator/roller/branches/
> >> roller_2.1/
> >>
> >> To make this change?
> >>
> >> Matt
> >>
> >> On 2/10/06, David M Johnson <Da...@sun.com> wrote:
> >>> I'm +0 on that Matt, unless there's a change it will break
> >>> something.
> >>>
> >>> If you want to do it and do a little testing, I'll re-spin the
> >>> build.
> >>>
> >>> - Dave
> >>>
> >>>
> >>> On Feb 10, 2006, at 1:59 PM, Matt Raible wrote:
> >>>
> >>>> Should we upgrade to Acegi 1.0 RC2 before the release?
> >>>>
> >>>> http://forum.springframework.org/showthread.php?t=22167
> >>>>
> >>>> On 2/10/06, David M Johnson <Da...@sun.com> wrote:
> >>>>>
> >>>>> On Feb 10, 2006, at 1:35 PM, Henri Yandell wrote:
> >>>>>> My usual release process worked happily this time.
> >>>>>> Are there release notes listing the new features/fixes?
> >>>>>
> >>>>> Yes, the CHANGES.txt file lists the issues and the what's new
> >>>>> page on
> >>>>> the wiki provides a more user-friendly write-up with screenshots.
> >>>>>
> >>>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller_2.1_WhatsNew
> >>>>>
> >>>>> Time for a final release vote?
> >>>>>
> >>>>> - Dave
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Hen
> >>>>>>
> >>>>>> On 2/9/06, David M Johnson <Da...@sun.com> wrote:
> >>>>>>>
> >>>>>>> Roller 2.1-incubating RC3 is available. The only change since
> >>>>>>> RC2 is
> >>>>>>> a fix for the PostgreSQL issue that Henri identified (see
> >>>>>>> below). I
> >>>>>>> did some testing with PostgreSQL and check the 2.0.1 to 2.1
> >>>>>>> upgrade
> >>>>>>> path.
> >>>>>>>
> >>>>>>> Release files are here:
> >>>>>>> http://people.apache.org/~snoopdave/release_candidates/
> >>>>>>>
> >>>>>>> Documentation drafts are here:
> >>>>>>> http://people.apache.org/~snoopdave/doc_drafts/
> >>>>>
> >>>>>
> >>>
> >>>
>
Re: VOTE: release Roller 2.1
Posted by Ted Husted <te...@gmail.com>.
On 2/21/06, David M Johnson <Da...@sun.com> wrote:
> Anil, Allen and I have been quietly discussing a security issue --
> I'll create a new RC once we have a resolution.
This may e what you meant, but a good place to discuss a rapid
response to security issues is the PMC list (or PPMC list). It is
important that all development discussions go through one of the
lists, and the occasional necessity for discussions like these is one
reason the PMC is not a public list.
-Ted.
Re: VOTE: release Roller 2.1
Posted by David M Johnson <Da...@Sun.COM>.
Thanks Henri, I'll fix that readme.
Anil, Allen and I have been quietly discussing a security issue --
I'll create a new RC once we have a resolution.
- Dave
On Feb 21, 2006, at 5:23 PM, Henri Yandell wrote:
>
>
> On Tue, 21 Feb 2006, Henri Yandell wrote:
>
>>
>>
>> On Tue, 21 Feb 2006, Noel J. Bergman wrote:
>>
>>>> We've got the votes to make the release
>>>> +1 Dave J
>>>> +1 Matt R
>>>> +1 Allen G
>>>> +0 Anil G
>>> None of which are Incubator PMC members. Did Henri not vote?
>>> Please post
>>> the results of this to general@incubator.apache.org, asking for
>>> the PMC to
>>> approve a release.
>>
>> Not yet. I'm in the middle of moving house this week, so time is
>> extremely limited. I've looked at a previous release and been
>> happy with things, but not looked at the latest rc to be able to
>> give my vote.
>>
>> Will try to eke a little time tonight to doublecheck the latest rc
>> files.
>
> Tonight will probably be full of packing, so pushed things out of
> the way and found a little time.
>
> Downloaded rc4; legal bits are fine. The README.txt for the tools
> zip is different to the other two, so that should be fixed before a
> release because it's missing some of the necessary "Roller includes
> Acegi" type statements.
>
> Install went fine. Running app appears to be working fine. I'm sure
> you will, but we should shout about the need to change security
> keys in each release announcement (blog, mailing list, whatever) we
> do. Too easy to just charge along and not do it (ie: I didn't :) ).
>
> So:
>
> +1, providing that README.txt gets fixed.
>
> Sorry for the delay, life is hellish at the this week. I'm looking
> forward to resting on Sunday.
>
> Hen
RE: VOTE: release Roller 2.1
Posted by Henri Yandell <ba...@apache.org>.
On Tue, 21 Feb 2006, Henri Yandell wrote:
>
>
> On Tue, 21 Feb 2006, Noel J. Bergman wrote:
>
>>> We've got the votes to make the release
>>
>>> +1 Dave J
>>> +1 Matt R
>>> +1 Allen G
>>> +0 Anil G
>>
>> None of which are Incubator PMC members. Did Henri not vote? Please post
>> the results of this to general@incubator.apache.org, asking for the PMC to
>> approve a release.
>
> Not yet. I'm in the middle of moving house this week, so time is extremely
> limited. I've looked at a previous release and been happy with things, but
> not looked at the latest rc to be able to give my vote.
>
> Will try to eke a little time tonight to doublecheck the latest rc files.
Tonight will probably be full of packing, so pushed things out of the way
and found a little time.
Downloaded rc4; legal bits are fine. The README.txt for the tools zip
is different to the other two, so that should be fixed before a release
because it's missing some of the necessary "Roller includes Acegi" type
statements.
Install went fine. Running app appears to be working fine. I'm sure you
will, but we should shout about the need to change security keys in each
release announcement (blog, mailing list, whatever) we do. Too easy to
just charge along and not do it (ie: I didn't :) ).
So:
+1, providing that README.txt gets fixed.
Sorry for the delay, life is hellish at the this week. I'm looking forward
to resting on Sunday.
Hen
RE: VOTE: release Roller 2.1
Posted by Henri Yandell <ba...@apache.org>.
On Tue, 21 Feb 2006, Noel J. Bergman wrote:
>> We've got the votes to make the release
>
>> +1 Dave J
>> +1 Matt R
>> +1 Allen G
>> +0 Anil G
>
> None of which are Incubator PMC members. Did Henri not vote? Please post
> the results of this to general@incubator.apache.org, asking for the PMC to
> approve a release.
Not yet. I'm in the middle of moving house this week, so time is extremely
limited. I've looked at a previous release and been happy with things, but
not looked at the latest rc to be able to give my vote.
Will try to eke a little time tonight to doublecheck the latest rc files.
Hen
RE: VOTE: release Roller 2.1
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We've got the votes to make the release
> +1 Dave J
> +1 Matt R
> +1 Allen G
> +0 Anil G
None of which are Incubator PMC members. Did Henri not vote? Please post
the results of this to general@incubator.apache.org, asking for the PMC to
approve a release.
--- Noel
Re: VOTE: release Roller 2.1
Posted by David M Johnson <Da...@Sun.COM>.
We've got the votes to make the release, so unless somebody raises an
objection I'll do it today.
+1 Dave J
+1 Matt R
+1 Allen G
+0 Anil G
- Dave
On Feb 14, 2006, at 2:30 PM, David M Johnson wrote:
> I've tried it on MySQL and PostgreSQL. Henri did a sanity check too.
> It's in production, docs are updated.
>
> Let's release it.
>
> - Dave
>
>
> On Feb 11, 2006, at 10:32 AM, David M Johnson wrote:
>> New release candidate with Acegi 1.0 RC2 thanks to Raible.
>> http://people.apache.org/~snoopdave/release_candidates/
>>
>> - Dave
>>
>>
>>
>> On Feb 10, 2006, at 2:24 PM, Matt Raible wrote:
>>> IMO, a security package should always be on the latest release.
>>> Should I check out from:
>>>
>>> https://svn.apache.org/repos/asf/incubator/roller/branches/
>>> roller_2.1/
>>>
>>> To make this change?
>>>
>>> Matt
>>>
>>> On 2/10/06, David M Johnson <Da...@sun.com> wrote:
>>>> I'm +0 on that Matt, unless there's a change it will break
>>>> something.
>>>>
>>>> If you want to do it and do a little testing, I'll re-spin the
>>>> build.
>>>>
>>>> - Dave
>>>>
>>>>
>>>> On Feb 10, 2006, at 1:59 PM, Matt Raible wrote:
>>>>
>>>>> Should we upgrade to Acegi 1.0 RC2 before the release?
>>>>>
>>>>> http://forum.springframework.org/showthread.php?t=22167
>>>>>
>>>>> On 2/10/06, David M Johnson <Da...@sun.com> wrote:
>>>>>>
>>>>>> On Feb 10, 2006, at 1:35 PM, Henri Yandell wrote:
>>>>>>> My usual release process worked happily this time.
>>>>>>> Are there release notes listing the new features/fixes?
>>>>>>
>>>>>> Yes, the CHANGES.txt file lists the issues and the what's new
>>>>>> page on
>>>>>> the wiki provides a more user-friendly write-up with screenshots.
>>>>>>
>>>>>> http://rollerweblogger.org/wiki/Wiki.jsp?page=Roller_2.1_WhatsNew
>>>>>>
>>>>>> Time for a final release vote?
>>>>>>
>>>>>> - Dave
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Hen
>>>>>>>
>>>>>>> On 2/9/06, David M Johnson <Da...@sun.com> wrote:
>>>>>>>>
>>>>>>>> Roller 2.1-incubating RC3 is available. The only change since
>>>>>>>> RC2 is
>>>>>>>> a fix for the PostgreSQL issue that Henri identified (see
>>>>>>>> below). I
>>>>>>>> did some testing with PostgreSQL and check the 2.0.1 to 2.1
>>>>>>>> upgrade
>>>>>>>> path.
>>>>>>>>
>>>>>>>> Release files are here:
>>>>>>>> http://people.apache.org/~snoopdave/release_candidates/
>>>>>>>>
>>>>>>>> Documentation drafts are here:
>>>>>>>> http://people.apache.org/~snoopdave/doc_drafts/
>>>>>>
>>>>>>
>>>>
>>>>
Roller 2.1 (RC3) testing (positive)
Posted by Sean Gilligan <se...@msgilligan.com>.
I've installed 2.1RC3 on both my Mac and on a production server for
testing by a limited number of users. So far, so good...
I updated the Platforms page on the Wiki with the configurations, I've
tested:
http://rollerweblogger.org/wiki/Wiki.jsp?page=Platforms
-- Sean
David M Johnson wrote:
> I've tried it on MySQL and PostgreSQL. Henri did a sanity check too.
> It's in production, docs are updated.
>
> Let's release it.
>
> - Dave
>