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 On 4 February 2011 16:29, mikelietz <[email protected]> wrote: > 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 -- Michael C. Harris, School of CS&IT, RMIT University http://twofishcreative.com/michael/blog IRC: michaeltwofish #habari -- 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
