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 On Feb 3, 11:58 pm, Michael Bishop <[email protected]> wrote: > 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 > > > > > > > > On Thu, Feb 3, 2011 at 9:35 PM, rick c <[email protected]> wrote: > > > On Feb 3, 9:14 pm, Michael Bishop <[email protected]> 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) > > > > 2¢ > > > > ~miklb > > > > On Thu, Feb 3, 2011 at 8:18 PM, mikelietz <[email protected]> wrote: > > > > #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 > > > > > On Feb 2, 10:54 pm, Owen Winkler <[email protected]> wrote: > > > > > 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 > > > 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 > > > -- > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > >http://groups.google.com/group/habari-dev -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev
