On Wed, May 6, 2009 at 5:19 PM, Derek Wright wrote:
> On May 6, 2009, at 1:36 PM, Margie Roswell wrote:
>> I'm not getting it. The issues block disappears when you're actually in
>> the issue queue.
> If you already drilled down to the issue queue, why do you still need the
> summary blocks?
I wo
On May 7, 2009, at 2:37 PM, Domenic Santangelo wrote:
As to the issue queue re-placement, the fact that someone asked on the
dev list, and the first reply didn't notice it either should be a hint
as to the UX issues caused by putting that block there.
IMHO, the problem is the design of bluebe
On May 7, 2009, at 11:46 AM, As If Productions wrote:
Meanwhile, if you want to talk about wasted space, listing the
"Latest 5 Issues" is useless to anyone except the module maintainers.
Blocks like this are a key part of Mark + Leisa's design for the new
site. The principle (as I underst
Think twice.
> http://drupal.org/project/paging - last commit from Gurpartap: 2 weeks
> ago. Next maintainer (Darren): 48 weeks ago. Last D5 recommended
> release was in January.
...tells you that Paging (a rather small module) had no activity in the past
2 weeks, and there is 1 maintainer only.
Domenic Santangelo wrote:
On Thu, May 7, 2009 at 2:11 PM, andrew morton
wrote:
On Thu, May 7, 2009 at 1:01 PM, Michael Favia wrote:
Derek Wright wrote:
However, the point of the maintainers block isn't necessarily to provide
links people click on, but text people read. And data about how ma
On Thu, May 7, 2009 at 2:11 PM, andrew morton
wrote:
> On Thu, May 7, 2009 at 1:01 PM, Michael Favia wrote:
>> Derek Wright wrote:
>>>
>>> However, the point of the maintainers block isn't necessarily to provide
>>> links people click on, but text people read. And data about how many
>>> maintai
On Thu, May 7, 2009 at 1:01 PM, Michael Favia wrote:
> Derek Wright wrote:
>>
>> However, the point of the maintainers block isn't necessarily to provide
>> links people click on, but text people read. And data about how many
>> maintainers, who they are, and how active they are is important info
On Thu, 7 May 2009 11:27:25 -0400
Moshe Weitzman wrote:
> > Having a structured head implies having a renderer/theme
> > function (am I right?)
>
> yes. but core provides some basic ones like #markup so we may not
> need anything new.
?
> a $page['head'] array sounds good to me.
$page = array
On Thu, May 7, 2009 at 2:54 PM, Earl Miles wrote:
> Earnie Boyd wrote:
>
>> Quoting James Gilliland :
>>
>>
>>> Drupal Law 0: If you need to do something, make an API for it first.
>>>
>>>
>> print t('Hello World');
>>
>> Oh wait I should create an API to do it first.
>>
>> function print_hello_w
Earnie Boyd wrote:
The block can have the benefit of goading the maintainer into
maintaining it. Prestige points for a small issue queue. One problem
I see is the "Oldest issue" instead of the "Oldest bug report" and
"Oldest support request". The age of a task or a feature request
shouldn't
Earnie Boyd wrote:
Quoting James Gilliland :
Drupal Law 0: If you need to do something, make an API for it first.
print t('Hello World');
Oh wait I should create an API to do it first.
function print_hello_world() {
print t('Hello World');
}
That's not an API, that's abstraction. Kind
As If Productions wrote:
Meanwhile, if you want to talk about wasted space, listing the "Latest 5
Issues" is useless to anyone except the module maintainers.
It's not that useful to me, either, though maybe for really small modules.
Ivan Sergio Borgonovo wrote:
At least in my experience a "what if they were 3" makes a huge
difference to avoid 2 just a special case of 1.
But anyway how could you plan or even think an API could be
useful knowing just 2 use-case?
But then... when you cut and paste more than once... you need an
At 08:28 AM 5/7/2009, Margie wrote:
Most people already have all sorts of anxiety about "I'm not as good as
that." I think the maintainers list could tend to reinforce the star power
of a few people, but that's a whole psychological question.
I agree with Margie on this. We recently had a disc
On Thu, 7 May 2009 09:25:53 -0600
Greg Knaddison wrote:
> On Thu, May 7, 2009 at 9:12 AM, Ivan Sergio Borgonovo
> wrote:
> > On Thu, 7 May 2009 09:23:48 -0500
> > Jeff Eaton wrote:
> >
> >> Crell's Law: If an API must be use-case-optimized, make it
> >> swappable & tailor the default for cheap
Quoting James Gilliland :
Drupal Law 0: If you need to do something, make an API for it first.
print t('Hello World');
Oh wait I should create an API to do it first.
function print_hello_world() {
print t('Hello World');
}
print_hello_world();
Oh wait I should create an API to do it fi
Quoting Michael Favia :
Derek Wright wrote:
However, the point of the maintainers block isn't necessarily to
provide links people click on, but text people read. And data
about how many maintainers, who they are, and how active they are
is important information for assessing the health of
That's dopry's first law...
On Thu, May 7, 2009 at 12:40 PM, James Gilliland wrote:
> On Thu, May 7, 2009 at 9:23 AM, Jeff Eaton wrote:
>
>> Crell's Law: If an API must be use-case-optimized, make it swappable &
>> tailor the default for cheap shared hosting. High-end sites can swap.
>>
>> Eat
Derek Wright wrote:
However, the point of the maintainers block isn't necessarily to
provide links people click on, but text people read. And data about
how many maintainers, who they are, and how active they are is
important information for assessing the health of a project.
Project statistic
On Thu, May 7, 2009 at 9:23 AM, Jeff Eaton wrote:
> Crell's Law: If an API must be use-case-optimized, make it swappable &
> tailor the default for cheap shared hosting. High-end sites can swap.
>
> Eaton's Corollary: If an API is swappable, write two implementations. APIs
> with one test case ar
On May 7, 2009, at 4:58 AM, Margie Roswell wrote:
The maintainers list is useful! It's good. But why give links that
FEW people will click on a higher listing than links that MANY
people will click on? It doesn't make sense.
That's a fine question, but it should ultimately be directed to
On Thu, May 7, 2009 at 11:25 AM, Greg Knaddison wrote:
> On Thu, May 7, 2009 at 9:12 AM, Ivan Sergio Borgonovo
> wrote:
> > On Thu, 7 May 2009 09:23:48 -0500
> > Jeff Eaton wrote:
> >
> >> Crell's Law: If an API must be use-case-optimized, make it
> >> swappable & tailor the default for cheap sh
> We have to temper the ideal with reality. We have several swappable
> systems in Drupal (database, mail sending, caching, others?) and as
> far as I know only one of them has multiple backends in core
> (databases). We are able to have multiple backend for databases, but
> it takes a lot of eff
On May 7, 2009, at 10:25 AM, Greg Knaddison wrote:
We have to temper the ideal with reality. We have several swappable
systems in Drupal (database, mail sending, caching, others?) and as
far as I know only one of them has multiple backends in core
(databases). We are able to have multiple bac
> Having a structured head implies having a renderer/theme function (am
> I right?)
yes. but core provides some basic ones like #markup so we may not need
anything new.
a $page['head'] array sounds good to me.
On Thu, May 7, 2009 at 9:12 AM, Ivan Sergio Borgonovo
wrote:
> On Thu, 7 May 2009 09:23:48 -0500
> Jeff Eaton wrote:
>
>> Crell's Law: If an API must be use-case-optimized, make it
>> swappable & tailor the default for cheap shared hosting. High-end
>> sites can swap.
>
>> Eaton's Corollary: If a
On Tue, 5 May 2009 11:41:47 -0500
Jeff Eaton wrote:
> On May 5, 2009, at 11:19 AM, Ivan Sergio Borgonovo wrote:
>
> > So there is no way to edit in a structured way head.
> In Drupal 7, I'd really love to see the globally alterable $page
> array become a place where this stuff lives. hook_page_
On Thu, 7 May 2009 09:23:48 -0500
Jeff Eaton wrote:
> Crell's Law: If an API must be use-case-optimized, make it
> swappable & tailor the default for cheap shared hosting. High-end
> sites can swap.
> Eaton's Corollary: If an API is swappable, write two
> implementations. APIs with one test case
On Thu, May 7, 2009 at 9:23 AM, Jeff Eaton wrote:
> Crell's Law: If an API must be use-case-optimized, make it swappable &
> tailor the default for cheap shared hosting. High-end sites can swap.
>
> Eaton's Corollary: If an API is swappable, write two implementations. APIs
> with one test case are
Crell's Law: If an API must be use-case-optimized, make it swappable &
tailor the default for cheap shared hosting. High-end sites can swap.
Eaton's Corollary: If an API is swappable, write two implementations.
APIs with one test case are rarely flexible enough for the second.
--eaton
I think in this case (of maintainers list being shown above the actual list
of issues), that that's a developer-centric goal more than a user-centric
goal.
Most people already have all sorts of anxiety about "I'm not as good as
that." I think the maintainers list could tend to reinforce the star p
Hi guys,
you find a outstanding presentation about the usage of datatypes,
storage engines, replication, query optimization from the
ZendCon2008
http://devzone.zend.com/article/4497
includes slides and audio.
Best Thomas Zahreddin
With more Code than you can handle, don't ask for more co
On Thu, May 7, 2009 at 3:07 AM, Margie Roswell wrote:
> I decided that I like it. Though I think it would be better if the
> Maintainers block were listed below the other two issue blocks. The Issues
> block is the far more important one for most users, and shouldn't risk being
> too far "below th
33 matches
Mail list logo
