- Development - lists.drupal.org

Anyone seen vauxia?
by Dan Robinson 01 Jun '06

01 Jun '06

We've been working with her send, premium and guestpass modules. We've found a bunch of bugs, submitted some patches and have tried pinging her to see if she's still maintaining these. Anyone seen her around? Thanks, Dan

5 8

tango icons no longer "allowed" in contribs.
by Bèr Kessels 01 Jun '06

01 Jun '06

Hello fellow developers and themers. First of all, I hope we can all hold our breath, and fingers and not start another thread out of this. You might not agree, but leave that for other times and places. Thank you ;) Tango icons use Creative commons (CC) as their licence. Whether or not CC is compatible, transformable, integratable or anything else is not the point here. The result is that you cannot use tango icons in contribs, as was our policy for a while. If you have a project using tango (or any CC icons or work, in fact) make sure you either replace them with your own work or one of the various nice GPL icons around. Make sure you do this an all branches (releases). If you find modules that still use tango icons, or any other incompatible licence, please contact the owner, or leave an issue in the queue for that project. Dries -and the other contrib maintainers- want to keep contribs Pure GPL. This is for simpicity. « We're not lawyers, so let's try not to make up our own rules, or mix licenses without knowing what we are doing. » -- Dries With regards, Bèr

1 0

RE: [infrastructure] Re: [development] Drupal 4.5 unsupported
by Steven Peck 01 Jun '06

01 Jun '06

> -----Original Message----- > From: development-bounces(a)drupal.org > [mailto:development-bounces@drupal.org] On Behalf Of Larry Garfield > Sent: Tuesday, May 30, 2006 10:48 AM > To: development(a)drupal.org > Subject: Re: [infrastructure] Re: [development] Drupal 4.5 unsupported > > On Tue, May 30, 2006 8:59 am, Khalid B said: > > On 5/30/06, blogdiva(a)culturekitchen.com > <blogdiva(a)culturekitchen.com> > > wrote: > >> That's an awesome question. I'd like to hear from > developers and the > >> people in the marketing team. The question is at the core of what I > >> feel Drupal is overlooking at the moment --code freezes. > > > > Code freezes do happen. Once we have a release, its API > does not change > > (may be a tiny bit occasionally, but not normally). > > > > What we do not freeze is APIs between releases. How can we > move forward > > from 4.7 to 6.6 with the API remaining the same? Where would the new > > stuff go? Are you advocating we keep APIs forever? > > > > Read my comment here on where the energy should be focussed > (migration > > tools, > > transitional releases, and compatibility layers). > > > > http://baheyeldin.com/node/617 > > Honestly, I think part of the issue with the "stable API" > question is that > Drupal uses version numbers differently from many projects. > The de facto > standard for version numbers for most projects is > Major.Minor.Bug / x.y.z. > > Z increases only fix bugs. > Y increases add features, but don't break backward > compatibility with 3rd > party code. > X increases, all bets are off. > > Witness, for instance, KDE, which has evolved and improved > dramatically in > the 3.y.z cycle, but code for 3.0.0 still (generally) works > in 3.5.1. For > the upcoming 4.0, howver, there are no "sacred cows" and > everything will > need to be updated. > > For Drupal, Y increases, all bets are off. We technically > don't have Y > releases, just Z and X, but we use both of the first two > numbers for the X > releases. That throws a lot of people off. It actually > surprised me a > great deal, although fortunately it didn't affect my plans > significantly. > > Whatever else we do, we should probably make that clearer > right up front. > It's not inherently a bad development model, just an > unconventional one > that needs to be made clearer. > > --Larry Garfield > How much more clear can I make this? http://drupal.org/handbook/version-info The alias is recent but it has been at the top level of the handbook now for about a year. Should we link it in the Project download page for Drupal? There are other projects that use different from KDE versioning release scheme's as well. Drupal's been consistent for the 3 years I've used it with it's versioning information and method. The versioning scheme has not changed at all. -sp

12 19

GPL policy: request for clarification
by Nedjo Rogers 01 Jun '06

01 Jun '06

The GPL appears to allow us to combine GPL and "compatible" code in a single GPL-licensed package. Can we include such code in drupal.org CVS? This is a pressing issue because there is considerable interest in using external GPL-compatible but non-GPL Javascript libraries (Prototype, jQuery), at least in contrib and possibly as candidates for core. Our CVS policy states "All code must be licensed under GNU/GPL" (contributions README.txt). The practice has been to interpret this as meaning that open source libraries with "MIT" or similar licenses may not be included in Drupal CVS. However, the Free Software Project has designated a number of licenses, including the "MIT" license, as "compatible" with the GPL, because they impose no restrictions that conflict with the GPL, see http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses. The GPL FAQ specifically states, http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean, that the GPL permits you to "combine code released under the other [compatible] license with code released under the GNU GPL in one larger program" privided that "such a combination ... is released under the GNU GPL". In other words, apparently, we can GPL the combination of GPL code and code with compatible licenses. So, it appears, we should be free to include "MIT" and other compatible-licensed code in our CVS and releases, provided we make it clear we are thus GPL-ing the combination. So, can we go ahead and put such combinations in CVS? Can we consider/propose them for core?

9 11

Re: [Drupal feature] Personal Contact SELECTED BY DEFAULT, even MANDATED
by Steve Dondley 01 Jun '06

01 Jun '06

I helped write a patch that already addresses this and it has been committed to the head: http://drupal.org/node/41352 On 6/1/06, pwolanin <development(a)drupal.org> wrote: > Issue status update for > http://drupal.org/node/66648 > Post a follow up: > http://drupal.org/project/comments/add/66648 > > Project: Drupal > Version: cvs > Component: contact.module > Category: feature requests > Priority: normal > Assigned to: Anonymous > Reported by: iandickson > Updated by: pwolanin > Status: active > > Yes, I agree. I think people joining a site are already opting in, so > it makes more sense to have this on by default. I'd almost categorize > this as a bug and push for inclusion in 4.7.2... > > > > > pwolanin > > > > Previous comments: > ------------------------------------------------------------------------ > > Thu, 01 Jun 2006 06:55:01 +0000 : iandickson > > In community projects it is often the case that members are not really > up for reading everything carefully. Upshot - they miss the box and > wonder why no one contacts them..., so I'd like to be able to set > Personal Contact ON by Default. (User can disable if they wish). > > > I'd also like an option to MANDATE it so it can't be disabled by user, > (People get annoyed if they can't contact a provocative poster). > > > Note - I went looking for this and found threads in which people who > needed this function had posted mod hacks to do it. Which I won't use - > too hairy - but shows how important it is. > > > General Comment - this is a Usability Issue - a key role of Admin > should be to ensure that member defaults are designed to minimise the > work that work that members need to do, so any check box that it is > expected peoiple will tick, should be defaultable ticked. > > > > > -- Dondley Communications http://www.dondleycommunications.com Communicate or Die: American Labor Unions and the Internet http://www.communicateordie.com

1 0

RE: [infrastructure] Re: [development] Drupal 4.5 unsupported
by Steven Peck 01 Jun '06

01 Jun '06

Added link to the project download page. http://drupal.org/project/Drupal+project The page originated from forum questions and all updates have been designed to refine and clarify the message. Further refinement or clarification is welcome. -sp > -----Original Message----- > From: development-bounces(a)drupal.org > [mailto:development-bounces@drupal.org] On Behalf Of Jonathan Lambert > Sent: Wednesday, May 31, 2006 4:30 PM > To: development(a)drupal.org > Subject: Re: [infrastructure] Re: [development] Drupal 4.5 unsupported > > > > > On 5/31/06 4:22 PM, "Khalid B" <kb(a)2bits.com> wrote: > > > So, how do we make it more easy to find/communicate or use a scheme > > that has a better chance of being understood? > > I think that's the million dollar point. > > I think this is the page on the site that references the subject: > http://drupal.org/handbook/version-info > > Is that documentation clean enough? If not, let me know how > you would like > it updated (seriously, folks, weigh in here, this is the > actual resolution > to this issue) and I will accumulate the results and get it > updated nicely. > > Coo? > > Jonathan

1 0

Drupal 4.5 unsupported
by Gerhard Killesreiter 31 May '06

31 May '06

Hi there! As of the last security release Drupal 4.5 is de facto unsupported. Contributed modules and themes are already no longer repackaged (don't know who changed that and when). I plan to remove the existing tarballs from files/projects so that they are no longer for download. Please voice your objections soon (and you better have very good reasons ;). Cheers, Gerhard

24 67

Improving drupal.js
by Nedjo Rogers 31 May '06

31 May '06

There's a lot of interest among the AJAX/Javascript group at http://groups.drupal.org/ajax-developers in putting some energy into improving the good Javascript beginnings we made in 4.7. Ideas include: introducing a Drupal namespace, refining some of our implementations, improving event handling, registering behaviors, isolating effects so they're accessible to effects libraries. There's interest as well in the potential of adopting one of the leading js development libraries (jQuery http://jquery.com/, Prototype http://prototype.conio.net/, etc.) as a development base. To this end, we're considering a drupal.js Drupal Enhancement Proposal, http://groups.drupal.org/node/603, and have started a working group at http://groups.drupal.org/drupal-js. timcn has begun to sketch in a proposed approach at http://cvs.drupal.org/viewcvs/drupal/contributions/modules/drupal.js/. I also posted a note to the jQuery mailing list about the possibility of jQuery being available under GPL or LGPL and got an encouraging response from jQuery author John Resig, see the thread "Would you consider making jQuery available under the GPL?" at http://jquery.com/discuss/2006-May/, in particular http://jquery.com/discuss/2006-May/001414/. If you'd like to contribute, please wade in with your comments and suggestions on the draft DEP, http://groups.drupal.org/node/603, and join the drupal-js group. Cheers, Nedjo

1 0

social network module
by Albert Wong 30 May '06

30 May '06

Greetings - I don't generally post here, but I read your comment re: social networking and I didn't want it to fall through the cracks.. . so I just wanted to give you a little bit of (hopefully helpful) guidance, regarding which direction to take, in case you're looking for some. On dev / your 5.26.06 posting / it seemed as if you were trying to decide whether to go for developing either... (1) "social networking" capabilities, a la orkut -- for drupal end users -- (2) or network analysis -- for drupal admins. Personally, my vote is for polishing up the social network capabilies of drupal for end users, a la orkut. [In fact, (1) might be a prerequisite for a successful deployment of (2). Reasoning: without adequate SN capabilities, there might be little network infrastructure to analyze.] :-) Anyhow, that's my current interest and bias and in case you've elect to go that route, I've done some investigating of what drupal already has on offer, so could hopefully give you a bit of a head start. There's definitely stuff you can build on, although there's also quite a ways to go. The principal social networking tool available in Drupal, imho, currently, is Drupal's "buddylist.module" which is supposed to be the rough equivalent of the common "friends" function you find on all the popular SN sites, orkut, myspace, etc. The module is well written and well documented. So, I would consider building off of it. However, this module has two significant drawbacks, (1) First, under its current cvs setup, *buddy relations are not symmetrical*. That is, if A is buddy of B, it does not imply that B is buddy of A. That is, buddylist treats friendship relationships as *directional*, rather than *mutual*. This creates some confusing scenarios -- for example -- under the current setup, you can have the following situation: "Jack is buddies with Jill, but Jack is not buddies of Jill, where as Jill is not buddies with Jack, but Jill is buddies of Jack" [Did you get that? ;-)] Although there might be some very unusual special cases where a unidirectional friend relationship might be useful, this is clearly, generally, not the common semantic case. (2) Second, currently, *buddy relationships may be unilaterally determined*. That is, A can unilaterally decide to declare that he is buddies with B, regardless of B's consent. That is, for example: "Quasimodo, the crazy stalker, can decide *on his own* that he's buddies with Esmerelda, even though Esmerelda has placed a restraining order on Quasimodo." ;-) Again, this unilateral capability is not standard in the common usage of buddy relationships as a social networking tool - and for good reason, I believe. Generally, buddy relationships are mutually and *consensually* determined. There are other more superficial issues regarding the polishing of buddylist, but these two issues strike at the core of it, and should be tackled first, imho. A solution to these two issues above has been posted as a patch here http://drupal.org/node/11892 -- it is patch that I wrote -- with help from RobRoy -- and functions without a hitch on my site, www.ithou.org . This patch replaces the "asymmetric" / "non-consensual" framework with one that is "symmetric" and "consensual". It is still awaiting review. I imagine that you could assist in that polishing and review process and as part of your SoC contribution, you could help move Drupal and buddylist into a more solid social networking platform. Should this be of interest to you as part of your SoC project, please do not hesitate to contact me. Regards, Albert albert [at] ithou.org

3 2

RE: [infrastructure] Re: [development] Drupal 4.5 unsupported
by Boerland, Bert 30 May '06

30 May '06

-----Original Message----- From: development-bounces(a)drupal.org > I reread Jonathans posts twice, becuase this problem really interests me (I > studied operational engineering: Maintaining and upgrading large technical > facilities such as powerplants) I work in a huge datacenter where we manage k's of hosts for customers, so this interest me as well. As a general rule of thumb, we have the following policy. We upgrade: 1) if the /customer/ wants it and hence pays for it (new functionality / external resons) 2) if /operations/ wants it because it is cheaper to maintain a box (operational costs /internal reasons) 3) if /customer/operations/ want it due to securtity risks (preventing imago/repair costs) (note: 3 includes lifecycle management aka EOL as is the case with 4.5 right now) These are imho the only valid reasons to upgrade, oss or proprietary code. The fact that you dont have any license costs for oss doesnt change this, neither the fact that bazaar style coding gives you faster updates with more functionality. These are just parameters within these rules. Anyone is free to upgrade or not. The only thing that we have to do is to state what the criteria are for supporting older versions. And if you think you need support for older versions, anyone is free to start coding for 4.1 or buy support. I wouldnt call it smart though or futureproof.

1 0