[VOTE] Feature freeze for 0.7

[Michael C. Harris]

Step one on the Release Checklist[1], freeze by merging trunk to
makaanga (the branch that bears fruit). This represents a freeze of
new features to focus bug fixing in preparation for a 0.7 release.
According to the Release Policy[1], as this is a Major Point Release,
we will freeze for at least a week.

This is the list of remaining bugs for 0.7:
https://trac.habariproject.org/habari/report/10

So let's VOTE for a freeze to start the release of 0.7.

[1] http://wiki.habariproject.org/en/Release_Checklist
[2] http://wiki.habariproject.org/en/Release_Policy

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
IRC: michaeltwofish #habari

[Owen Winkler]

On 1/31/2011 10:34 PM, Michael C. Harris wrote:
>
> So let's VOTE for a freeze to start the release of 0.7.

+1

[rick c]

+1

[Christopher Davis]

If I am back to active, +1, if I am still emeritus, my advice would be to move forward with the freeze.

Sent from my iPhone

> --
> To post to this group, send email to habar...@googlegroups.com
> To unsubscribe from this group, send email to habari-dev-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/habari-dev

[Colin]

+1

--
Colin Seymour
Blog: http://colinseymour.co.uk
Tech Stuff: http://lildude.co.uk
Barefoot Running: http://barefootrunner.co.uk
IRC: lildude #habari

[Scott Merrill]

On Mon, Jan 31, 2011 at 10:34 PM, Michael C. Harris
<mic...@twofishcreative.com> wrote:
> So let's VOTE for a freeze to start the release of 0.7.

+1

[Raman Ng (tinyau)]

+1

--
To post to this group, send email to habar...@googlegroups.com
To unsubscribe from this group, send email to habari-dev-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/habari-dev

--
Cheers,
Raman (aka 天佑 / tinyau)
Blog: http://blog.tinyau.net
Twitter: tinyau

[Matt Read]

+1

> --
> To post to this group, send email to habar...@googlegroups.com
> To unsubscribe from this group, send email to habari-dev-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/habari-dev
>

--
Matt Read
http://mattread.info
http://mattread.com

[Dave Perry]

On Jan 31, 7:34 pm, "Michael C. Harris" <mich...@twofishcreative.com>
wrote:

>
> So let's VOTE for a freeze to start the release of 0.7.

+1

community vote

[Michael Bishop]

-1. I genuinely believe at least one core plugin that utilizes the blocks should be bundled with core, which seems technically a "feature". All core themes now support blocks, and to further that being a focus of how plugins interact with themes, a public release should foster that. All good intentions aside, we don't know when the next release will be, and not providing the base elements for that, we would be stymying that evolution.

Once a core plugin is introduced that provides some basic blocks, I'm for a release and would be +1. If the cabal and community do not believe such plugin is an additional "feature" rather expounding on an existing feature, that's fine. I just think something should be included.

~miklb

[Owen Winkler]

On 2/1/2011 7:53 PM, Michael Bishop wrote:
> -1. I genuinely believe at least one core plugin that utilizes the
> blocks should be bundled with core, which seems technically a
> "feature". All core themes now support blocks, and to further that
> being a focus of how plugins interact with themes, a public release
> should foster that. All good intentions aside, we don't know when
> the next release will be, and not providing the base elements for
> that, we would be stymying that evolution.
>
> Once a core plugin is introduced that provides some basic blocks, I'm
> for a release and would be +1. If the cabal and community do not
> believe such plugin is an additional "feature" rather expounding on
> an existing feature, that's fine. I just think something should be
> included.

You make a good point.

Is there a plugin in extras already that would fulfill this need? I
think that it wouldn't take very long to take one of them and repack it
or augment it to the point where we could get you to +1 a freeze.

Owen

[Chris Meller]

On Feb 1, 2011, at 8:37 PM, Owen Winkler wrote:

> Is there a plugin in extras already that would fulfill this need?

We always planned on making dashboard modules into blocks in 0.8, what if we went ahead and did it, rather than coming up with another plugin to put in core?

[Chris J. Davis]

That sounds great to me.

+1 on that one.

[Michael Bishop]

I think even if the simpleblocks plugin was added that would be a good start.  If it was expanding to offer 3-4 basic blocks, that might be ideal - recent comments, recent posts, the search box.

[Michael Bishop]

I'm certainly not taking light the thought of adding another plugin to core, but if we want to move themes and theme development to using blocks/areas, we should provide the end users with some basic functionality IMO.

I'm not sure how making the dashboard widgets into blocks would provide for this.

~miklb

[Chris Meller]

On Feb 2, 2011, at 6:18 PM, Michael Bishop wrote:

> I'm not sure how making the dashboard widgets into blocks would provide for this.

I thought your intention was to provide an example for plugin developers to use to create their own blocks, which this would accomplish without the need for an additional core plugin.

I don't like the idea of adding a new plugin that provides a block to core just so we can have a plugin that provides a block, that's never been the Habari way. If the overwhelming majority of users aren't going to use it it's always been our policy that it should be left in -extras and I don't see any of the suggested options so far (aside from dashboard modules) being used by the vast majority of our install base.

That said, if we wanted to provide a plugin that really used blocks well (ie: got block wrappers and scopes right, used the block CSS classes assigned, etc.) and offered some common requests (monthly archives, recent posts, recent comments) I wouldn't be opposed to that.

[Owen Winkler]

On 2/2/2011 9:49 PM, Chris Meller wrote:
>
> I don't like the idea of adding a new plugin that provides a block to
> core just so we can have a plugin that provides a block, that's never
> been the Habari way. If the overwhelming majority of users aren't
> going to use it it's always been our policy that it should be left in
> -extras and I don't see any of the suggested options so far (aside
> from dashboard modules) being used by the vast majority of our
> install base.
>
> That said, if we wanted to provide a plugin that really used blocks
> well (ie: got block wrappers and scopes right, used the block CSS
> classes assigned, etc.) and offered some common requests (monthly
> archives, recent posts, recent comments) I wouldn't be opposed to
> that.

I think its a good idea to ultimately switch the dashboard over to using
blocks instead of modules. However, this would once again throw a
wrench into release.

At the same time, I think that core themes need to be augmented to make
better use of blocks if we're going to bother including block plugins in
core too. We should examine what features core themes provide currently
that could be replaced with blocks, and then change the themes to use
areas and include blocks to replace that functionality.

My question at this point is, what we should do now?:

1) Release as-is without a core block plugin and immediately revisit
this whole issue for a very fast 0.8 release.

2) Include a simple block plugin (literally "simpleblock", or
alternatively "commonblocks" would be my suggestions) for 0.7, and then
revisit the core themes for a fast 0.8 release.

3) Review core themes now, replace all their block-like functionality
with areas and a new core block plugin, which may push the 0.7 release
by a month or so.

4) Update core themes and produce a core block plugin as in 3, and also
replace the admin dashboard with a block-enabled theme page, which will
postpone 0.7 for an indeterminate amount of time.

My personal preference on this issue ranges from 1 through 3, with a
keener interest in option 1 corresponding to our ability to guarantee a
fast release date for 0.8 with just the additional features from option 4.

All that said, option 2 intuitively feels like a nice compromise for
including sample block functionality in core without delaying it too
much, which is why I think this suggestion is on the table.

I think we're way beyond the point of saying "a little longer after so
long already won't hurt". It *will* hurt to delay, and at this point
I'd rather roll out a better 0.8 in March and potentially have to rip
out a poor choice for 0.7's core block plugin than delay the 0.7 release
to April to add core dashboard blocks.

If we wanted to, we could add a single -extras block plugin to 0.7 now,
tag it off in makaanga, and start work on the changes from option 4 for
release in 0.8. Fix bugs in branch and release the damn 0.7 already.

Owen

[Michael Bishop]

I by no means intended to delay release by months (or weeks for that matter).  I was suggesting something like #2 in the first place.  I just think it would be very confusing to users to see these areas/blocks in all 3 default themes but not have any idea what the purpose is.  Having at least a simple text box that can be activated and dragged into the space at least gives them context, and that other plugins may also support this feature.

~miklb

[Chris Meller]

I'm not in favor of any of the options that involve "a very fast 0.8 release". That screws up our roadmap (no big deal) and puts a lot of extra pressure on us to throw together in a hurry something we should have probably done better the first time. If we can't throw it together in a reasonable amount of time for 0.7, why would we think we could if we released 0.7 and planned to do a 0.8 in the same amount of time?

Whatever we decide, it should be for 0.7, whether that means pushing the release out a little longer or not.

Lots of people were reluctant to embrace the Developer Previews because they're viewed as too buggy and for (duh) developers only, but no one's yet expressed any interest in a beta release, which would undoubtably draw a larger audience. I'm still of the opinion that a little longer will *not* hurt, but releasing a beta or two could definitely help if it's something you're concerned about.

We definitely should at least review the state of the core themes currently. Their implementation could certainly be improved in a 0.7.1 bugfix, but if we throw blocks out there and ask people to start building on them it'd be nice if we didn't break everything they just did when we "fix them for real" in 0.7.1 (or 0.8).

[Owen Winkler]

On 2/3/2011 12:16 AM, Chris Meller wrote:
> I'm not in favor of any of the options that involve "a very fast 0.8
> release". That screws up our roadmap (no big deal) and puts a lot of
> extra pressure on us to throw together in a hurry something we should
> have probably done better the first time. If we can't throw it
> together in a reasonable amount of time for 0.7, why would we think
> we could if we released 0.7 and planned to do a 0.8 in the same
> amount of time?

That's exactly the reason to do it in 0.8 instead, so that we can take
more time in 0.8 to concentrate on those issues. The idea also being
that we could use this as a trial run to get the quicker, more regular
releases everyone's been wishing we had. That we haven't had a
feature-updating release since April 2009 is somewhat damaging.

> We definitely should at least review the state of the core themes
> currently. Their implementation could certainly be improved in a
> 0.7.1 bugfix, but if we throw blocks out there and ask people to
> start building on them it'd be nice if we didn't break everything
> they just did when we "fix them for real" in 0.7.1 (or 0.8).

This is one of the options I presented, and I'm not against it. As I
said, I would be more in favor of my option 1 if we could commit to a
very fast follow-up of 0.8 with just the features we didn't add. If
we're not going to do that, then that's not the answer, and option 3
makes more sense. How long it delays release to make these changes is
debatable -- I was hoping for February of 0.7.

Also, I think that blocks are API-ready. We're not asking people to
build on something that they'll have to change completely in the next
version. Maybe I'm wrong about that if people haven't been testing the
block functionality in their themes the DP's. There are at least some
UI glitches that I would hope to clean up during the freeze. The point
I'm making here is that I think if we did a follow-up 0.7.1 or 0.8
release, it shouldn't break what we've asked them to build, but sure, it
would be nice to get confirmation of that by banging areas into the core
themes (and ditching K2 and adding a HiEngine theme to core).

Also note that blocks aren't specified explicitly on the roadmap, but
would presumably fall under 0.8 (themes and multisite) rather than 0.7
(taxonomy and content types).
(http://trac.habariproject.org/habari/roadmap) My opinion of the
roadmap is generally low simply because it's half-baked thoughts we've
tossed around on IRC and have ended up being put into Trac seemingly
just so the page exists. If we switched to the frequent regular release
schedule that everyone has been espousing, this roadmap wouldn't make
any sense.

Owen

[mikelietz]

#2. I'd lean more toward commonblocks, even though it is large,
because the blocks it contains are more useful right out of the box.

It needs a little work, though - the categories block belongs in a
categories plugin, not in it. It needs more commenting. Also, it
should probably include a block wrapper as well.

Let's get in touch with the original author(s) and see if it's OK to
include :P

[Michael Bishop]

The more this conversation goes, the more I regret voting -1.  My real goal was to just get _something_ into core that would give a new user the ability to understand what blocks are and not be confused. I do not want to see this go down a road of discussion until interest wanes and we do not release for another X months.

I think from what I've been shown, commonblocks is what I'm suggesting.  Can it be improved? I assume so. Can the UI for blocks be improved. Yes. I would whole heartedly revoke my -1 if commonblocks was included in core and we simply say we make that whole element a focus to improve in the .7 cycle and blocks/areas/scopes a focus in .8. (Or some relative compromise that wouldn't stop a release)

2¢

~miklb

[Michael C. Harris]

On 4 February 2011 13:14, Michael Bishop <mi...@miklb.com> wrote:
>
> I think from what I've been shown, commonblocks is what I'm suggesting.  Can
> it be improved? I assume so. Can the UI for blocks be improved. Yes. I would
> whole heartedly revoke my -1 if commonblocks was included in core and we
> simply say we make that whole element a focus to improve in the .7 cycle and
> blocks/areas/scopes a focus in .8. (Or some relative compromise that
> wouldn't stop a release)

+1

[rick c]

A variation on #2 would be my preference. It has been entirely too
long since we had a formal release.

I don't see adding a core plugin illustrating block creation as being
a problem, either commonblocks or a plugin with a less extensive set
of blocks covering three or four blocks that people generally use. All
three core themes can use blocks now. Adding styling to the css for
the blocks to one or the other shouldn't take too long. Plugin authors
would have a simple example of how to create blocks that are usable by
themers. Habari would have a built-in example of using blocks in a
theme. We would be able to release 0.7 this month. I don't think that
will lead to releasing a poorly executed 0.8 too quickly, as it would
give time to do a proper update, while still not having a huge delay
before 0.8 is ready.

Rick

[Michael Bishop]

Speaking with Mike Lietz tonight, a promising comprise: rip out the most basic functions of commonblocks for a "coreblocks" plugin in core(no support for asides, tag cloud), including a simpleblocks function that allows for filtered HTML/text, call it a day.

Still move forward with feature freeze, release ASAP?

Not sure an additional +1 is necessary, I'm confident that this element will make it to a .7 release and revoke my -1.

~miklb

--

[mikelietz]

I'd say that incorporating the plugin would not interfere with (my
limited understanding of) feature freeze.

I could start cutting it up tomorrow.

+1 for feature freeze so we can get this release tested and released.

mikelietz

[Michael C. Harris]

I've called a vote to include coreblocks in core[1]. Unless people
reverse their votes for a freeze in this thread, +1 votes for a freeze
will stand.

Current standing is 10 +1 (assuming Michael's +1 on the hopeful
inclusion of coreblocks.

[1] http://groups.google.com/group/habari-dev/browse_frm/thread/eb243347d8673400

--

[Michael C. Harris]

On 7 February 2011 22:10, Michael C. Harris <mic...@twofishcreative.com> wrote:
> I've called a vote to include coreblocks in core[1]. Unless people
> reverse their votes for a freeze in this thread, +1 votes for a freeze
> will stand.
>
> Current standing is 10 +1 (assuming Michael's +1 on the hopeful
> inclusion of coreblocks.

Passed, I'll organise makaanga today, hopefully.

[Michael C. Harris]

We've just done the feature freeze for the 0.7 release! Please try it out.

You can download nightly snapshots from
http://habariproject.org/dist/habari_makaanga.zip.

These are the tickets left, https://trac.habariproject.org/habari/report/10

In a minimum of one week, we'll start producing release candidates.