Re: [development] Drupal's CVS policies... including
I see both sides here. Compromise proposal. Include a section in the Project description that lets the developer place links to the supported third-party libraries hosted on external sites. These would be similar to the CVS / Documentation link fields that we have now. Data needed: - TItle - Link - Module Release Version(s) - Notes (optional) It might also be good to have a function that could check the user's installed library hash against the "sanctioned" version used by the module developer. This feature would be similar to (incorporated into) the update_status module. The proposed hook would simply be a function that let the module pass hook_hash($path, $filename). We might store the library hash values in the module.info file. If the hash check fails, update_status would flag the module as needeing an update. Seem like a plan? - Ken Rickard agentrickard
Ken Rickard wrote:
I see both sides here. Compromise proposal. [snip] While this sounds like a great solution for non [L]GPL'd code libraries I think it is an unnecessary limitation on module developers that use GPL'd code.
-- Michael Favia michael@favias.org tel. 512.585.5650 http://michael.favias.org
On 21 May 2007, at 10:36 PM, Ken Rickard wrote:
Include a section in the Project description that lets the developer place links to the supported third-party libraries hosted on external sites. These would be similar to the CVS / Documentation link fields that we have now.
how about you define it in the .info, and drupal.org processes it from there. This way we could also build a package building script that can automate making gzips containing the info.
Drupal.org already has growth issues. Adding yet another thing for it to do that could break and there are only 3-5 people who could fix it and hundreds who would scream about it being broken and post in every forum complaining and attacking isn't on my list of things that would be good. -sp From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of adrian rossouw Sent: Tuesday, May 22, 2007 3:16 AM To: development@drupal.org Subject: Re: [development] Drupal's CVS policies... including On 21 May 2007, at 10:36 PM, Ken Rickard wrote: Include a section in the Project description that lets the developer place links to the supported third-party libraries hosted on external sites. These would be similar to the CVS / Documentation link fields that we have now. how about you define it in the .info, and drupal.org processes it from there. This way we could also build a package building script that can automate making gzips containing the info.
Maybe there should be more drupal.org maintainers who can handle things like packaging scripts.
Karoly Negyesi wrote:
Maybe there should be more drupal.org maintainers who can handle things like packaging scripts.
I would like a pony, too.
You're not alone -- http://www.iwantapony.com/ and http://tinyurl.com/2dxw8b Cheers, Bill -- Bill Fitzgerald http://www.funnymonkey.com Tools for Teachers 503.897.7160
On Tuesday, 22. May 2007, Bill Fitzgerald wrote:
Karoly Negyesi wrote:
I would like a pony, too.
You're not alone --
http://sc.tri-bit.com/Pony Sorry, Jakob
On 5/22/07, Chris Johnson <cxjohnson@gmail.com> wrote:
Maybe there should be more drupal.org maintainers who can handle things like packaging scripts.
Despite the less-than-helpful follow ups to this comment.... ANYONE can handle packaging scripts. They just have to be *planned* and *written*. And, true, having them checked into a (private) CVS somewhere so other folks can work on them might be a good idea. dww has some great ideas floating around bundling / packaging for install profiles, and I'm hoping the folks that are seeing about raising money to fund this will be having some public posts soon (/me waves at Zacker). -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
My point was that if there is too much work to do useful things like the initial suggestion for drupal.org, maybe we should try to find more people to help out there. It's not an idle suggestion. But the entry bar seems rather high at the moment. So it has nothing to do with a pony, but rather with making it easier for people to actually help out.
-----Original Message-----
From: development-bounces@drupal.org [mailto:development- bounces@drupal.org] On Behalf Of Chris Johnson Sent: Wednesday, May 23, 2007 9:00 AM To: development@drupal.org Subject: Re: [development] Drupal's CVS policies... including
My point was that if there is too much work to do useful things like the initial suggestion for drupal.org, maybe we should try to find more people to help out there. It's not an idle suggestion. But the entry bar seems rather high at the moment.
So it has nothing to do with a pony, but rather with making it easier for people to actually help out.
The people who maintain the Infrastructure of Drupal.org are developers and maintainers of web sites too. They have jobs that pay for their types of use or hobbies that interest them strongly enough to invest the time to help. In addition to being _maintainers_ of the infrastructure of Drupal.org that so many use every day, they are also _users_ of Drupal.org. So what I see so many arguments as reading is, someone else should do work to make it easier for _them_ to do some random interest thing. I have a longer post on the word _user_ on my site. It's so often used as the hammer to justify something yet so often undefined and to narrow of definition. If those people who are actually doing the work tell you that it's more complicated than you realize, you should consider that when formulating your vision. So far no one has addressed even remotely the very few complications pointed out with foreign code. They just throw out the 'license gives me rights' justification which is not terribly relevant to long term sustainable support or dismiss away the complications. The bar is high because people are dismissing the amount of work it takes to do something. Respectfully, Steven Peck http://www.blkmtn.org/what-is-a-drupal-user
The bar is high because people are dismissing the amount of work it takes to do something.
Respectfully, Steven Peck
I allow as to how what Steven Peck has just written could be more generally accurate than the specific cases I was thinking about -- and that it would be educational for some segment of the users of drupal.org who want something changed. But my comments had to do more with a specific suggestion for a not too unreasonably difficult to create feature, but for which people like Derek (dww) have far too little time, as they are already stretched thin. Let's take me as an example of someone who might implement such a feature, but who finds the path to doing so unnecessarily difficult. I'm willing to help out the infrastructure team. But i don't have large amounts of time to do so. But my "vision" is not distorted by thinking something is easier than it really is. If "those who actually do the work" tell me it's more complicated than I realize, I first consider the source -- i.e. what my opinion of that person's skill and knowledge are. I'm always willing to be educated and learn more. Let me point out, however, that I've done a lot more "complicated" implementing of all kinds of software and systems than most. Doing lots of work does not necessarily make one wise. I generally don't claim something to be simple if it is not; if anything, I tend to err on the conservative side. But this is a tangent. Back to the main point -- if we want to get more work done, we need more people doing the work. To get more people doing the work, we need to make it more obvious as to how people can do it, what needs to be done, and more willing to let people take on smaller slices of the work. In general, most of the work on Drupal gets done not by the most qualified, but by the people with the most time or most motivation (probably true of a great deal of things in life, actually). But simply because someone doesn't have the ability to commit huge amounts of time does not mean they aren't technically capable. Let's try to find ways to let those people contribute, too. Equally respectfully, Chris Johnson
participants (9)
-
adrian rossouw -
Bill Fitzgerald -
Boris Mann -
Chris Johnson -
Jakob Petsovits -
Karoly Negyesi -
Ken Rickard -
Michael Favia -
Steven Peck