new features in D6 core?

Are new features still being considered for Drupal 6 core?

I've coded a new "Set language" option for the bulk node update form at
admin/content/node.  I filed an issue report with a patch and screenshot, at
http://drupal.org/node/609262 .

But from my reading of other issue reports, it seems that the 6.x API is
considered to be frozen at this point.  If I understand correctly, that would
rule out including my patch, which adds some hooks to the locale module.  Can
someone please tell me if this is true, or even better, point me to a definitive
statement?

Thanks,
Andrew.

[info-1714]

Andrew,

The short answer is: No.

New features are not added after the code freeze, which is usually months
before a stable version is released. Code freeze for Drupal 7 is already
behind us. If you want to contribute your code, try to make it into a
contrib module.

Marc


On Fri, 23 Oct 2009 02:54:34 -0400, Andrew Schulman
<andrex@...> wrote:

> Are new features still being considered for Drupal 6 core?
>
> I've coded a new "Set language" option for the bulk node update form at
> admin/content/node.  I filed an issue report with a patch and screenshot,
> at
> http://drupal.org/node/609262 .
>
> But from my reading of other issue reports, it seems that the 6.x API is
> considered to be frozen at this point.  If I understand correctly, that
> would
> rule out including my patch, which adds some hooks to the locale module.
> Can
> someone please tell me if this is true, or even better, point me to a
> definitive
> statement?
>
> Thanks,
> Andrew.

On Friday 23 October 2009 1:54:34 am Andrew Schulman wrote:

> Are new features still being considered for Drupal 6 core?
>
> I've coded a new "Set language" option for the bulk node update form at
> admin/content/node.  I filed an issue report with a patch and screenshot,
> at http://drupal.org/node/609262 .
>
> But from my reading of other issue reports, it seems that the 6.x API is
> considered to be frozen at this point.  If I understand correctly, that
> would rule out including my patch, which adds some hooks to the locale
> module.  Can someone please tell me if this is true, or even better, point
> me to a definitive statement?
>
> Thanks,
> Andrew.

Yes this is true.  Once a Drupal version is released it accepts only bug and
security fixes while new features are added to the next major version.  Drupal
6 is the current stable release and therefore is not taking new features.

Drupal 7 actually just went into feature freeze this month, so is not taking
new features either while we focus on performance optimization, bug fixes, and
UX improvements until it is released, *probably* sometime early next year but
that depends on how good a job of we do of tracking down and squishing bugs.  
(Help is always appreciated!)  Once Drupal 7 is released, it will be the
stable version and not accept anything but bug and security fixes while
development begins on Drupal 8, which will accept all kinds of wacky new stuff
during its development cycle until its feature freeze, and the cycle repeats.

--
Larry Garfield
larry@...

[Cameron Eagans]

You could always build it out as a contrib module, though. It sounds pretty useful.
-----
Cameron Eagans
Owner, Black Storms Studios, LLC
http://www.blackstormsstudios.com

On Fri, Oct 23, 2009 at 1:12 AM, Larry Garfield <larry@...> wrote:

On Friday 23 October 2009 1:54:34 am Andrew Schulman wrote:
> Are new features still being considered for Drupal 6 core?
>
> I've coded a new "Set language" option for the bulk node update form at
> admin/content/node.  I filed an issue report with a patch and screenshot,
> at http://drupal.org/node/609262 .
>
> But from my reading of other issue reports, it seems that the 6.x API is
> considered to be frozen at this point.  If I understand correctly, that
> would rule out including my patch, which adds some hooks to the locale
> module.  Can someone please tell me if this is true, or even better, point
> me to a definitive statement?
>
> Thanks,
> Andrew.

Yes this is true.  Once a Drupal version is released it accepts only bug and
security fixes while new features are added to the next major version.  Drupal
6 is the current stable release and therefore is not taking new features.

Drupal 7 actually just went into feature freeze this month, so is not taking
new features either while we focus on performance optimization, bug fixes, and
UX improvements until it is released, *probably* sometime early next year but
that depends on how good a job of we do of tracking down and squishing bugs.
(Help is always appreciated!)  Once Drupal 7 is released, it will be the
stable version and not accept anything but bug and security fixes while
development begins on Drupal 8, which will accept all kinds of wacky new stuff
during its development cycle until its feature freeze, and the cycle repeats.

--
Larry Garfield
larry@...

> You could always build it out as a contrib module, though. It sounds pretty
> useful.

Thanks.  Unfortunately, when I tried that the CVS masters said that my proposed
module was "too simple" to justify granting me an account
(http://drupal.org/node/606962).

It's true, the feature is quite simple.  It really should just be integrated
into core.  But that obviously isn't possible for D6 or 7, which is helpful to
know.  I'm looking now for another module that could easily integrate the
feature, but if I don't find one I'll go back to the CVS masters and try again.

Thanks,
Andrew.

[Gerhard Killesreiter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Schulman schrieb:
>> You could always build it out as a contrib module, though. It sounds pretty
>> useful.
>
> Thanks.  Unfortunately, when I tried that the CVS masters said that my proposed
> module was "too simple" to justify granting me an account
> (http://drupal.org/node/606962).
>


This has been rectified.


Cheers,
        Gerhard

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrhkroACgkQfg6TFvELooRo6QCghNFkg/vbqPieZv1ONG2yWWwc
tYwAoLwXit3oQNLCYs03OQIbWj7r6URR
=XjHq
-----END PGP SIGNATURE-----

[Jeff Greenberg-3]

The logic in that seems flawed for many reasons.


Gerhard Killesreiter wrote:

> Thanks. Unfortunately, when I tried that the CVS masters said that my
> proposed
>> module was "too simple" to justify granting me an account
>>
>>    

[Earnie]

Quoting Andrew Schulman <andrex@...>:

>> You could always build it out as a contrib module, though. It sounds pretty
>> useful.
>
> Thanks.  Unfortunately, when I tried that the CVS masters said that  
> my proposed
> module was "too simple" to justify granting me an account
> (http://drupal.org/node/606962).
>
> It's true, the feature is quite simple.  It really should just be integrated
> into core.  But that obviously isn't possible for D6 or 7, which is  
> helpful to
> know.  I'm looking now for another module that could easily integrate the
> feature, but if I don't find one I'll go back to the CVS masters and  
> try again.
>

Looks like Kiam's decision was overridden and you now have CVS access.

--
Earnie
-- http://r-feed.com/           -- http://for-my-kids.com/
-- http://www.4offer.biz/       -- http://give-me-an-offer.com/

[Andrew Berry-3]

On 2009-10-23, at 7:21 AM, Andrew Schulman wrote:

> It's true, the feature is quite simple.  It really should just be  
> integrated
> into core.

I wonder if this feature would be best implemented as an action in VBO  
for D6:

http://drupal.org/project/views_bulk_operations

> >> You could always build it out as a contrib module, though. It sounds pretty
> >> useful.
> >
> > Thanks.  Unfortunately, when I tried that the CVS masters said that my proposed
> > module was "too simple" to justify granting me an account
> > (http://drupal.org/node/606962).
> >
>
>
> This has been rectified.
>
>
> Cheers,
> Gerhard

Thank you.
Andrew.

> > It's true, the feature is quite simple.  It really should just be  
> > integrated
> > into core.
>
> I wonder if this feature would be best implemented as an action in VBO  
> for D6:
>
> http://drupal.org/project/views_bulk_operations

It does seem to sort of fit there.  The problem though, is that then it
would depend on both views and vbo, which are fairly heavyweight modules.

I've looked around for other admin or multilanguage-related modules where
this feature might fit, but I haven't found any good candidates yet.  I
think there were one or two but again they seemed pretty heavyweight for
someone who wanted just this small feature.

Another option to make the module more worthwhile on its own, would be to
expand it to include other bulk node operations.  That would be fine, but I
don't happen to have any others at present.  Anyone know of any other
candidates?

Any thoughts about the best name for a module that currently just provides
a language bulk set operation?

* Language bulk set:  narrowest and currently most accurate.

* Language bulk operations:  room to expand.

* Node bulk operations:  lots of room for future growth, but a bit
grandiose for a module that currently only provides one operation.

Thanks,
Andrew.

[Bill Fitzgerald]

A quick observation here, and feel free to flame this mercilessly [1].

As I see it, the purpose of the review of application should be to
determine whether the applicant will comply with the d.o requirements
regarding licensing, etc -- it should *not* be to judge the merits of
the proposed module.

In this case, and in others I have seen, people have been unnecessarily
hassled during the CVS application process.

As a community, we are shooting ourselves in the foot if we hassle/turn
away developers, especially when we are turning them away for invalid
reasons.

If Andrew hadn't posted to the Dev list, his good idea would not have
had the opportunity to make it into the community. I wonder how many
other good ideas have been lost for the exact same reason.

Cheers,

Bill

[1]. Yes, I know that there are a small number of people triaging a
large number of CVS applications.

Andrew Schulman wrote:

>>>> You could always build it out as a contrib module, though. It sounds pretty
>>>> useful.
>>> Thanks.  Unfortunately, when I tried that the CVS masters said that my proposed
>>> module was "too simple" to justify granting me an account
>>> (http://drupal.org/node/606962).
>>>
>>
>> This has been rectified.
>>
>>
>> Cheers,
>> Gerhard
>
> Thank you.
> Andrew.
>
>

[davereid]

This is going to be one of those discussions we always have like backwards compatibility between major versions.

Yes, the main point is there are way too few people helping review applications. I do agree that whoever is reviewing always needs to be compassionate and be able to justly explain his or her decision, which currently doesn't always happen.

Just because someone can follow CVS licensing doesn't mean I should approve a better_views module or a better_cck module. This is also our opportunity to prevent duplicate or unnecessary modules, the latter being a fine line. A small, trivial 10-line customization that runs hook_form_alter() should be approved?

This needs effort from all sides:
1. CVS admins/reviewers to always be helpful and make sound decisions since it is usually the applicant's beginning attempt at contributing code.
2. The existing community (the 8 non-CVs admins) to actually care about the new members and help with application review. This only happens where there are problems. If people were looking at the CVS applications and chime in and say "Wow, I've always needed this. This would make a great module," that would make the decision easier for the admins and we probably wouldn't be having this discussion.
3. CVS applicants always submitting thoughtful and thorough application. I think Andrew falls into this case, but there are a lot that don't. Makes the job harder for both 1 and 2.

See http://drupal.org/cvs-application/requirements and

Dave Reid
dave@...

On Fri, Oct 23, 2009 at 4:50 PM, Bill Fitzgerald <bill@...> wrote:

A quick observation here, and feel free to flame this mercilessly [1].

As I see it, the purpose of the review of application should be to determine whether the applicant will comply with the d.o requirements regarding licensing, etc -- it should *not* be to judge the merits of the proposed module.

In this case, and in others I have seen, people have been unnecessarily hassled during the CVS application process.

As a community, we are shooting ourselves in the foot if we hassle/turn away developers, especially when we are turning them away for invalid reasons.

If Andrew hadn't posted to the Dev list, his good idea would not have had the opportunity to make it into the community. I wonder how many other good ideas have been lost for the exact same reason.

Cheers,

Bill

[1]. Yes, I know that there are a small number of people triaging a large number of CVS applications.

Andrew Schulman wrote:

You could always build it out as a contrib module, though. It sounds pretty
useful.

Thanks.  Unfortunately, when I tried that the CVS masters said that my proposed
module was "too simple" to justify granting me an account
(http://drupal.org/node/606962).

This has been rectified.


Cheers,
       Gerhard

Thank you.
Andrew.

[Kevin Reynen]

Adding to the potential flame fodder...

We've actually encouraged non-developers who will likely never commit anything to CVS to request CVS accounts so we can leverage Project on D.O. as a project management tool.   While anyone can take ownership of an issue themselves, the list of people someone with CVS access can assign an issue/task/feature to is limited to the other users with CVS access to the module or theme.

We've just started scratching the surface of this functionality, but every person from the Open Media Project who requested a CVS account was approved. 

- Kevin Reynen

On Fri, Oct 23, 2009 at 4:35 PM, Dave Reid <dave@...> wrote:

This is going to be one of those discussions we always have like backwards compatibility between major versions.

Yes, the main point is there are way too few people helping review applications. I do agree that whoever is reviewing always needs to be compassionate and be able to justly explain his or her decision, which currently doesn't always happen.

Just because someone can follow CVS licensing doesn't mean I should approve a better_views module or a better_cck module. This is also our opportunity to prevent duplicate or unnecessary modules, the latter being a fine line. A small, trivial 10-line customization that runs hook_form_alter() should be approved?

This needs effort from all sides:
1. CVS admins/reviewers to always be helpful and make sound decisions since it is usually the applicant's beginning attempt at contributing code.
2. The existing community (the 8 non-CVs admins) to actually care about the new members and help with application review. This only happens where there are problems. If people were looking at the CVS applications and chime in and say "Wow, I've always needed this. This would make a great module," that would make the decision easier for the admins and we probably wouldn't be having this discussion.
3. CVS applicants always submitting thoughtful and thorough application. I think Andrew falls into this case, but there are a lot that don't. Makes the job harder for both 1 and 2.

See http://drupal.org/cvs-application/requirements and

Dave Reid
dave@...

On Fri, Oct 23, 2009 at 4:50 PM, Bill Fitzgerald <bill@...> wrote:

A quick observation here, and feel free to flame this mercilessly [1].

As I see it, the purpose of the review of application should be to determine whether the applicant will comply with the d.o requirements regarding licensing, etc -- it should *not* be to judge the merits of the proposed module.

In this case, and in others I have seen, people have been unnecessarily hassled during the CVS application process.

As a community, we are shooting ourselves in the foot if we hassle/turn away developers, especially when we are turning them away for invalid reasons.

If Andrew hadn't posted to the Dev list, his good idea would not have had the opportunity to make it into the community. I wonder how many other good ideas have been lost for the exact same reason.

Cheers,

Bill

[1]. Yes, I know that there are a small number of people triaging a large number of CVS applications.

Andrew Schulman wrote:

You could always build it out as a contrib module, though. It sounds pretty
useful.

Thanks.  Unfortunately, when I tried that the CVS masters said that my proposed
module was "too simple" to justify granting me an account
(http://drupal.org/node/606962).

This has been rectified.


Cheers,
       Gerhard

Thank you.
Andrew.

> A quick observation here, and feel free to flame this mercilessly [1].
>
> As I see it, the purpose of the review of application should be to
> determine whether the applicant will comply with the d.o requirements
> regarding licensing, etc -- it should *not* be to judge the merits of
> the proposed module.
>
> In this case, and in others I have seen, people have been unnecessarily
> hassled during the CVS application process.
>
> As a community, we are shooting ourselves in the foot if we hassle/turn
> away developers, especially when we are turning them away for invalid
> reasons.
>
> If Andrew hadn't posted to the Dev list, his good idea would not have
> had the opportunity to make it into the community. I wonder how many
> other good ideas have been lost for the exact same reason.

Well, here's my view.

Yes, I'm a new contributor to Drupal.  I read the new maintainer documents and
followed the advice there, but I didn't expect to get it all right the first
time.

I was disappointed and a little frustrated that my CVS account was denied,
mainly because it wasn't clear to me how else I was supposed to get my code out
to the community.  But the reason for the denial, although very shortly stated,
has merit.  We don't want a bunch of trivial modules cluttering up Drupal-- I
get that.

So I asked on the forums and filed a patch against 6.x core, but I didn't get an
answer in either place.  But those are noisy places, so I just figured I needed
to keep trying.  Once I wrote to this list, I got an answer right away and a
positive result.

So in short I'd say:

- The reason for denying my account was valid, but it should have considered, or
suggested, what the alternative might be for me to make my code available.

- A new developer should expect to need some patience in engaging the community
about their contribution.  If they're serious about contributing, they'll stick
to it.

It did occur to me, that a person who already had a CVS account could have
contributed the same module at their discretion, while I couldn't because I
didn't have an account yet.  So it seems that CVS approval was being used as a
proxy for module approval.  But I also agree that new developers should pass a
threshold test for making a sound contribution.

Anyway, the community came through in the end.  I wouldn't worry about it too
much.

Andrew.

[Jeff Greenberg-3]

I don't know that I'd agree with the reason for denying it being valid.
I'd say that with regards to the question posed earlier, it makes sense
to approve a module that has 1 line of code, if that code is going to be
use to the community. Denying the community the functionality, or
telling several (dozens, hundreds, thousands?) of people to go code it
themselves because it's trivial to do, but not trivial enough to add to
core, doesn't seem like the right approach. If it's useful, a module
makes sense.

[davereid]

Again, how can one person know that one line is useful to the entire community if other people don't speak up about it? It requires the community to be involved in the process and not reacting to just when there are problems.

Dave Reid
dave@...

On Fri, Oct 23, 2009 at 8:31 PM, Jeff Greenberg <jeff@...> wrote:

I don't know that I'd agree with the reason for denying it being valid. I'd say that with regards to the question posed earlier, it makes sense to approve a module that has 1 line of code, if that code is going to be use to the community. Denying the community the functionality, or telling several (dozens, hundreds, thousands?) of people to go code it themselves because it's trivial to do, but not trivial enough to add to core, doesn't seem like the right approach. If it's useful, a module makes sense.

[Jeff Greenberg-3]

Dave Reid wrote:

> Again, how can one person know that one line is useful to the entire
> community if other people don't speak up about it? It requires the
> community to be involved in the process and not reacting to just when
> there are problems.
>
Right, then if one person isn't qualified to know whether it would be
useful to the community, let the community decide by downloading it or not.

> > It's true, the feature is quite simple.  It really should just be  
> > integrated
> > into core.
>
> I wonder if this feature would be best implemented as an action in VBO  
> for D6:
>
> http://drupal.org/project/views_bulk_operations

VBO works on a different form than admin/content/node, but both forms have bulk
update operations, and Dave Reid points out that this feature could go into both
places.  I'll offer it as a patch for VBO as soon as I can get to it.

[Ashraf Amayreh]

I suddenly got this (perhaps silly) idea of only allowing a CVS owner to create one project and require approval by posting to the DEV list when wishing to create another project rather than making this open for all CVS owners. This would definitely help with the repetition problem and module boom.

Posting to the DEV list should at least give other module developers and people interested the opportunity to object to, agree or suggest alternatives to the proposed module rather than suddenly finding a useless/repetitive module springing up here and there because the developer didn't know another one existed.

Suggestions? Flames? Thoughts?

AA

On Sat, Oct 24, 2009 at 4:35 AM, Jeff Greenberg <jeff@...> wrote:

Dave Reid wrote:

Again, how can one person know that one line is useful to the entire community if other people don't speak up about it? It requires the community to be involved in the process and not reacting to just when there are problems.

Right, then if one person isn't qualified to know whether it would be useful to the community, let the community decide by downloading it or not.

--
Ashraf Amayreh
http://aamayreh.org