Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By irwin on
In the RC release thread, the following discussion arose:
http://drupal.org/drupal-4.6.0-rc#comment-31276
I had a minor problem with a feature disappearing on me - in this case, the Categories block. While the fix was relatively easy, I can imagine this kind of issue happening on some other sites where the feature removed might be a bit more complex with a fix that's not so obvious.
There were three problems, in my opinion, with how this change was handled:
1) There was no indication on the site that this feature was being removed.
2) There was no suggested alternative on the site.
3) (less of an issue) There was no period to allow users to phase out or replace the feature.
Drupal is a moving target and its back end and front end are always improving and changing. What I don't want to encourage is stagnation of either old, unused features or a bad architecture. However, there needs to be a graceful way to help users make the transition from one Drupal version to another. If we don't do this, users will soon be afraid to upgrade Drupal, and then the community will have to deal with the issue of having a dozen unsupported versions of the software that people are continually asking for help about or requesting features for.
While I posted a number of (poor) suggestions in the thread above, I might suggest instead:
For every single CVS change log made, a reference to an issue must be made.
Basically, changes shouldn't be made to core without some kind of documented justification. If someone is going to remove the Categories block, then they should first create an issue that says, "Categories block is not considered useful. Suggested alternative is to use taxonomy_html". When they check in their CVS code that removes the feature, provide a link to the issue.
I know that at this point, people are screaming, "But that'll be painful! That's going to flood the Issues board with all kinds of requests!" Well, not really - I checked the CVS log messages and there's nothing there that can't be linked to an issue... "PHP5 modifications" can be sorted under node/9292. If you're making improvements to query speed, then link to an issue related to performance in that module, and so forth. It may slow down development slightly because you'd have to look up issues before making code changes, but it might make it easier to follow minor changes and revisions because the issues would be searchable, and can accept user replies and feedback. If you're adding a feature, then create an issue about the feature, link to it, and close the issue right away.
Ideally (but I don't know if this is possible), checking in a CVS report will automatically add that log message to the issue so that people who are following the issue can see in which revision the patch was applied and can review it.
Anyway, that's just a suggestion... there might be flaws in this, please let me know. It might not even be a good idea - let me know about that, too. Thank you!
Comments
The problem with this kind
The problem with this kind of approach is that it is likely to increase the workload of the core developers that do the cvs commits. They are already trying hard to make the cvs messages meaningfull, but any more would probably be too much to ask for considering that they do this in their spare time. I have an alternative suggestion: Some long time Drupal user (no development skills needed) could subscribe to the devel and cvs list and transcribe the more technical lingo into something more readable and publish this on drupal.org. We could have an extra forum for this and thus an RSS feed to which people could subscribe. This is a great opportunity for the less technical Drupal users to contribute back to the community. If somethign is unclear, there will always be developers available to explain things (for example in #drupal).
--
If you have troubles with a particular contrib project, please consider filing a support request. Thanks. And, by the way, Drupal 4.6 will support PHP 5.
--
Drupal services
My Drupal services
While this is another
While this is another option, I don't think that the long time Drupal user who would be assigned to do this task would feel very entertained by this job. It is one thing to ask developers to reference an issue before making commits as part of a mandatory workflow, but another to ask someone to wade through a few hundred CVS messages and try to make heads and tails of some of them. Many of them are VERY cryptic. Also, the developer knows what he's doing - in his head, he has a perfect mental model of what he's trying to do.
Besides, someone who can understand CVS messages isn't likely to be just a user - chances are it'll be someone who already knows technical jargon.
What the coders need to do is to is to help share what's going on inside their heads, so the rest of us know why something is being changed.
There's a little quote that goes around called "If it ain't broke, don't fix it". Unfortunately, Drupal is far from being a perfect piece of software. If something is broken, it should be an issue somewhere - and if code is changed, then the CVS commit message should refer to that issue.
Of course, the tradeoff between writing an Issue # in your CVS commit might be inconsequential to answering support queries about where feature X went, why Commit Y was made, or why commit Z broke the system, or how come Code Block 1 and Code Block 2 are so damned ugly and strange. You can just look at the CVS log, go back to the Issues for more information, and then learn design rationales without having to contact the code author or dig it up from your memory. A lot of people contribute to Drupal - a lot of people also forget why something was programmed in a certain way.
In any case, even if it's not enforced, perhaps a developer can try it this way for a month or two just to see if it's beneficial at all.
-- Irwin
Drupal at work -> http://suikoden.mine.nu
Suikoden-themed Role-playing Game.
The point is that there are
The point is that there are at the moment two people who have and use core cvs write access You could argue that there should be more, but that is just not how Drupal works. Those two people are already trying hard to do what you proposed (see here for an example http://drupal.org/cvs?commit=14090) (Note: I am speaking about core Drupal only). There almost always is a link to an issue, the removed taxonomy block is an exception. If the linked issues are easy enough to understand for a user is another question. Many of them probably aren't. That is why I thought it would be nice to have somebody who is somewhat (but not completely) into technical stuff and would translate the important issues into plain English.
I was thinking about something similar to the Kernel-Traffic news page (http://www.kernel-traffic.org/kernel-traffic/latest.html) which summarizes the discussions on the Linux Kernel mailinglist.
To be brutally frank (as I always am): I do not think that any developer will do this. Developers either develop Drupal because they like to do that or (rarely) because they get paid to. In both cases the writing of maybe extensiv, non-technical commit messages or issues is simply not high on the agenda.
I also think that this task should not be done by a developer, because it would end up being too technical again.
I think this is really a great opportunity for somebody (or a group of people) to do some service for their fellow Drupal users. If you think it is not entertaining, then you will understand why developers keep issues and commit messages to the bare bones. ;)
--
If you have troubles with a particular contrib project, please consider filing a support request. Thanks. And, by the way, Drupal 4.6 will support PHP 5.
--
Drupal services
My Drupal services
I don't mind that you're
I don't mind that you're frank. I do still believe that developers here should try to make sure that the reason behind their changes is written in an issue that people can search for and talk about. It's easier to create an issue that refers to new code, close it, and then you know exactly where and when this code appeared as opposed to finding out there's a problem, opening an issue, and then trying to discover exactly why you might have put that code in there in the first place.
The idea here is that if you have an itch, tell people about it before you scratch it. ;) That way, we don't look at you strangely while you're scratching.
But let's go with your suggestion of getting people to help translate changelogs so forth into readable format... what kind of mechanism do we have in Drupal to put the wheels into place? So far the CVS logs don't seem to allow comments or amendments directly on the site.
I must also mention that if absolutely NO ONE ELSE except for me thinks this is a good idea in general, then I'll just shrug my shoulders and let it slide.
-- Irwin
* Drupal at work -> http://suikoden.mine.nu (Suikoden-themed Role-playing Game.)
* My other Drupal site -> http://scrapped.mine.nu (Video-game & Anime-themed Blog)
no mechanism needed
As Killes said, a forum could be created, and you or anyone could post there the translations from jargon to English :) Think Kernel traffic or Zend newsletter, especially the summary of Zend newsletter :D
Most core commits has an issue number in it, that's true.. However, I tend agree with Killes: I will not waste my time to evaluate whether my issue is understable to a non-developer. If someone asks about it, I may try to explain, especially if he publishes a beautified version of that talk.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
cryptic commit messages
Dries always uses the number if the issue when fixing something. That makes a perfect changelog.
The most of the core improvments and changes are already discussed in detail in the issues. Very often, issues are even discussed on the ML.
So I agree with your point that its hard to get to the information, but i disagree with that it would not be there. We do not need more information, but we need someone to gather it and summarise it.
---
If this solved you problem, please report back. This will help others whom are looking for the same solution.
Next time, please consider to file a support request.
[Bèr Kessels | Drupal services www.webschuur.com]
Does anyone here have a
Does anyone here have a battle-plan suggestion for this? Should I just install Drupal head, go through CVS changelogs, and run testcases through what I perceive to be the changes, and update issues/some page accordingly?
This actually strikes me significantly as a formalized QA team more than just "guy who translates CVS messages". Someone with a HEAD installation of Drupal somewhere could update the site, go through the CVS changelog, test the change, and then close bugs with an explanation of the issue. If there's a node dedicated to the release, a note can be added if user feature behaviour was changed, or if developer APIs were changed.
I do not subscribe to the ML so that is potentially my first mistake but the Drupal ML is too high-traffic for me to keep up.
-- Irwin
* Drupal at work -> http://suikoden.mine.nu (Suikoden-themed Role-playing Game.)
* My other Drupal site -> http://scrapped.mine.nu (Video-game & Anime-themed Blog)
I don't think you'd need to
I don't think you'd need to subscribe to the list. You should look at the core commit messages and try to understand what they are about, read the comments on the issue, and translate it to plain Engilish if the issue is of importance to the user that installs Drupal or uses Drupal on a site. You could collect your findings on a single forum post or we open up an extra forum for this. At release time Dries could then reference the posts he thinks are important in his release statement. You could also make an extended version of a releases statement.
--
If you have troubles with a particular contrib project, please consider filing a support request. Thanks. And, by the way, Drupal 4.6 will support PHP 5.
--
Drupal services
My Drupal services