What does everyone think of hard feature freeze on September 1st? That gives us approximately 4 months of development time. A good time for a release after that would be one to two months later, but in reality it would be "when it is ready." That is only 4 months and I am seeing a lot of ways we want to break everything; this will probably be 4.8 and not 5.0. I don't think making roadmaps for contributions we can't control is too productive, but if we did have a roadmap, we would have a clear idea of what we can call 5.0. -- Neil Drumm http://delocalizedham.com/
On Apr 29, 2006, at 6:04 PM, Neil Drumm wrote:
What does everyone think of hard feature freeze on September 1st? That gives us approximately 4 months of development time.
A good time for a release after that would be one to two months later, but in reality it would be "when it is ready."
That is only 4 months and I am seeing a lot of ways we want to break everything; this will probably be 4.8 and not 5.0. I don't think making roadmaps for contributions we can't control is too productive, but if we did have a roadmap, we would have a clear idea of what we can call 5.0.
Here is what you can commit on your roadmap. 1) Installer in core from CivicSpace. a) Installer for Drupal core. b) Forms for configuring individual modules including writing file, creating directories, and installing module tables into separate databases. c) Profiles and selection during installation. 2) Moving capabilities in the administration module into core to allow for configurable administration pages, subpages, and matching configuration of administration menu's. Works in 4.6, works in 4.7. Need to get in core. 3) File caching patch. Done for 4.6. Done for 4.7. Working to get it in 4.8. More to come. Cheers, Kieran CivicSpace
-- Neil Drumm http://delocalizedham.com/
Now that this has been brought up, I'd like to put forward my thoughts or idea. * split out 4.8 and 5.0 * hard freeze date for 4.8 * roadmap for 5.0 Split 4.8 and 5.0: We all have Great Plans for 4.8. Those Great Plans are all of the magnitude of Fapi. Stick two such overhauls in one release, and we **know** its not going to be possible to release anytime soon. That is a pity for all the small changes (ajax, freetagging, etc) that people want, but are unavailable, because we cannot release 4.8 because all the Big Plans are holding it up. 4.8 for all the usual stuff. (pragmatism) 5.0 for the big re-hauls, gigantic plans and huge patches. (freedom) Two possible problems, though: People are too busy with one (4.8) to put full attention on another (5.0). And patches will often need to go into two branches: more work, more maintenance. I think both are small problems compared to the amount of freedom (5.0) and pragmatism (4.8) we gain trough this; There are enough people out there anyway, but 5.0 will need no/less testing until its somewhere stable. So it needs far less people. Patches that need to be maintained in pairs: I don't think that will be the case often. After all: what good will "a small theming improvement on aggregator output" patch do in 5.0, if in 5.0 the "big theme overhaul to make all output structural, like fAPI" patch is already in? Patches will be so different that those that apply to both branches have to maintained separate anyway. Hard freeze date for 4.8.
What does everyone think of hard feature freeze on September 1st? That gives us approximately 4 months of development time. Neil proposes Sept. 1st. to be a hard freeze date. If we don't have to worry about huge patches, that FUBARed core, this is doable. If we are going to implement all the wild plans, in a single branch (when we do not split 4.8 and 5.0) this is not going to be possible. Esp small bugfixes and features will become unmaintainable, because core changed completely every month or so :). And off course, having two or three Huge projects breaking everyhing requires an unknown amount of time to stabilise (fAPI is *still* not really stable). No roadmap is needed, for 4.8. It can simply be a 'What is in by Sept 1st, is in. The rest is not. Fullstop".
Roadmap for 5.0 Because the 5.0 does not aim at a release date, but at a set of goals (world domination ;) ), I think it will be a good idea to make a roadmap for this. Obviously we'd need a gatekeeper to maintain that roadmap, to provide it from growing unworkable big. If the release for 5.0 will be aimed around a year, a year and a half from now, that roadmap can still be big enought to put all our big ideas in. This, BTW is how a lot of projects work towards big releases. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
You have listed some good points about two parallel tracks for development. Here are some drawback. 1. Will be expensive (not only on development, but in terms of community resources, think documentation, support, ...etc. as well as the obvious fragmentation of the development effort). 2. Confusing (communication to prospective and present users, as well as the development community). 3. Do we have to merge repositories at one point (4.8 branch to 5.0)? If not, then it is effectively maintenance on 4.7, with (possible/questionable) patch ports to 5.0. Having said that, point 1 may not be constrained by the development resource issue that it used to be, since we now have very capable and proven branch maintainers and commiters (Gerhard and Neil). In other words, this is not as much of a problem as it has been in the past where it was mainly Dries doing it all. Side point: I have stated before that 4.7 should have been 5.0, since we have significant APIs and functionality changes. The decision to stay with 4.7 and not call it 5.0 had good reasons (too late to call it something else). How about using a code name for the next release and not just a number? For example, if we call the next release any meaningless name such as Gizmo, or Orca, we can then decide before we release it to call it 4.8 or 5.0 depending on what went in.
How about using a code name for the next release and not just a number?
Dries does not like code names, but now that someone else raised the point, I will add my two cents. Let's call it CRYSTAL: Come, Release Years Sooner Than Able Last! (Sorry, could not resist.)
Codenames are used all over the place. Intel has it for the CPUs (Dothan, Willamette, Prescott) Apple has it for OS (Panther, Tiger) Microsoft (Chicago, Longhorn) The only drawback I see from using it is that if some documentation refers to the code name, and then the release number comes along, and there is a disconnect. We can avoid that by using both in the future, for example the release 4.8 becomes (4.8 Dreamy Druplicon) release, so there is no confusion. Debian and Ubuntu use that scheme, and it works OK me thinks. Oh, and Dreamy/Droopy/Drooly are bad names, and can be a turn off for some prospective users, so let us keep the code names simple and neutral, if we decide to use them (fish names, car names, bird names, city names, ...etc.) What are the other objections to code names. On 4/30/06, Karoly Negyesi <karoly@negyesi.net> wrote:
How about using a code name for the next release and not just a number?
Dries does not like code names, but now that someone else raised the point, I will add my two cents.
Let's call it CRYSTAL: Come, Release Years Sooner Than Able Last! (Sorry, could not resist.)
How 'bout naming them for some city where we had an important conference that year? So 4.7 could've been Amsterdam or Vancouver. 4.8 could be Brussels. -Robert Khalid B wrote:
Codenames are used all over the place.
Intel has it for the CPUs (Dothan, Willamette, Prescott) Apple has it for OS (Panther, Tiger) Microsoft (Chicago, Longhorn)
The only drawback I see from using it is that if some documentation refers to the code name, and then the release number comes along, and there is a disconnect.
We can avoid that by using both in the future, for example the release 4.8 becomes (4.8 Dreamy Druplicon) release, so there is no confusion. Debian and Ubuntu use that scheme, and it works OK me thinks.
Oh, and Dreamy/Droopy/Drooly are bad names, and can be a turn off for some prospective users, so let us keep the code names simple and neutral, if we decide to use them (fish names, car names, bird names, city names, ...etc.)
What are the other objections to code names.
On 4/30/06, Karoly Negyesi <karoly@negyesi.net> wrote:
How about using a code name for the next release and not just a number?
Dries does not like code names, but now that someone else raised the point, I will add my two cents.
Let's call it CRYSTAL: Come, Release Years Sooner Than Able Last! (Sorry, could not resist.)
The best scheme is a meaningless name picked from a virtually endless "domain". Using Vancouver or Amsterdam because we had a conference there means that we will be in trouble next year if the conference is held in the same city. This is the same way you name machines in a network. Never give the machines meaningful names or structured code/numbers that may change on upgrades, relocations, mergers/acquisitions, ...etc. (An example was in the early days of Usenet and email, machines were called by the make/model, e.g. decvax or sun, and then they were replaced but the name has to stay the same). We can call them Ferrari, Porsche, ...etc. (Dries will like these). We can call them Eagle, Hawk, Falcon, or Shark, Orca, Stingray, ...etc. This is not to say that it can have hidden messages or dual meaning (I am sure chx can invent a witty acronym out of any of those).
From the exotic ideas departments, we can name the upcoming one HoneyMoon because Dries got married earlier this year. Or, we can use my youngest daughter's name, or someone's favorite pet. The supply is endless.
Before we decide on a code name, let Dries bless the idea of using code names first, since he had reservations in the past (as per chx). I think it solves the issue of us being stuck with a number and over (or under) growing it in the release cycle. On 4/30/06, Robert Douglass <r.douglass@onlinehome.de> wrote:
How 'bout naming them for some city where we had an important conference that year? So 4.7 could've been Amsterdam or Vancouver. 4.8 could be Brussels.
-Robert
Khalid B wrote:
Codenames are used all over the place.
Intel has it for the CPUs (Dothan, Willamette, Prescott) Apple has it for OS (Panther, Tiger) Microsoft (Chicago, Longhorn)
The only drawback I see from using it is that if some documentation refers to the code name, and then the release number comes along, and there is a disconnect.
We can avoid that by using both in the future, for example the release 4.8 becomes (4.8 Dreamy Druplicon) release, so there is no confusion. Debian and Ubuntu use that scheme, and it works OK me thinks.
Oh, and Dreamy/Droopy/Drooly are bad names, and can be a turn off for some prospective users, so let us keep the code names simple and neutral, if we decide to use them (fish names, car names, bird names, city names, ...etc.)
What are the other objections to code names.
On 4/30/06, Karoly Negyesi <karoly@negyesi.net> wrote:
How about using a code name for the next release and not just a number?
Dries does not like code names, but now that someone else raised the point, I will add my two cents.
Let's call it CRYSTAL: Come, Release Years Sooner Than Able Last! (Sorry, could not resist.)
My suggestion for the name is "Wizened Dogrose". -- Konstantin
Khalid B wrote:
Side point: I have stated before that 4.7 should have been 5.0, since we have significant APIs and functionality changes. The decision to stay with 4.7 and not call it 5.0 had good reasons (too late to call it something else).
How about using a code name for the next release and not just a number? For example, if we call the next release any meaningless name such as Gizmo, or Orca, we can then decide before we release it to call it 4.8 or 5.0 depending on what went in.
Excellent idea, and one that I support. I like my branch numbers to have meaning. As a bonus, the press loves the cachet of code names. :-) ..chrisxj
Let us not loose focus because we can reply with nice names and acronyms! Op zondag 30 april 2006 15:23, schreef Khalid B:
You have listed some good points about two parallel tracks for development.
Here are some drawback.
I listed exactly those three, only that I mentioned them as two drawbacks, so let me re-clarify (if that was not a word, it is now).
1. Will be expensive (not only on development, but in terms of community resources, think documentation, support, ...etc. as well as the obvious fragmentation of the development effort).
5.0 will be more of asandbox for at least half a year. Views module: Huge success. Without proper docs for a long while. a) Its appealing: new, exciting, nice to be part-of. CCK: has lived as vapourware and in academical state for at least a year. Only last month JonBob (Jonathan Chaffer) made real documentation and end-user stuff. Why? We all could read+see the proposals, knew that its (for a big part) JonBob working on it, together with other Bright Brains, such as moshe and off course John VanDyk. We trusted their insight, more then we trusted any code or patches, because for a long while they were not there. A patch that breaks everything can still get into 5.0, but in our "normal route" would need enourmous resource, because book.module is bitching, aggregator becomes broken beyond repair etc. All that is of less importance when the pressure for a release is no longer there. My point? Openess, 'freedom' (as in: get free way to do your thing to make Drupal better) has worked. Documentation, resources, etc are not only less important when working in such a "free" environment. We do not need a lot of resources other then those that watn to spend them on sucgh projects anyway!
2. Confusing (communication to prospective and present users, as well as the development community).
No. In contrary. Everyone (involved and interested) knows that KDE 3.5 was a release with bugfixes, some new features and lots of cool and better stuff. But still all people know that KDE 4 is going to be Tha Bomb. If we put it right, it is not at all hard to communicate that: 4.8 will be a release with more, better, nicer stuff then 4.7. That people should focus on that, for their sites. 5.0 ails to be a next generation CMS. is something to get very excited about, and to be invloeved in, but is nothing to deploy, yet. That is less confusing then stuff like "sorry, 4.8 was supposed to release early 2007, but it is January 2008 now. If you want us to release soon, please review patches." and with all the plans I have heard around Drupal, this is IMO going to happen for sure. We cannot manage all this. So either we need (someone) to put an early halt to all the Big Plans, or we will get an even longer slip then 4.7. The stuff people are working on surpasses frms api in both complexity, and amount. By far.
3. Do we have to merge repositories at one point (4.8 branch to 5.0)? If not, then it is effectively maintenance on 4.7, with (possible/questionable) patch ports to 5.0.
No. I was clear about this in my post. If stuff is in 4.8 that is still important for 5.0 there will be resources and people to do that. Same vice versa. I gave examples: "After all: what good will "a small theming improvement on aggregator output" patch do in 5.0, if in 5.0 the "big theme overhaul to make all output structural, like fAPI" patch is already in?"
Having said that, point 1 may not be constrained by the development resource issue that it used to be, since we now have very capable and proven branch maintainers and commiters (Gerhard and Neil). In other words, this is not as much of a problem as it has been in the past where it was mainly Dries doing it all.
Yes. and I beleive that a 5.0 being more free, because it needs not focus on the next release, will only improve this more.
Side point: I have stated before that 4.7 should have been 5.0, since we have significant APIs and functionality changes. The decision to stay with 4.7 and not call it 5.0 had good reasons (too late to call it something else).
Indeed true. This is why longhorn, KDE 4, Mac osx, or any other Huge And Complete Overhaul release has had its branch for ages. I beleive Drupal has reached (already beyond) the point that it needs such a "mayor overhaul branch". Even if we give it some codename. IT does not matter. Point stands that having one pragmatic release (just improve and get new cutting edge stuff in) ASAP, and one academic (become the most and best CMF/S of the world) branch will do us a lot of good. -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com | Heeft het gebruik van Sympal gevolgen voor de eigendomsrechten van het gepubliceerde materiaal?: http://help.sympal.nl/heeft_het_gebruik_van_sympal_gevolgen_voor_de_eigendom...
I am going to partially agree. 4.7 has been in theoretical feature freeze for something like 6 months. It wasn't always enforced that well, but in theory it was. :-) That means there's a backlog of smaller features or niceties that were put aside in order to not break things even more than FAPI did. I know I have 3-4 sitting in the patch queue marked postponed that I've been holding off on for that reason. Saying that 4.7+ will be a smaller "polish and flesh out" release is a good idea. It gives us a chance to take the now (mostly) stable FAPI and flesh it out, get in lots of the convenience features that have been held back recently, debug some more, and so forth, and make 4.8 a really solid, complete, stable, if not-earthshattering-after-4.7 release. Smaller API changes are OK (they always happen), but ground-shaking changes should be put off. It's important to have that really solid and polished release out there, because you know that the big stuff that comes after it is going to take as long as FAPI did to stabilize. That means it will be "out there" for a LONG time. I think of it sort of like the KDE 4 roadmap, honestly. KDE 3.5 was deliberately a conservative "polish and perfect the 3.x series" release, because they knew that 4.0 was going to break stuff, take a year or more to come out, and then another year before many distros get over their x.0-release phobia. That's a good, pragmatic plan, and I see good reason to emulate it. I don't know that we need a separate 5.0 branch right now, though. Really big changes should be made in their own private branches (that's what branching is for), or perhaps even their own separate repositories as FAPI was. They're going to take a while. If the 4.8 cycle is short, then they wouldn't need to go into a mainline tree until after the 4.8 freeze anyway. And, of course, we could use the manpower on polishing 4.8. There would need to be some sort of coordination betwen the different big-changes groups to make sure they all are breaking things in the same way, but that's what a release manager is for: to make sure that the everything-is-cck group and the OO-theming group and the all-sql-is-autogenerated group are not pulling in 4 different directions. As for codenames, the 4.7/5.0 question is why they exist. :-) I'm game. On Sunday 30 April 2006 02:40, Bèr Kessels wrote:
Now that this has been brought up, I'd like to put forward my thoughts or idea.
* split out 4.8 and 5.0 * hard freeze date for 4.8 * roadmap for 5.0
Split 4.8 and 5.0: We all have Great Plans for 4.8. Those Great Plans are all of the magnitude of Fapi. Stick two such overhauls in one release, and we **know** its not going to be possible to release anytime soon. That is a pity for all the small changes (ajax, freetagging, etc) that people want, but are unavailable, because we cannot release 4.8 because all the Big Plans are holding it up.
4.8 for all the usual stuff. (pragmatism) 5.0 for the big re-hauls, gigantic plans and huge patches. (freedom)
Two possible problems, though: People are too busy with one (4.8) to put full attention on another (5.0). And patches will often need to go into two branches: more work, more maintenance. I think both are small problems compared to the amount of freedom (5.0) and pragmatism (4.8) we gain trough this; There are enough people out there anyway, but 5.0 will need no/less testing until its somewhere stable. So it needs far less people. Patches that need to be maintained in pairs: I don't think that will be the case often. After all: what good will "a small theming improvement on aggregator output" patch do in 5.0, if in 5.0 the "big theme overhaul to make all output structural, like fAPI" patch is already in? Patches will be so different that those that apply to both branches have to maintained separate anyway.
Hard freeze date for 4.8.
What does everyone think of hard feature freeze on September 1st? That gives us approximately 4 months of development time.
Neil proposes Sept. 1st. to be a hard freeze date. If we don't have to worry about huge patches, that FUBARed core, this is doable. If we are going to implement all the wild plans, in a single branch (when we do not split 4.8 and 5.0) this is not going to be possible. Esp small bugfixes and features will become unmaintainable, because core changed completely every month or so :). And off course, having two or three Huge projects breaking everyhing requires an unknown amount of time to stabilise (fAPI is *still* not really stable). No roadmap is needed, for 4.8. It can simply be a 'What is in by Sept 1st, is in. The rest is not. Fullstop".
Roadmap for 5.0 Because the 5.0 does not aim at a release date, but at a set of goals (world domination ;) ), I think it will be a good idea to make a roadmap for this. Obviously we'd need a gatekeeper to maintain that roadmap, to provide it from growing unworkable big. If the release for 5.0 will be aimed around a year, a year and a half from now, that roadmap can still be big enought to put all our big ideas in.
This, BTW is how a lot of projects work towards big releases.
Bèr
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Op zondag 30 april 2006 19:54, schreef Larry Garfield:
I don't know that we need a separate 5.0 branch right now, though. Really big changes should be made in their own private branches (that's what branching is for), or perhaps even their own separate repositories as FAPI was. They're going to take a while. If the 4.8 cycle is short, then they wouldn't need to go into a mainline tree until after the 4.8 freeze anyway. And, of course, we could use the manpower on polishing 4.8.
Having a dedicated, and well-defined 4.7, as well as several branches aimnig at "some distant" release sounds like an even better plan then a single 5.0 branch. CVS is not ready for this, though, but we should certainly not hold ourselves back because our tools are bnot able to cope with our ideas :) Let us not get into a CVS vs. XYZ fight right now, but focus on the discussion. Having several brancheseach with their onwbn group and goal is a brillant plan. Theme overhauls do not stand in the way of CCK. A i18n in core will not hold back any development on big nodeapi improvments and so on. So; after I read this post by Larry, I think aiming for a 5.0 is not a good idea after all. But aiming for a 4.7-without-Uncastrated-male-cattle-poop still is a good idea. A,nd having a place, or more places, to put all that Uncastrated-male-cattle-poop is a good idea too, especially if those can be placed in a lot of seperate places. -- [ Bèr Kessels | Drupal services www.webschuur.com ] Heeft het gebruik van Sympal gevolgen voor de eigendomsrechten van het gepubliceerde materiaal?: http://help.sympal.nl/heeft_het_gebruik_van_sympal_gevolgen_voor_de_eigendom...
So; after I read this post by Larry, I think aiming for a 5.0 is not a good idea after all. But aiming for a 4.7-without-Uncastrated-male- cattle-poop still is a good idea. A,nd having a place, or more places, to put all that Uncastrated-male-cattle-poop is a good idea too, especially if those can be placed in a lot of seperate places.
I'm very sceptic about roadmaps and long-term planning in the context of Drupal development. A roadmap is vaporware and creates pressure. In practice, stuff gets written, or it doesn't. Also, the longer we wait to tackle certain problems (and rewrite code), the harder it will be. Therefore, I'm in favor of incremental releases. If you want to take on a big task, please do. The sooner, the better. Things that are ready to go in, go in. Things that are not ready to go in are postponed to the next version. Depending on what went in, we call the next version Drupal 4.8 or Drupal 5.0. Simple as that. -1 for having a roadmap -1 for having two parallel development branches -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
I'm very sceptic about roadmaps and long-term planning in the context of Drupal development. A roadmap is vaporware and creates pressure.
I respectfully disagree on this, commenting from an end user perspective. A roadmap is not about time boxing what is going to be developed when, but a shared common vision of the community how to get from point A to point B -- i.e. to understand the target and to understand the inter-dependencies. I feel this is essential for volunteer based project, although it is true that what is being coded is what gets delivered but without a roadmap how would you get feedback from end users on what is important ? From what I can gather on this mailing list discussions, which I only joined about a month ago, it looks like there are some very important and nifty features in drupal have not had adequate resource to work on . The question is how many people other than the current development community aware of this? A roadmap can be a very effective marketing tool to share your vision with a larger community, it does not need to be time boxed. Cheers, jenny
Dries Buytaert wrote:
I'm very sceptic about roadmaps and long-term planning in the context of Drupal development. A roadmap is vaporware and creates pressure.
Perhaps the "roadmap" could be redefined as two things: 1. Things we hear a lot from users as something they really want to see. We already have surveys thanks to Kieran, and we know what the wish list is. If we do this polling once a year, we will have an idea of what the current needs are. 2. From the above wishlist, we can select features that someone in the development community has committed to writing within the next release, or a sponsor has committed funding. Call the first one "community wishlist", and the second one "roadmap". How about that? Would that reduce the vaporware aspect of it?
Jenny Hsueh wrote:
Dries Buytaert wrote:
I'm very sceptic about roadmaps and long-term planning in the context of Drupal development. A roadmap is vaporware and creates pressure.
... A roadmap is not about time boxing what is going to be developed when, but a shared common vision of the community how to get from point A to point B -- i.e. to understand the target and to understand the inter-dependencies. ...
What is a "shared common vision"? Esoteric wisdom will say it's an illusion. In my experience so far, a roadmap is not appropriate for an open-source community of this calibre. They can be hard to agree on ("we need a vote"), can be stifling ("I'm stuck with this task I don't want"), can create tension ("drupal sucks, look the roadmap you promised"), use up valuable resources ("we have to re-think the roadmap because of ...."). sime
On Mon, 2006-05-01 at 10:51 -0400, Jenny Hsueh wrote:
Dries Buytaert wrote:
I'm very sceptic about roadmaps and long-term planning in the context of Drupal development. A roadmap is vaporware and creates pressure.
I respectfully disagree on this, commenting from an end user perspective. A roadmap is not about time boxing what is going to be developed when, but a shared common vision of the community how to get from point A to point B -- i.e. to understand the target and to understand the inter-dependencies. I feel this is essential for volunteer based project, although it is true that what is being coded is what gets delivered but without a roadmap how would you get feedback from end users on what is important ? From what I can gather on this mailing list discussions, which I only joined about a month ago, it looks like there are some very important and nifty features in drupal have not had adequate resource to work on . The question is how many people other than the current development community aware of this? A roadmap can be a very effective marketing tool to share your vision with a larger community, it does not need to be time boxed.
Cheers, jenny
From a developers perspective...
I'm going to develop what I want for Drupal regardless of the Roadmap other people have. I don't want my pet 'features' that are ready for release to have to wait on your pet feature. I want to see it in the mainline development version so people can test and comment on it. I think people who are actively developing drupal now days have a feel for where it is going. .darrel.
On Monday 01 May 2006 18:25, Darrel O'Pry wrote:
On Mon, 2006-05-01 at 10:51 -0400, Jenny Hsueh wrote:
Dries Buytaert wrote:
I'm very sceptic about roadmaps and long-term planning in the context of Drupal development. A roadmap is vaporware and creates pressure.
I respectfully disagree on this, commenting from an end user perspective. A roadmap is not about time boxing what is going to be developed when, but a shared common vision of the community how to get from point A to point B -- i.e. to understand the target and to understand the inter-dependencies. I feel this is essential for volunteer based project, although it is true that what is being coded is what gets delivered but without a roadmap how would you get feedback from end users on what is important ? From what I can gather on this mailing list discussions, which I only joined about a month ago, it looks like there are some very important and nifty features in drupal have not had adequate resource to work on . The question is how many people other than the current development community aware of this? A roadmap can be a very effective marketing tool to share your vision with a larger community, it does not need to be time boxed.
Cheers, jenny
From a developers perspective...
I'm going to develop what I want for Drupal regardless of the Roadmap other people have. I don't want my pet 'features' that are ready for release to have to wait on your pet feature. I want to see it in the mainline development version so people can test and comment on it. I think people who are actively developing drupal now days have a feel for where it is going.
.darrel.
Well, only kinda. For instance, is CCK ready for prime time yet? Should I be doing my nodes that way from now on? I keep hearing that CCK+Views is The Future(tm), but the last docs and discussion I saw on CCK say that it's still in a state of flux and not yet stable. Knowing something like "4.8 will include a stable CCK, so you can plan accordingly" (or not) is valuable, and not at all obvious to many of we peon developers. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 02 May 2006, at 02:34, Larry Garfield wrote:
I respectfully disagree on this, commenting from an end user perspective. A roadmap is not about time boxing what is going to be developed when, but a shared common vision of the community how to get from point A to point B -- i.e. to understand the target and to understand the inter-dependencies. I feel this is essential for volunteer based project, although it is true that what is being coded is what gets delivered but without a roadmap how would you get feedback from end users on what is important ? From what I can gather on this mailing list discussions, which I only joined about a month ago, it looks like there are some very important and nifty features in drupal have not had adequate resource to work on . The question is how many people other than the current development community aware of this? A roadmap can be a very effective marketing tool to share your vision with a larger community, it does not need to be time boxed.
I'm going to develop what I want for Drupal regardless of the Roadmap other people have. I don't want my pet 'features' that are ready for release to have to wait on your pet feature. I want to see it in the mainline development version so people can test and comment on it. I think people who are actively developing drupal now days have a feel for where it is going.
I was about to say the _exact_ same as Darrel. People who hang out on the mailing list, the forums or on IRC know what can be improved and worked on. Most of us have a feel of what is being worked on, and where things are going. We all know that work is being done on the install system, the CCK, the views module, etc. But wait ... how is that possible without a roadmap? ;)
Well, only kinda. For instance, is CCK ready for prime time yet? Should I be doing my nodes that way from now on? I keep hearing that CCK+Views is The Future(tm), but the last docs and discussion I saw on CCK say that it's still in a state of flux and not yet stable.
You answered your own question.
Knowing something like "4.8 will include a stable CCK, so you can plan accordingly" (or not) is valuable, and not at all obvious to many of we peon developers. :-)
We can't make any such promises, and therefore, we won't. The CCK will be ready when it's ready. Things happens, or not. And when things happens, we'll be coordinating, reviewing, patching and micro-managing. Sorry but we don't do official roadmaps or extensive project planning. -- Dries Buytaert :: http://www.buytaert.net/
Sorry but we don't do official roadmaps or extensive project planning.
Maybe this is the point, which differenciate big, commercial projects and open source software at all. Most of the OSS software lacks of strong leadership and written point of vision. Are you sure, that i18n, CCK, etc. will make it into core without any plans to make it into core? Just start with very simple (one page) official list of major features which should be in 4.8/5.0 and you will do very well for the Drupal development. Regards, Jakub
On 02 May 2006, at 10:25, Jakub Suchy wrote:
Are you sure, that i18n, CCK, etc. will make it into core without any plans to make it into core?
It doesn't depend on the availability of a global roadmap, but on the actual work and planning done by its specific contributors. A roadmap does not guarantee that certain features make it. It does, however, create the kind of hope that will backfire. In the minds of people, roadmaps list deliverables. We won't create an official roadmap.
Just start with very simple (one page) official list of major features which should be in 4.8/5.0 and you will do very well for the Drupal development.
I shared my vision on more than one occasion and now Drupal 4.7.0 is released, I'll be writing about it more. Similarly, other people have been sharing their vision too. I encourage all of you to share your vision. And when you're done, make sure to start writing code and to collaborate (eg. review patches). It is what it takes to turn your vision into reality. I'll do exactly that. (When I started blogging, I promised myself not to theorize about things I won't be working on myself.) Anyway, in the past, I referred to this as a "personal battle plan" (rather than a roadmap or vision), which I think is a much better term in the FOSS world. After each major release, we'd collect people's personal battle plans. Here is my personal battle plan for Drupal 4.6 (and Drupal.org): http://drupal.org/node/11512 Here is my personal battle plan for Drupal 4.5: http://drupal.org/node/6673#comment-10068 I think that, so far, I did pretty well turning my vision into reality. Maybe it is time for another round of 'personal battle plans'? To me, that is a lot more valuable than a roadmap, vision or wishlist. -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
Darrel wrote:
I'm going to develop what I want for Drupal regardless of the Roadmap other people have. I don't want my pet 'features' that are ready for release to have to wait on your pet feature. I want to see it in the mainline development version so people can test and comment on it. I think people who are actively developing drupal now days have a feel for where it is going.
I was about to say the _exact_ same as Darrel. People who hang out on the mailing list, the forums or on IRC know what can be improved and worked on. Most of us have a feel of what is being worked on, and where things are going. We all know that work is being done on the install system, the CCK, the views module, etc. But wait ... how is that possible without a roadmap? ;)
Dries and Darrel are at least partially wrong on that final point -- that people who are actively developing have a [good] feel for where it is going. Dries enjoys an unparalleled position to know those things. He started the project, and he is the primary reviewer and committer. He knows what he is interested in allowing to go in and what he is not, so he clearly has an obvious advantage over knowing which direction Drupal is going. But even active developers can't know everything, and there is the question of just how much involvement some developers can have in the community. Some people have busier lives than others and can't spend all day hanging out in IRC and reading innumerable mailing lists and forums. Moreover, unless you know who the personalities are, and are on good terms with them, there will be some information that may slip by you. Likewise with conferences -- not everybody can attend them. Here's a good example: how many of those "active developers" who "had a good feeling for where it was going" had a clue that the FAPI was going to be dropped in last fall, and that it would have such far reaching effects? I'll wager that number was about 5, not the 338 contributors listed in the 4.7 release. I'm not arguing for a roadmap here. But I am arguing that "active developers already knowing where it's going" as a reason to not have a roadmap is faulty thinking. It's just not true enough. And the bigger the project gets, the less true it will be. ..chrisxj
On 02 May 2006, at 17:26, Chris Johnson wrote:
I'm not arguing for a roadmap here. But I am arguing that "active developers already knowing where it's going" as a reason to not have a roadmap is faulty thinking. It's just not true enough. And the bigger the project gets, the less true it will be.
Yes, we should do a better job communicating about developments and changes in Drupal-land. That is going to be one of my action items. -- Dries Buytaert :: http://www.buytaert.net/
On 02 May 2006, at 17:31, Dries Buytaert wrote:
On 02 May 2006, at 17:26, Chris Johnson wrote:
I'm not arguing for a roadmap here. But I am arguing that "active developers already knowing where it's going" as a reason to not have a roadmap is faulty thinking. It's just not true enough. And the bigger the project gets, the less true it will be.
Yes, we should do a better job communicating about developments and changes in Drupal-land. That is going to be one of my action items.
Summary of the discussion: http://buytaert.net/roadmap. More to come. -- Dries Buytaert :: http://www.buytaert.net/
Darrel O'Pry wrote:
From a developers perspective...
I'm going to develop what I want for Drupal regardless of the Roadmap other people have. I don't want my pet 'features' that are ready for release to have to wait on your pet feature. I want to see it in the mainline development version so people can test and comment on it. I think people who are actively developing drupal now days have a feel for where it is going.
.darrel.
It is fair, one can have ones own view of what they like or dislike without the concerns of others yet wishing others can help to test and comment on their pet features. It is pretty sad if this is the main stream thoughts from developers - I hope this is not the case. But of course, we all like no rules and no obligations ;-). Don't want to be deliberate on this roadmap discussion any more, but my point is - a roadmap or whatever you want to call it, is a tool to make things more "visible" up front and help the community to navigate - I will think a more productive way to get folks to help to test your feature is to make sure whatever you are working or want to work on is important enough to be on the roadmap so that it is visible to others, and any dependencies it has will be well planned and coordinated up front. Jenny
It is fair, one can have ones own view of what they like or dislike without the concerns of others yet wishing others can help to test and comment on their pet features. It is pretty sad if this is the main stream thoughts from developers - I hope this is not the case. But of course, we all like no rules and no obligations ;-).
Jenny This is Open Source development. It does not happen because corporate marketing mandates a feature, or someone up high in the hierarchy orders it down the command chain. It is mainly a scratch your itch thing. Someone's itch may be something relating to a web site they own and run, another person's itch is their non- profit clients, yet another would be commercial clients, yet another would be scalability for a hosting provider, ...etc. We cannot force everyone to a herd mentality or a hive mind. If others want a feature in, they write it, they lobby for it, they convince others of its value. I will only object if I see that this breaks something else, or is bloated, or whatever. In my view, the features have to be the collective sum of pet features that people who chose to propose them and put the effort to make them happen. So, it is not as pessimistic as you understood it to be, or as you may sound to you.
Khalid B wrote:
It is fair, one can have ones own view of what they like or dislike without the concerns of others yet wishing others can help to test and comment on their pet features. It is pretty sad if this is the main stream thoughts from developers - I hope this is not the case. But of course, we all like no rules and no obligations ;-).
Jenny
This is Open Source development. It does not happen because corporate marketing mandates a feature, or someone up high in the hierarchy orders it down the command chain.
fully understand this, myself work in international collaboration/non-profit based projects for many years so understand what you get is only what people are willing to put in there. but over the years, I saw successful projects all have a few common threads; that is i) leadership within the community - the shepherd ii) the atmosphere which promotes the collaboration and helping each others. Not saying drupal is lacking of this, but can be improved.
In my view, the features have to be the collective sum of pet features that people who chose to propose them and put the effort to make them happen.
agree, and if one pet feature is highly demandable over the others, when push comes to shove the decision will be easier. Jenny
Jenny
... I saw successful projects all have a few common threads; that is i) leadership within the community - the shepherd ii) the atmosphere which promotes the collaboration and helping each others. Not saying drupal is lacking of this, but can be improved.
When I stop and reflect on what the community has achieved with drupal, my mind boggles. So how did this all happen without a "road-map"? If it aint broke...
Khalid B wrote:
It is fair, one can have ones own view of what they like or dislike without the concerns of others yet wishing others can help to test and comment on their pet features. It is pretty sad if this is the main stream thoughts from developers - I hope this is not the case. But of course, we all like no rules and no obligations ;-).
Jenny
This is Open Source development. It does not happen because corporate marketing mandates a feature, or someone up high in the hierarchy orders it down the command chain.
It is mainly a scratch your itch thing. Someone's itch may be something relating to a web site they own and run, another person's itch is their non- profit clients, yet another would be commercial clients, yet another would be scalability for a hosting provider, ...etc.
We cannot force everyone to a herd mentality or a hive mind. If others want a feature in, they write it, they lobby for it, they convince others of its value. I will only object if I see that this breaks something else, or is bloated, or whatever.
In my view, the features have to be the collective sum of pet features that people who chose to propose them and put the effort to make them happen.
So, it is not as pessimistic as you understood it to be, or as you may sound to you.
I do think that the one positive to the 'roadmap' argument is to put together what people are working on. Not so much a "This is waht will happen" but a projection of how things look now. Even with the knowledge that this isn't a promise, and is malleable, it can help people out by identifying areas that could use help, should someone wish to pitch in, and it can identify areas that are well covered so that people don't end up butting heads trying to scratch the same itch.
Khalid B wrote:
I do think that the one positive to the 'roadmap' argument is to put together what people are working on. Not so much a "This is waht will happen" but a projection of how things look now. Even with the knowledge that this isn't a promise, and is malleable, it can help people out by identifying areas that could use help, should someone wish to pitch in, and it can identify areas that are well covered so that people don't end up butting heads trying to scratch the same itch.
I think this need is being met by the development of groups.drupal.org. In fact, interested parties could even create a Road-map group! ;-) sime
On Monday 01 May 2006 22:37, info@urbits.com wrote:
I think this need is being met by the development of groups.drupal.org. In fact, interested parties could even create a Road-map group! ;-)
sime
I'm curious. Is there a reason why groups.drupal.org doesn't tie into the drupal.org user list? Isn't that rather what the drupal module is for? :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
I'm using it with my drupal.org account... don't forget the @drupal.org otherwise it won't remote auth you. On Tue, 2006-05-02 at 00:43 -0500, Larry Garfield wrote:
On Monday 01 May 2006 22:37, info@urbits.com wrote:
I think this need is being met by the development of groups.drupal.org. In fact, interested parties could even create a Road-map group! ;-)
sime
I'm curious. Is there a reason why groups.drupal.org doesn't tie into the drupal.org user list? Isn't that rather what the drupal module is for? :-)
On 02 May 2006, at 05:16, Earl Miles wrote:
I do think that the one positive to the 'roadmap' argument is to put together what people are working on. Not so much a "This is waht will happen" but a projection of how things look now. Even with the knowledge that this isn't a promise, and is malleable, it can help people out by identifying areas that could use help, should someone wish to pitch in, and it can identify areas that are well covered so that people don't end up butting heads trying to scratch the same itch.
People will be posting and blogging about what they are working on. Similarly, we'll be posting development updates on the Drupal.org front page, in the Drupal newsletter, etc. We'll be talking and brainstorming about it on the mailing list, on conferences, etc. -- Dries Buytaert :: http://www.buytaert.net/
Op maandag 1 mei 2006 09:08, schreef Dries Buytaert:
The sooner, the better. Things that are ready to go in, go in. Things that are not ready to go in are postponed to the next version. Depending on what went in, we call the next version Drupal 4.8 or Drupal 5.0. Simple as that.
This is oversimplified. But yes. Keeping stuff Simple is a good Drupal habit. Still the fact remains that there are a LOT of big things that want to get into 4.8. To name but a few, which I think make a fair chance: * views in core. Will require a lot of code and modules in core to be removed. Not changed, but removed! * output in fapi strucures, being the newt step towars more of a, MVC. Requires big changes in all modules. Possibly more then fAPI even. Adrian has been talking about this a lot. * CCK in core. not this next release, probably, but certainly worth investigating. After all the purpose of CCK was mostly to get it ready for core? * Foo as nodes. Some work, code and plans are to make profiles as nodes (*cough*) and I am confident that categories.module (taxonomy as nodes) will prove a better alternative then taxonomy.module! I have heard a lot of talk about this, as well as real working code. Just this week another feeds- and feed-items as nodes hit contribs. Working on these four will, I fear and hope, put Drupal completely upside-down. If any of the four goes in, and has an impact close to fAPI, we already need *7 months* (the time it took to get fAPI stable enough for a release) in any case. Add another one and the time will increase exponentially. Views in core, together with, lets say, CCK, would stretch a release to somwhat one and half year, I think. Now, add a third and a fourth, and time will be counted in years, I fear. So, it is simply pragmatism that makes me think we *need* separate branches. It would be a pity if people have to wait for "a-freetagging-alike-feature" (or podcasting support) for 1.5 years, just because all the huge infrastructural changes keep the release from releasing. I would even go so far as to predict, that if we keep Drupal so long (a year) from releasing in the coming cycle, people will release forks, just to be able to distribute and use a backported feature. People will backport a feature (like freetagging) and release that 'drupal' as DrupalFreeTagging or so. [*] [*] freetagging is used as example, because it was a feature added early in the 4.7 branch, yet only reached people today. Bèr -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
Bèr Kessels wrote:
* views in core. Will require a lot of code and modules in core to be removed. Not changed, but removed!
I don't, honestly, see this happening for a variety of reasons. Views works well as a contrib module, and in that light, I think it's a great motivator to actually remove a bunch of stuff from core entirely, and move them into the talked-about-but-as-yet-not-implemented 'golden' contrib area, where the modules in that area have a higher level of scrutiny and review, similar to core.
Op maandag 1 mei 2006 20:01, schreef Earl Miles:
I don't, honestly, see this happening for a variety of reasons. Views works well as a contrib module, and in that light, I think it's a great motivator to actually remove a bunch of stuff from core entirely, and move them into the talked-about-but-as-yet-not-implemented 'golden' contrib area, where the modules in that area have a higher level of scrutiny and review, similar to core.
You are right here. Let us hope that the zhole concept of "core" will change soon. But. As it stand now, core pretends to be a ready-to-go-handy-to-use set. It is everything but that IMO. nearly all core modules (the only one I do not know alternatives for is forum) have FAR better equivalents in contribs. Netto result is that someone who is serious about building a site needs to digg deep into contribs to find all the replacements for core modules. I also think this proves that the free/open way of contribs prove to be a very healthy way of getting good quality projects out there. Bèr
Bèr Kessels wrote:
If any of the four goes in, and has an impact close to fAPI, we already need *7 months* (the time it took to get fAPI stable enough for a release) in any case.
To be fair, half the reason FAPI took so long to troubleshoot/bug-fix is because it was completely new, never-before done and basically a complete rewriting of how Drupal does forms (which are used in almost every file ;)) from the ground up. There was no way to predict all the possible scenarios that would need to be accounted for until much, much later. Most of the changes you outline either already have existing code in contrib or wherever to draw from, or are re-tooling/enhancement type of things (like FAPI improvements or X as nodes). I don't see a lot of "start completely over from scratch" stuff here, so I think "years" may be a tad bit unrealistic. ;) I do agree that getting all 4 of them in the same release is probably a stretch, especially with a now "time boxed" development cycle, but hey let's see what happens! -Angie CivicSpace Labs
http://drupal.org/node/61285 Its presence in core is holding up its own development.
Robert Douglass wrote:
Its presence in core is holding up its own development.
cool idea. And let's rm archive.module and maybe blog.module too. :) Cheers, Gerhard
Gerhard Killesreiter wrote:
Robert Douglass wrote:
Its presence in core is holding up its own development.
cool idea. And let's rm archive.module and maybe blog.module too. :)
+1. These should become contrib modules. 'Course, that requires someone actually maintain them. That's something that really needs to be worked out on the 'golden' contrib. Well ok, archive can probably almost just disappear, it really doesn't do much.
Before we go overboard on this, do not take them out of core until someone takes each one and give it the necessary TLC (tender loving care). Unmaintained modules just fall off the face of the earth. Look at queue module and where it has been in over a year. Not a single commit!
Well ok, archive can probably almost just disappear, it really doesn't do much.
A while back, there was a push to replace archive by codemonkeyx's contributed version. See this http://drupal.org/node/29676
A while back, there was a push to replace archive by codemonkeyx's
Yes - I was behind that push. However, there were two difficulties: * There's a particular SQL query that doesn't work in PgSQL (the one that gets a list of months in which there are posts, I think). * There were reports of off-by-one errors, compounded by what appeared to be bad handling of GMT and epoch seconds, in the database, and their modification by the user's or admin-set timezone. I am still using the last known good version of archive.module (as posted on the issue you linked) on yesterday's HEAD at disobey.com: http://www.disobey.com/archive -- Morbus Iff ( if god is my witness, god must be blind ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
I have a quick question pertaining this issue : why is it not possible to have one blog/polling module like Scoop? On 01.May.2006, at 02:53 PM, Morbus Iff wrote:
A while back, there was a push to replace archive by codemonkeyx's
Yes - I was behind that push. However, there were two difficulties:
* There's a particular SQL query that doesn't work in PgSQL (the one that gets a list of months in which there are posts, I think).
* There were reports of off-by-one errors, compounded by what appeared to be bad handling of GMT and epoch seconds, in the database, and their modification by the user's or admin-set timezone.
I am still using the last known good version of archive.module (as posted on the issue you linked) on yesterday's HEAD at disobey.com:
http://www.disobey.com/archive
-- Morbus Iff ( if god is my witness, god must be blind ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
blogdiva@culturekitchen.com wrote:
I have a quick question pertaining this issue : why is it not possible to have one blog/polling module like Scoop? The blog and poll modules do completely different things in Drupal. How are the two related in Scoop?
Queue.module, for example, is relatively similar to nmoderation module, which is now available for 4.7. That work was sponsord by Code0range.net, and I'm working on a migration script for queue.module data. I'd initially understood that queue's moderation system worked like the comment moderation tools in 4.6; as it's slightly different, I'm putting a bit more work into the conversion path. But it is happening. Queue.module, though, was a case of 'just good enough to prevent further core development, but not good enough to do what people really want it to.' That specific module may have vanished once it hit contrib, but the core need now has a number of solutions depending on a site's need. Vote-up-down simulates digg-style voting, nmoderation offers a relatively complex voting matrix, and so on. The suggestion was put out that poll.module be ported to VotingAPI; If someone's willing to take a stab at converting it, I'd be willing to work with them and assist in ongoing support. Off the top of my head, it would be easy to support multichoice polls, write-in answers, and users-changing-their-votes. --Jeff
-----Original Message----- From: Khalid B [mailto:kb@2bits.com] Sent: Monday, May 01, 2006 1:41 PM To: development@drupal.org Subject: Re: [development] Time to remove poll module from core
Before we go overboard on this, do not take them out of core until someone takes each one and give it the necessary TLC (tender loving care).
Unmaintained modules just fall off the face of the earth. Look at queue module and where it has been in over a year. Not a single commit!
Well ok, archive can probably almost just disappear, it really doesn't do much.
A while back, there was a push to replace archive by codemonkeyx's contributed version.
See this http://drupal.org/node/29676
Thank you Jeff. The larger point is that the real innovation in this space cannot happen *inside of core*, and nobody is interested in developing it further if there are better options available in contrib. If someone *is* interested, they'll step forward. I wouldn't lament the demise of the queue.module one bit. If nobody has committed to that code base since its removal from core, that is a good indication that removing it was the right thing to do. -Robert Jeff Eaton wrote:
Queue.module, for example, is relatively similar to nmoderation module, which is now available for 4.7. That work was sponsord by Code0range.net, and I'm working on a migration script for queue.module data. I'd initially understood that queue's moderation system worked like the comment moderation tools in 4.6; as it's slightly different, I'm putting a bit more work into the conversion path. But it is happening.
Queue.module, though, was a case of 'just good enough to prevent further core development, but not good enough to do what people really want it to.' That specific module may have vanished once it hit contrib, but the core need now has a number of solutions depending on a site's need. Vote-up-down simulates digg-style voting, nmoderation offers a relatively complex voting matrix, and so on.
The suggestion was put out that poll.module be ported to VotingAPI; If someone's willing to take a stab at converting it, I'd be willing to work with them and assist in ongoing support. Off the top of my head, it would be easy to support multichoice polls, write-in answers, and users-changing-their-votes.
--Jeff
4.8 core should be slimmer with fewer modules (rm poll, archive, blog|story|page), but we should make it our goal to have a small number of targeted distributions that mix core with some contrib modules and an install profile to do a specific task. With the new groups site, this can be coordinated much more easily. A group would form around a proposed distribution, say Drupal for blogging, or Drupal for E-Commerce. They would put together core plus modules of their choice and it would get distributed as an official "package". Each group would have to have to be dedicated to maintaining their packages throughout the release cycle, which can be years, so such an undertaking is not to be started lightly. This approach would keep the core team free to do their thing, obviate the discussion of making a "golden" contrib repository, and make Drupal much more accessible to various targeted audiences while avoiding forking.
On 01 May 2006, at 10:17 PM, Robert Douglass wrote:
With the new groups site, this can be coordinated much more easily. A group would form around a proposed distribution, say Drupal for blogging, or Drupal for E-Commerce. They would put together core plus modules of their choice and it would get distributed as an official "package". Each group would have to have to be dedicated to maintaining their packages throughout the release cycle, which can be years, so such an undertaking is not to be started lightly. This approach would keep the core team free to do their thing, obviate the discussion of making a "golden" contrib repository, and make Drupal much more accessible to various targeted audiences while avoiding forking.
That's my first concern too. Getting dependencies ready for install profiles. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Before we go overboard on this, do not take them out of core until someone takes each one and give it the necessary TLC (tender loving care).
Unmaintained modules just fall off the face of the earth. Look at queue module and where it has been in over a year. Not a single commit!
Core is not an orphanage. It does not nurse unloved modules. If noone cared about queue.module in contrib, that's means it should have been kicked out of core a long time ago.
The whole poll discussion got me thinking. At a philosophical level, what DOES qualify a module for inclusion in core? The fact that many other useful things are built on top of it (APIs, etc)? The fact that it provides specific functionality needed by a critical mass of sites? The mere fact that it meets the coding standards? Clearly not #3. :) But obviously, most of the current core modules evolved as a part of the much older Drupal builds. What criteria make something *good* for core? --Jeff
Jeff Eaton wrote:
The whole poll discussion got me thinking. At a philosophical level, what DOES qualify a module for inclusion in core? The fact that many other useful things are built on top of it (APIs, etc)? The fact that it provides specific functionality needed by a critical mass of sites? The mere fact that it meets the coding standards? Clearly not #3. :) But obviously, most of the current core modules evolved as a part of the much older Drupal builds. What criteria make something *good* for core?
In the case of poll module it is clearly a case of "because it always was in core". I think the same applies to archive module. Very few modules ever get into core and/or removed from it. Cheers, Gerhard
On 5/1/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Robert Douglass wrote:
Its presence in core is holding up its own development.
cool idea. And let's rm archive.module and maybe blog.module too. :)
I can't tell if that's sarcasm or not... Cheers,
Gerhard
On 01 May 2006, at 9:15 PM, Gerhard Killesreiter wrote:
cool idea. And let's rm archive.module and maybe blog.module too. :)
and what's the different between page and story module at the moment, anyway. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
The real differences between page, story, and blog are behavioural. Permissions, display settings, and default URLs (/blog and /blog/uid in the case of blog.module) are the issues. The ability to easily slice-and-dice stuff like 'latest content' listings for specific tyes is one of the reasons I'd love to see something like views.module (though not views_ui.module) eventually rolled into core. Providing JUST the backend features would allow module developers ot include that kind of functionality in a way that's relatively 'transparent' to end users. Advanced users could easily override the views by installing views_ui.module. Or something like it. But that's another debate, I suppose. The point remains: Story, page, and blog content types are essentially identical. The only purpose they serve is to provide different behaviors in configuration, etc. --Jeff
-----Original Message----- From: Adrian Rossouw [mailto:adrian@bryght.com] Sent: Monday, May 01, 2006 2:06 PM To: development@drupal.org Subject: Re: [development] Time to remove poll module from core
On 01 May 2006, at 9:15 PM, Gerhard Killesreiter wrote:
cool idea. And let's rm archive.module and maybe blog.module too. :)
and what's the different between page and story module at the moment, anyway.
Robert Douglass wrote:
Its presence in core is holding up its own development.
cool idea. And let's rm archive.module and maybe blog.module too. :) Cheers, Gerhard
As someone mentioned in the thread this posting was derived from, moving modules out of core often means they fall of the face of the earth and no longer get support and updates. That's not good. On the other hand, we cannot add every valuable module which has or needs good on-going support to core. Various solutions to this have been proposed before. Here's mine for this year: => Core should be core required files and code only. For the rest of this posting, I will call these the "framework files" or just "framework," but the name is mostly not important to me. It's just for clarity. => There should be a group of the most useful, best coded modules which are maintained and supported like the core itself. For the rest of this posting, I will call these the "core modules" => There should be a contrib repository for any and all other code contributed by anyone with a CVS account. Support and maintenance is whatever is contributed. Why: this removes the tension of trying to keep "core" small by removing some useful and important modules in order to add newer, more "interesting" modules, yet at the same time provides a reasonable library of "core modules" which can be relied upon from release to release by the community. As we grow more expert developers, the size of the "core modules" library can grow, too. Not everybody is using Drupal the same way. This creates an inherent continuing conflict over which modules should be in what we now call core. It causes frustration when a module that a dozen sites depend on get dropped from core and a new release of Drupal comes out. Is Drupal a full-featured CMS out of the "core" box? Why bother struggling with that question and instead admit that Drupal can do a variety of different things with the right modules. Moving to a framework with installable profiles (collections of modules) for different uses will help move Drupal into wider usage, and at the same time, provide a better upgrade path for current installations. It will also encourage more API-style thinking when developing, since the "framework files" will be mostly APIs upon which all else is built. This would result over time in the framework becoming more generic and more optimized, which should allow for more creative and unusual modules to be built on top of it. It might even be sane to say that without installing at least one profile or bundle of modules on top of the framework, it wouldn't even function at all. For sake of example, the "download Drupal" page could offer the new user (say) 3 bundles or profiles, each a collection of the framework files plus only the modules needed to implement that profile. They might be: CMS, blog, and e-commerce site. Or something else. The same serious attention that is given to today's "core" would be given to both the "framework" and the "core modules" tomorrow. The initial division would not change the total amount of code maintained but would allow more modules to be added without pushing others out as the developer manpower became available. I think this sort of division would make life simpler for many existing sites who face upgrades, as well as make Drupal less intimidating for newcomers looking to start building. And, of course, scratching my own itch, this would make my life much simpler, because I use very few of today's "core" modules, but use lots of other modules outside of them. I want a clean framework to build on top of and I'm willing to do the work to make it happen. Ok, that's my few minutes on the soapbox for this quarter. :-) ..chrisxj
=> Core should be core required files and code only. For the rest of this posting, I will call these the "framework files" or just "framework," but the name is mostly not important to me. It's just for clarity.
=> There should be a group of the most useful, best coded modules which are maintained and supported like the core itself. For the rest of this posting, I will call these the "core modules"
This is something that I've suggested before -- some things, like node.module and so on, are obviously always going to be a part of the "framework files". This meshes very well, IMO, with Robert's vision of 'targeted distributions.' I think providing the current mix of Drupal core modules as a 'Classic Drupal' distro, or something like that, would be a fine way to let people keep on going as they have been. Those who want something else can get framework + a distro, or framework + a custom mix of modules and themes, etc. --Jeff
This echos a post I made on this list a few months ago as well, during the last time we discussed trimming core. I used the term "endorsed modules", but same idea. Views and flexinode/cck are far more useful in core than, say, blogapi. I'm not even entirely sure what that does. :-) One proposal that had been floated for the "1st tier" modules (whatever they're called) was automatic downloading. Core is/should be small, but people need to be able to get the functionality they want quickly and easily. Being able to download and install a stable module from within the UI would make that much easier, as well as not require separate download tarballs for each "distribution profile". I freely confess to not knowing all that would need to go into this drupal-get module, though. I vaguely recall someone mentioning that they were doing something along these lines. If that's you, what were you doing? -- Larry Garfield On Mon, May 1, 2006 2:40 pm, Jeff Eaton said:
=> Core should be core required files and code only. For the rest of this posting, I will call these the "framework files" or just "framework," but the name is mostly not important to me. It's just for clarity.
=> There should be a group of the most useful, best coded modules which are maintained and supported like the core itself. For the rest of this posting, I will call these the "core modules"
This is something that I've suggested before -- some things, like node.module and so on, are obviously always going to be a part of the "framework files". This meshes very well, IMO, with Robert's vision of 'targeted distributions.'
I think providing the current mix of Drupal core modules as a 'Classic Drupal' distro, or something like that, would be a fine way to let people keep on going as they have been. Those who want something else can get framework + a distro, or framework + a custom mix of modules and themes, etc.
--Jeff
I think we have essentially the same idea, Chris, and that leaves the question "how best to achieve it?" One thing that is needed for distributions to work well is the further delegation of responsibility. Adding some core maintainers (Gerhard and Neil) has worked out fantastically well. The distributions idea offers another opportunity to delegate responsibility even further. If "Bob" were made the maintainer of the "Drupal Blogging" distribution, and this meant selecting and vetting modules, coordinating development efforts, and preparing an install profile, then Bob would have a chance to shine in this new role the way that Gerhard rose to the task of being a core maintainer. Doling out responsibility like this is a great way to get things done =) One step further... if we use the groups site to let people "organically" decide which distributions they're interested in creating and maintaining, then we can wait until the distros actually appear before officially promoting them. This would prevent the scenario where we decide today that we really need "Drupal Blogging", but watch it fall on its face because nobody is really interested. Tell people to go out and make the distros, prove their value, show that they are serious efforts, and then, after they've proven themselves adequately, list them as official. -Robert Chris Johnson wrote:
=> There should be a group of the most useful, best coded modules which are maintained and supported like the core itself. For the rest of this posting, I will call these the "core modules"
On May 1, 2006, at 12:14 PM, Robert Douglass wrote:
Its presence in core is holding up its own development.
i agree with the thrust of this discussion (and the spin-offs) about slimming down core, removing not-so-core modules from core, etc. however, back to the original discussion at hand: removing poll -- does that mean i shouldn't bother working on http://drupal.org/node/51561 at all? i'd like to see a lot of improvements in poll, and would be willing to help work on them, but i don't want to waste effort if it's all going to be re-done, etc. should we make a group on groups.drupal.org for "poll developers"? i wonder how many of the DEP-related activities (e.g. all the almost-effort going into event, event management, etc) should be moved to a group there, too. i just created my account on groups.drupal.org, so i haven't checked it out yet in detail, but should this be the wave of the future for collaborative development, co-maintainers, etc? thanks, -derek (dww)
Robert Douglass wrote:
Its presence in core is holding up its own development.
There are plenty of good reasons to move modules around, but I don't think "to get more development done" is a good one. As Steven Peck said, being a maintainer would be best. I suspect poll is one of core's least-used modules, if that is true, then that is a good reason to consider removing it. And remember, we don't currently have any sort of golden contrib, so dropping a module from core is pushing it off a proverbial cliff. Maybe poll has a better parachute than queue module. -- Neil Drumm http://delocalizedham.com/
On 5/2/06, Neil Drumm <drumm@delocalizedham.com> wrote:
I suspect poll is one of core's least-used modules, if that is true, then that is a good reason to consider removing it.
I really doubt that poll is one of core's 'least-used' modules. I publish polls regularly on GreenAsh, and I've seen countless other Drupal sites that do the same. I'm betting that poll gets used a lot more than other core modules, such as blogapi. Having said that, I do also think that poll should be removed from core. We could use a decent poll module in contrib - I don't see any there already. ;-) Jeremy Epstein GreenAsh Services www.greenash.net.au
Here is a related topic: We discussed why poll should/should not be removed, and what happened to queue, and potentially others. In another thread Derek asked why core has modules at all. This goes back to the install profiles (bundles, preconfigured sets, whatever you want to call them) discussions. We can have a profile called "default" or "basic" or "community" and it could contain the modules currently in core (assigned to one or more maintainers). This has the benefit of slimming core even more and making it more into framework/API than a "blogging package" or "CMS package".
On May 2, 2006, at 8:05 PM, Khalid B wrote:
In another thread Derek asked why core has modules at all.
that wasn't me. i believe you're thinking of jeff eaton. i think drupal's "core" should contain some modules, even ones beyond the required 4 or 5. but, i'm in support of reducing the # of modules in core, and distributing the work of maintaining modules that are important, but not necessarily "core".
This has the benefit of slimming core even more and making it more into framework/API than a "blogging package" or "CMS package".
agreed. some things in core clearly don't need to be there, and contribute to drupal's (undeserved but understandable) reputation as "just a blogging package". -derek
Disclaimer : I am not a developer but a bootstrapped blog publisher. I am here because ... well ... I guess I can. I had asked before why this module could not be bundled in with the blog module; as in making it an extension just as comments and trackbacks. As someone who uses Drupal for a bit more than blogging, having polls in a post, the way Scoop sites have it, would make sense from a marketing research/political polling POV. Blog polls allow for immediate capturing of capture people's thoughts on a post. I honestly don't know why CivicSpace didn't steal that idea from the DailyKos crowd. Anyhow, it's one of those features I'd Best, Liza Sabater, Publisher www.lizasabater.com Culture + Politics + Technology www.culturekitchen.com New York grassroots news and activism www.dailygotham.com Feminist Bloggers Network www.blogsheroes.com A new kind of vouyerism www.voogling.com AIM - cultkitdiva SKYPE - lizasabater TEL - 646.552.7365 NOTICE: Due to Presidential Executive Orders, the National Security Agency may have read this email without warning, warrant, or notice. They may do this without any judicial or legislative oversight. You have no recourse nor protection save to call for the impeachment of President George W. Bush and Vice-President Richard Cheney, for high crimes and misdemeanors. On 02.May.2006, at 11:16 PM, Derek Wright wrote:
On May 2, 2006, at 8:05 PM, Khalid B wrote:
In another thread Derek asked why core has modules at all.
that wasn't me. i believe you're thinking of jeff eaton.
i think drupal's "core" should contain some modules, even ones beyond the required 4 or 5. but, i'm in support of reducing the # of modules in core, and distributing the work of maintaining modules that are important, but not necessarily "core".
This has the benefit of slimming core even more and making it more into framework/API than a "blogging package" or "CMS package".
agreed. some things in core clearly don't need to be there, and contribute to drupal's (undeserved but understandable) reputation as "just a blogging package".
-derek
I had asked before why this module could not be bundled in with the blog module; as in making it an extension just as comments and trackbacks.
I hear ya. I think, to some degree, what you want is possible now. Sorta. Say you make a new poll, and assign it to a block. Then, your theme would make a new block region "inside" the appearance of your blog post, and your poll block would go there. The problem is: a) this is not admin-friendly whatsoever, b) there's some craziness involved with setting the block options to only appear on certain URLs, etc. Regardless, however, I think it *is* possible right now.
Anyhow, it's one of those features I'd
I'd like a feature in email clients that'd forbid sending of mail where the signature is longer than the body of the message itself. -- Morbus Iff ( i subscribe to the theory of intellectual osmosis ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
As someone who uses Drupal for a bit more than blogging, having polls in a post, the way Scoop sites have it, would make sense from a marketing research/political polling POV. Blog polls allow for immediate capturing of capture people's thoughts on a post. I honestly don't know why CivicSpace didn't steal that idea from the DailyKos crowd.
I think what we can do is stop having polls as their own type of content. They are an add on module, like upload (file attachments), nodevote (votes), ...etc. In other words, they add polls on the form of any type of content that the admin assigns it to be. So, we can have blog polls, forum polls, page polls, ...etc.
Khalid B wrote:
As someone who uses Drupal for a bit more than blogging, having polls in a post, the way Scoop sites have it, would make sense from a marketing research/political polling POV. Blog polls allow for immediate capturing of capture people's thoughts on a post. I honestly don't know why CivicSpace didn't steal that idea from the DailyKos crowd.
I think what we can do is stop having polls as their own type of content. They are an add on module, like upload (file attachments), nodevote (votes), ...etc.
In other words, they add polls on the form of any type of content that the admin assigns it to be. So, we can have blog polls, forum polls, page polls, ...etc. I don't think demoting polls to a second class data type as an answer; a poll should be a node, but we need our blogs and forums to be able to accept more content types than just 'blog' or 'forum'.
I don't think demoting polls to a second class data type as an answer; a poll should be a node, but we need our blogs and forums to be able to accept more content types than just 'blog' or 'forum'.
I'm with Earl on this one. Blogs are not a *content type* even though we treat them that way in blog.module. They're a container, and (in most cases) a presentation style. "Blogs" should be able to accept weblink nodes, images, polls, journal entries, and so on. --Jeff
This all comes down to one point: we need an outliner to rule them all: forums, book module, blogs... they're all just containers for (CCK) node types. Sorry I haven't evaluated the Category module outliner... it might really be in the direction I'm thinking of. --Robert Jeff Eaton wrote:
I don't think demoting polls to a second class data type as an answer; a poll should be a node, but we need our blogs and forums to be able to accept more content types than just 'blog' or 'forum'.
I'm with Earl on this one. Blogs are not a *content type* even though we treat them that way in blog.module. They're a container, and (in most cases) a presentation style. "Blogs" should be able to accept weblink nodes, images, polls, journal entries, and so on.
--Jeff
On 5/4/06, Robert Douglass <r.douglass@onlinehome.de> wrote:
we need an outliner to rule them all: forums, book module, blogs... they're all just containers for (CCK) node types.
Sorry I haven't evaluated the Category module outliner... it might really be in the direction I'm thinking of.
The category_outliner module just mimicks the functionality of the 'outline view' feature in the book module (i.e. a view of the node hierarchy as an admin page). Perhaps category_transform is more what you had in mind? Category_transform mimicks the 'add to outline' feature of the book module (i.e. it 'transforms' a node of another type into a category or container). I'm currently working on changing the category module to the event module's model, of allowing any node type to also 'be' a category or container type (this work is being sponsored). When this is ready, it will essentially make the category module ready for the plans that you have in mind. Jeremy Epstein GreenAsh Services www.greenash.net.au
Somewhere in the CivicSpace or Drupal archives I said something to this effect more than a year ago. But I can't code modules ... sigh ... but yes, this is exactly what I've advocated for in the past. I honestly do not understand why there are distinctions between blog, story and page. I find them redundant. For someone who is a publisher/designer and minor tinkerer of modules, I'd consolidate those three into just the blog node and make that as extensible or static as possible. Liza Sabater, Publisher www.culturekitchen.com www.dailygotham.com TEL - 646.552.7365 AIM - cultkitdiva SKYPE - lizasabater On 03.May.2006, at 01:17 PM, Jeff Eaton wrote:
I don't think demoting polls to a second class data type as an answer; a poll should be a node, but we need our blogs and forums to be able to accept more content types than just 'blog' or 'forum'.
I'm with Earl on this one. Blogs are not a *content type* even though we treat them that way in blog.module. They're a container, and (in most cases) a presentation style. "Blogs" should be able to accept weblink nodes, images, polls, journal entries, and so on.
--Jeff
For someone who is a publisher/designer and minor tinkerer of modules, I'd consolidate those three into just the blog node and make that as extensible or static as possible.
Well... That's part of the problem. I don't think that content types should be consolidated into the 'blog' module, because blogging is only one of many things that can be done with Drupal. It would be like consolidating everything into the 'forum' module because people run community discussion sites with Drupal. Rather, the 'blog' module should allow users to select what content types they want to be included in their 'blog,' and display them accordingly. Amazon Tools book-review nodes, story nodes, polls, images, etc. If it's really necessary to stick a particular poll inside the *body* of another node (like a blog post or a story), it seems that a syntax for doing that, and an input filter, would be a better way to go. <poll id="$nid"> or something HTML-ish like that. One of the reasons I jumped into the Drupal community was the tremendously powerful concept of 'different content types for different purposes, all with the same shared interface.' Anything that moves us away from that is a mistake, IMO, but anything that lets us better leverage that power is a good thing. We might be saying the same thing -- I apologize if I misunderstood what you were getting at :) --Jeff
blogdiva@culturekitchen.com wrote:
Somewhere in the CivicSpace or Drupal archives I said something to this effect more than a year ago. But I can't code modules ... sigh ... but yes, this is exactly what I've advocated for in the past. I honestly do not understand why there are distinctions between blog, story and page. I find them redundant.
For someone who is a publisher/designer and minor tinkerer of modules, I'd consolidate those three into just the blog node and make that as extensible or static as possible.
Liza, the "node" itself is extensible, blog is not the right root type, "node" is. Story, book, page, forum, blog (SBPFB) all are just alternative names to "node", they don't contain/support more as a content type. Poll supports more (and is different in that it has no body/teaser text). The SBPFB node types exist so that you can assign different workflows to them, and display them in different built in views. Ie. you can easily restrict people to only create content in the forums and not in your articles section. If all these would be one, you would not have this functionality (on the type level). The different display of forums and blogs are also quite handy, or the easier outlining of book nodes (as opposed to what you need to do when putting a story or a poll into a book outline). This is why there are distinctions, maybe it is understandable now. Goba
Op woensdag 3 mei 2006 19:17, schreef Jeff Eaton:
I don't think demoting polls to a second class data type as an answer; a poll should be a node, but we need our blogs and forums to be able to accept more content types than just 'blog' or 'forum'.
I'm with Earl on this one. Blogs are not a *content type* even though we treat them that way in blog.module. They're a container, and (in most cases) a presentation style. "Blogs" should be able to accept weblink nodes, images, polls, journal entries, and so on.
--Jeff
Indeed. Blogs are containers. Once Working Code For Blogs As Containers here: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/ber/blog/ Though now I think blog.module should really be just a viewsAPI :) Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] Heeft het gebruik van Sympal gevolgen voor de eigendomsrechten van het gepubliceerde materiaal?: http://help.sympal.nl/heeft_het_gebruik_van_sympal_gevolgen_voor_de_eigendom...
On 03 May 2006, at 10:58 PM, Bèr Kessels wrote:
Though now I think blog.module should really be just a viewsAPI :)
yes. =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Wed, 2006-05-03 at 12:17 -0500, Jeff Eaton wrote:
I don't think demoting polls to a second class data type as an answer; a poll should be a node, but we need our blogs and forums to be able to accept more content types than just 'blog' or 'forum'.
I'm with Earl on this one. Blogs are not a *content type* even though we treat them that way in blog.module. They're a container, and (in most cases) a presentation style. "Blogs" should be able to accept weblink nodes, images, polls, journal entries, and so on.
--Jeff
So you're saying a blog should be a View? ;)
Darrel O'Pry wrote:
On Wed, 2006-05-03 at 12:17 -0500, Jeff Eaton wrote:
I don't think demoting polls to a second class data type as an answer; a poll should be a node, but we need our blogs and forums to be able to accept more content types than just 'blog' or 'forum'.
I'm with Earl on this one. Blogs are not a *content type* even though we treat them that way in blog.module. They're a container, and (in most cases) a presentation style. "Blogs" should be able to accept weblink nodes, images, polls, journal entries, and so on.
--Jeff
So you're saying a blog should be a View? ;)
It's hard to argue otherwise. A blog is a retrieval of content based upon some parameter. There are three most common parameters: 1) posts by blog author that are in this blog container. (Currently we note that by node type; in the future, I'd rather use a parent-child relationship. Hey relationships API!) 2) posts in all of these blog containers that I have bookmarked. I.e, subscribed to. Example: Blog Site #879812 has 8,372 different blogs; some are single-author blogs, some are multi-author blogs. The actual post rate is approximately one post every 30 seconds, meaning my 20 post page fills up every 10 minutes. That's too much data for me to process. So instead I browse the list of blogs available, pick the ones I like, and subscribe to it. (Functionality: views, blog-as-container-which-exists-only-ephemerally, flexible bookmark). 3) Much smaller blog site simply has one aggregated blog. Like what we have now. From the coding perspective, these are all just the same idea, with a different query generating the content.
On May 3, 2006, at 1:00 PM, Khalid B wrote:
In other words, they add polls on the form of any type of content that the admin assigns it to be. So, we can have blog polls, forum polls, page polls, ...etc.
You're talking about... dare I say it... a poll field type! Anyone who wants to attempt building such a beast for CCK is very welcome to. I will happily provide guidance.
On May 3, 2006, at 10:04 AM, Jonathan Chaffer wrote:
You're talking about... dare I say it... a poll field type! Anyone who wants to attempt building such a beast for CCK is very welcome to. I will happily provide guidance.
i'm torn about this: + you can actually have a *body* that describes the poll, or any other fields that make sense for the node you want displayed. i find it very weird that polls don't currently have a body, and if you want any text associated with them (other than the title/question), you have to enable comments and use those. - if it's just a field, it's harder (i think) to have tabs on the node page for doing interesting things with the poll. for example, polls currently allow you to view the poll (if you haven't voted) and the results as separate tabs. my patch in http://drupal.org/node/51561 adds yet another tab (for people w/ the right permission) to view the actual votes (by username or IP/host for anonymous). i'm not sure if/how CCK field types handle this sort of thing... if a field can register tabs when viewing the container node. if CCK fields can manage tabs for their container node, i'm all for this approach. -derek (dww) p.s. shouldn't we move this thread to http://groups.drupal.org/voting-systems ?
On May 3, 2006, at 1:49 PM, Derek Wright wrote:
On May 3, 2006, at 10:04 AM, Jonathan Chaffer wrote:
You're talking about... dare I say it... a poll field type! Anyone who wants to attempt building such a beast for CCK is very welcome to. I will happily provide guidance.
i'm torn about this:
- if it's just a field, it's harder (i think) to have tabs on the node page for doing interesting things with the poll. for example, polls currently allow you to view the poll (if you haven't voted) and the results as separate tabs. my patch in http://drupal.org/ node/51561 adds yet another tab (for people w/ the right permission) to view the actual votes (by username or IP/host for anonymous). i'm not sure if/how CCK field types handle this sort of thing... if a field can register tabs when viewing the container node.
Actually, on thinking about it, I think this is a model example for having a module-defined field (rather than field type). So we have: - The poll module defines a text field with multiple values, called "poll_choices". - Because it's a text field, text.module handles the input and validation, et cetera, and content.module handles the storage. - The module notices when a content type has poll_choices attached to it (probably in nodeapi) and handles voting, display, et cetera. - Fancy things like tabs are possible using the same mechanism. There's a little back-end work to enable this yet to do, but I think that's a fairly clean approach.
JonBob, you up to mentoring this if a student signs up? http://drupal.org/node/59958 Jonathan Chaffer wrote:
On May 3, 2006, at 1:00 PM, Khalid B wrote:
In other words, they add polls on the form of any type of content that the admin assigns it to be. So, we can have blog polls, forum polls, page polls, ...etc.
You're talking about... dare I say it... a poll field type! Anyone who wants to attempt building such a beast for CCK is very welcome to. I will happily provide guidance.
YES!!!!!! On 03.May.2006, at 01:00 PM, Khalid B wrote:
As someone who uses Drupal for a bit more than blogging, having polls in a post, the way Scoop sites have it, would make sense from a marketing research/political polling POV. Blog polls allow for immediate capturing of capture people's thoughts on a post. I honestly don't know why CivicSpace didn't steal that idea from the DailyKos crowd.
I think what we can do is stop having polls as their own type of content. They are an add on module, like upload (file attachments), nodevote (votes), ...etc.
In other words, they add polls on the form of any type of content that the admin assigns it to be. So, we can have blog polls, forum polls, page polls, ...etc.
It can be done the CCK way which Jonathan Chaffer (JonBob) outlined above. Another way is just the "regular" way, where the new blog module would display new form elements on any (or admin selectable) node types, and store its data in a poll table, perhaps backward compatible with the existing poll table. On 5/3/06, blogdiva@culturekitchen.com <blogdiva@culturekitchen.com> wrote:
YES!!!!!!
On 03.May.2006, at 01:00 PM, Khalid B wrote:
As someone who uses Drupal for a bit more than blogging, having polls in a post, the way Scoop sites have it, would make sense from a marketing research/political polling POV. Blog polls allow for immediate capturing of capture people's thoughts on a post. I honestly don't know why CivicSpace didn't steal that idea from the DailyKos crowd.
I think what we can do is stop having polls as their own type of content. They are an add on module, like upload (file attachments), nodevote (votes), ...etc.
In other words, they add polls on the form of any type of content that the admin assigns it to be. So, we can have blog polls, forum polls, page polls, ...etc.
Just a quick note of clarification -- I wasn't trying to imply that core should be SO stripped down tat we have NO modules. What I meant to ask was, 'What criteria make one module core-worthy but not another?' I think a much-streamlined core, with a secondary package of 'community tools,' or perhaps a 'Classic Drupal' module pack, would be a great step. But I've said that before. :) -Jeff -----Original Message----- From: Derek Wright [mailto:derek@dwwright.net] Sent: Tuesday, May 02, 2006 10:16 PM To: development@drupal.org; kb@2bits.com Subject: Re: [development] Time to remove poll module from core On May 2, 2006, at 8:05 PM, Khalid B wrote:
In another thread Derek asked why core has modules at all.
that wasn't me. i believe you're thinking of jeff eaton. i think drupal's "core" should contain some modules, even ones beyond the required 4 or 5. but, i'm in support of reducing the # of modules in core, and distributing the work of maintaining modules that are important, but not necessarily "core".
I'm of the mind that a "minimal core" should include those modules needed to get a site with a bunch of static pages (page nodes currently) up and running, and those internal/api modules that are of near-universal application (block, throttle, menu, path, etc.), and that's it. Everything from there on should be an add-on, either from a "first class citizen module" repository, an install profile that includes a dozen additional modules, contrib, or whatever. Just enough to be functional and whet a new user's appetite for more, and to give distribution builders a streamlined, low-cruft base to start from. On Tuesday 02 May 2006 23:03, Jeff Eaton wrote:
Just a quick note of clarification -- I wasn't trying to imply that core should be SO stripped down tat we have NO modules. What I meant to ask was, 'What criteria make one module core-worthy but not another?'
I think a much-streamlined core, with a secondary package of 'community tools,' or perhaps a 'Classic Drupal' module pack, would be a great step. But I've said that before. :)
-Jeff
-----Original Message----- From: Derek Wright [mailto:derek@dwwright.net] Sent: Tuesday, May 02, 2006 10:16 PM To: development@drupal.org; kb@2bits.com Subject: Re: [development] Time to remove poll module from core
On May 2, 2006, at 8:05 PM, Khalid B wrote:
In another thread Derek asked why core has modules at all.
that wasn't me. i believe you're thinking of jeff eaton.
i think drupal's "core" should contain some modules, even ones beyond the required 4 or 5. but, i'm in support of reducing the # of modules in core, and distributing the work of maintaining modules that are important, but not necessarily "core".
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Op maandag 1 mei 2006 20:08, schreef Angie Byron:
To be fair, half the reason FAPI took so long to troubleshoot/bug-fix is because it was completely new, never-before done and basically a complete rewriting of how Drupal does forms (which are used in almost every file ;)) from the ground up. There was no way to predict all the possible scenarios that would need to be accounted for until much, much later.
Yes. Some code exists and a lot does not. CCK might be cool and working. But it is far from ready to distribute *instead* of our default nodes. What about peoples data, for example. No. The changes I outline are serious, big monsters. Stuff, that we (a natural Developers problem?) tend to think "a couple of hours coding", "a simple update routine". Done in hours. No. We thought fAPI would take a few months. It took seven. I think that even the most realistic amoungst us would have laughed when someone said "this will take over half a year to get right". And we are still not there. Don't forget that either!
Most of the changes you outline either already have existing code in contrib or wherever to draw from, or are re-tooling/enhancement type of things (like FAPI improvements or X as nodes). I don't see a lot of "start completely over from scratch" stuff here, so I think "years" may be a tad bit unrealistic.
fAPI, when it hit core, was in development for a long while too. So you can safely add a few more months of extra development to my outlined seven. Also. We should not forget that besides the fAPI there were no other big projects going on. There were some AJAX improvements. And we had a huge amount of small issues in queue. But nothing of the same magnitude. Can you imagine the mess, if two such large projects are intervening eachother? Breaking eatchothers patches all the time? If two such projects drain all resources from our developersbase? I can. And hence I remain at my point of view, that we: * either need some very strong gatekeeper "thing" in place to manage core, and save it from breaking beyond usable ways. * Or can be assured that the first four to five months will get core in such a state, that it will take three-four times that time (a year, or more) to bring it back to a usable state. Call me a pessimist, if you want. But I manage to keep my deadlines within a 10% range because I plan "pessimistic". I call that realistic. People laughed at me, when back in november I said that "a release might not even be there at the end of february". So. Yes. Unless we plan more carefully this time, we will fall in the same traps again. And with the grown developers and userbase, talking about "years" is IMO not so unrealistic. Bèr
No. We thought fAPI would take a few months. It took seven. Eight.
Bèr Kessels wrote:
* either need some very strong gatekeeper "thing" in place to manage core, and save it from breaking beyond usable ways.
I guess Dries and I are very strong gatekeeper things. -- Neil Drumm http://delocalizedham.com/
On 2-May-06, at 12:35 AM, Neil Drumm wrote:
Bèr Kessels wrote:
* either need some very strong gatekeeper "thing" in place to manage core, and save it from breaking beyond usable ways.
I guess Dries and I are very strong gatekeeper things.
What special powers do you have? I'm guessing something to do with dismissing ridiculous patches with a single blow... (currently at Internet Identity Workshop in San Francisco trying to figure out a good standards-based replacement for Drupal dist auth) -- Boris
Op dinsdag 2 mei 2006 09:35, schreef Neil Drumm:
I guess Dries and I are very strong gatekeeper things.
I was not referring to gatekeeper as in 'let patches in or not'. That, I know, is done very well!! But as in: "Sorry folks, but CCK is a too big task to get into 4.8. Especially now that FooBar has put development upside down. Please do not pursue this goal of getting CCK in, and rather focus on getting FooBar stable. We can see if CCK might make it in afterwards". That kind of gatekeeping. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] Heeft het gebruik van Sympal gevolgen voor de eigendomsrechten van het gepubliceerde materiaal?: http://help.sympal.nl/heeft_het_gebruik_van_sympal_gevolgen_voor_de_eigendom...
On 30 Apr 2006, at 19:54, Larry Garfield wrote:
As for codenames, the 4.7/5.0 question is why they exist. :-) I'm game.
How about we call it 'development version'? That is by far the most accessible term for outsiders. Think about it. Code names are a developer-ism. -- Dries Buytaert :: http://www.buytaert.net/
On 5/1/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
On 30 Apr 2006, at 19:54, Larry Garfield wrote:
As for codenames, the 4.7/5.0 question is why they exist. :-) I'm game.
How about we call it 'development version'? That is by far the most accessible term for outsiders. Think about it. Code names are a developer-ism.
Development version is not unique. It is like "cvs" now, which confuses the heck out of so many people. Think about it: issues are against cvs version, but that is a shifting target. It was the "development version" at some point in time, but no one knows which release that cvs version ended up as. A unique code name identifies a version that is yet to be named with a numeric designation. It does not repeat, no risk of duplicates. So, issues, features, documentation, ..etc. can all be traced back to an identifiable release. The temporal aspect is not lost. Oh, and regarding what names, I like plain names, nothing fancy or too geeky, since this is shared to the outside name.
Neil, I think that this is a really reasonable time frame for new feature and development. It will force us to pick whatever big changes are most dear to us, and focus on one or two of them because we know we can't handle 5-6 of them. And as Sept. 1 draws nearer, only smaller features will be allowed. I support and encourage the Sept. 1 deadline, announced in advance, and hope that you stick to it militantly. Cheers, Robert Neil Drumm wrote:
What does everyone think of hard feature freeze on September 1st? That gives us approximately 4 months of development time.
A good time for a release after that would be one to two months later, but in reality it would be "when it is ready."
That is only 4 months and I am seeing a lot of ways we want to break everything; this will probably be 4.8 and not 5.0. I don't think making roadmaps for contributions we can't control is too productive, but if we did have a roadmap, we would have a clear idea of what we can call 5.0.
On 30 Apr 2006, at 03:04, Neil Drumm wrote:
What does everyone think of hard feature freeze on September 1st? That gives us approximately 4 months of development time.
A good time for a release after that would be one to two months later, but in reality it would be "when it is ready."
That is only 4 months and I am seeing a lot of ways we want to break everything; this will probably be 4.8 and not 5.0. I don't think making roadmaps for contributions we can't control is too productive, but if we did have a roadmap, we would have a clear idea of what we can call 5.0.
I was about to suggest the exact same, and the exact same date. Whether it will be called 4.8 or 5.0 remains to be seen (depends on the changes that will make it). -- Dries Buytaert :: http://www.buytaert.net/
participants (30)
-
Adrian Rossouw -
Angie Byron -
blogdiva＠culturekitchen.com -
Boris Mann -
Bèr Kessels -
Chris Johnson -
Darrel O'Pry -
Derek Wright -
Dries Buytaert -
Dries Buytaert -
Earl Miles -
Gabor Hojtsy -
Gerhard Killesreiter -
info＠urbits.com -
Jakub Suchy -
James Gilliland -
Jeff Eaton -
Jenny Hsueh -
Jeremy Epstein -
Jonathan Chaffer -
Karoly Negyesi -
Khalid B -
Kieran Lal -
Konstantin Käfer -
Larry Garfield -
Morbus Iff -
Moshe Weitzman -
Neil Drumm -
Robert Douglass -
sime