+1 :)
On 26/08/2008, at 1:57 PM, John Casey wrote:
> I'm okay with making the current RC a first milestone toward 2.1.0,
> if we know what the endgame for 2.1.0 is. How do we know when we're
> done? Also, can we focus on having a 2.1.0 GA out in the next two or
> so months? It's been since April that we had a release, and that one
> had some pretty big problems that are keeping people away. I don't
> want to set the bar too high on these releases, especially when
> there's so little development time to go around. IMO, if we can
> start out with *some* success, we can build off of that and keep
> things moving. Personally, I'd much rather see 3-4 new features
> every three months in a GA release, instead of 12-16 new features in
> a year. It also gives us a much better chance of making our releases
> stable and predictable.
>
> As far as the performance problems on the 2.1.x branch, that's on my
> todo list for tomorrow, to merge in my changes from the RC branch to
> get the 2.1.x branch back up to snuff. Sorry that's been slow coming
> (no pun intended) but I'm starting to get caught up WRT SVN syncing
> now, so hopefully tomorrow will be the day.
>
> As far as supporting 3 codelines, my own thought is to keep 2.0.x on
> life support long enough to get a GA release of 2.1 out (and maybe a
> little longer, I don't know what's really feasible here), but not to
> spend too much time spit-shining 2.0.x anymore. If we can find a way
> to fix the most broken features without bringing down the rest of
> that house of cards, then that'll be good enough for me.
>
> Brett, Christian, I think JIRA voting is a great way to "weight" the
> survey results with the users' priorities, but I want to make sure
> we have an alternate mechanism that allows us to talk about features
> - which will be sets of JIRA issues, in reality - outside of an
> issue-tracking context. We need to use Confluence for this sort of
> work, writing proposals that can be reviewed and voted on, IMO. I
> was just thinking that Dennis' use of the survey system was a great
> idea, and could be a perfect fit for this sort of planning.
>
> -john
--
Brett Porter
brett@...
http://blogs.exist.com/bporter/---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@...
For additional commands, e-mail:
dev-help@...