When some patches are more equal than others, I just can't continue. If one of my patches had only tenth the code style errors actions patch had (and I am not talking of the critical bug it has, it's not easy to see albeit module_implements had a five line long comment over the same bug) there would have been no chance that patch got commited. I complained long and hard in the issue queue over the years for helding up this or that important feature over a space or two. Neither the book patch nor the menu fixes are in despite they are tested and supported. I guess my life is so entwined with Drupal that I won't be able to stay away for long. Anyways, I will take a few days break. Regards, NK
Ps. Of course, the happenings around deletion API put me in a mood where the aforementioned happenings was just too much.
On 30 Jun 2007, at 16:55, Karoly Negyesi wrote:
If one of my patches had only tenth the code style errors actions patch had (and I am not talking of the critical bug it has, it's not easy to see albeit module_implements had a five line long comment over the same bug) there would have been no chance that patch got commited. I complained long and hard in the issue queue over the years for helding up this or that important feature over a space or two.
No need to point the finger at John. Rather than complaining, you should be happy and excited about John's work, and you should be grateful for the time and energy he put into the actions module. Besides, most of your big patches had various critical bugs too. Is that a shame? I don't think so. It happens and usually we are quick to fix those. That's why we're still in "development mode". If you look at the actions.module's issue queue, you'll see that it got a dozen great/detailed reviews. It's something to be happy about, not something to be frustrated/jealous about. :)
Neither the book patch nor the menu fixes are in despite they are tested and supported.
People can't review dozens of patches a day. I spent several hours a day reviewing patches already and other people to do. A decent review takes 30 minutes, and sometimes more. (I was traveling last/this week and I announced that well in advance -- see the code freeze extension e-mail.) -- Dries Buytaert :: http://www.buytaert.net/
patch got commited. I complained long and hard in the issue queue over the years for helding up this or that important feature over a space or two. No need to point the finger at John. Rather than complaining, you should be happy and excited about John's work, and you should be grateful for the time and energy he put into the actions module.
Besides, most of your big patches had various critical bugs too. Is that a shame? I don't think so. It happens and usually we are quick to fix those. That's why we're still in "development mode".
Then I was not communicating clearly enough. I thought starting with a quote from the Animal Farm will be clear enough but it was obviously not: I am deeply disappointed with the fact of the commits and non commits. I am not pointing at John, if anyone, then my finger points to Dries for making an exception here. Or to the reviewers for not catching the many code style errors. Or I am just frustrated with deletion API and what I perceive as unfairness with the book patch. Or I just might be sleep deprived. Pick whatever. NK
Karoly, On 30 Jun 2007, at 19:56, Karoly Negyesi wrote:
Then I was not communicating clearly enough. I thought starting with a quote from the Animal Farm will be clear enough but it was obviously not: I am deeply disappointed with the fact of the commits and non commits. I am not pointing at John, if anyone, then my finger points to Dries for making an exception here. Or to the reviewers for not catching the many code style errors. Or I am just frustrated with deletion API and what I perceive as unfairness with the book patch. Or I just might be sleep deprived. Pick whatever.
While I try to listen to all input, Drupal has never been a democracy. I try my best to resolve conflicts, to listen, to be fair, and to balance all the concerns and the input I get. But at the end of the day, it's my job to decide what patches should go into core and what patches shouldn't go into core. By design, it is impossible to please everyone or to be 100% fair. I hope this doesn't come as a surprise to you. Furthermore, it is impossible for me to review every single patch every time it was updated. This means I'm forced to prioritize my own code reviews, just like you or anyone else prioritizes yours. I focus my time on patches (i) that people tell me are important or (ii) that align well with my vision for Drupal. Anyway, if everyone prioritizes his or her code reviews, patches that people care about, tend to get many reviews/helpers. Patches that people don't really care about are sometimes forgotten or neglected. This isn't necessarily a bad thing, although it can be frustrated for those who are extremely passionate about his or her patch. Granted, sometimes important patches are neglected because they have a high barrier to entry. This is highly unfortunate and I try to deal with those as time permits. I try to review a lot of these patches. Anyway, we're currently nearing the code freeze, and people tend to forget about all other patches except their own. These are inherently crazy times. I don't know why, but sometimes people think of the code freeze as the end of the world, and their patch being the magic hero that comes in to save the world just in time. Of course, it is nothing like that, and there is nothing wrong with patches being postponed. Maybe the code freeze frenzy blinds you too? Consider to take a fresh perspective on why the actions module went in and why the book module improvements haven't yet. I'll share you my perspective ... I agree with parts of the book patch, and I disagree with other parts of the book patch. Regardless my disagreements, I don't think the book patch is super-high priority. Frankly, there is no harm done when the book improvements don't make it into Drupal 6. Now contrast this with the actions module. Personally, I think the actions module is a "true enabler". It allows modules to interoperate in new ways, and it instantly gives us many great new features. Getting the actions module into Drupal 6 is important as it is something we want to start building on as soon as possible. I spent 3+ hours reviewing the actions module and I think the underlying design is sound; I'm confident that outstanding problems can be fixed easily. Lastly, the delete API is also more important than the book patch so that's why I spent most of today pondering about the delete API. I care a lot about what the delete API tries to accomplish, and that's why I think it is so important to do it right, and why I'm not happy with a half- baked solution. As always, you're welcome to provide me constructive feedback. I'm sorry to "deeply disappoint" you but maybe you can elaborate more about why you are unhappy with the recent "book - actions - delete API" events? What's wrong with my perspective? Let's talk more about it ... :-) -- Dries Buytaert :: http://www.buytaert.net/
core and what patches shouldn't go into core. By design, it is impossible to please everyone or to be 100% fair. I hope this
to start building on as soon as possible. I spent 3+ hours reviewing the actions module and I think the underlying design is sound; I'm
Sure it is. I have never contented the merits of the actions system, here. The perceived problem here was fairness. If you spent 3+ hours reviewing it then surely you have seen the code style errors which would have hold back any other patch. Add to that I was very tired and frustrated to see the many hours Chad and Peter poured into the relevant patches apparently go for nothing (note: not my patches) -- and that's about it. Obviously, I will restart either late today or tomorrow, I would like to make the bugfix period as short as possible, just before the original freeze date I have started to collect some review pledges from dojo people... more on this later. Peace, ChX
Let me sidetrack this thread to give some insight into why some people feel strong about the book patch. Dries Buytaert wrote:
Maybe the code freeze frenzy blinds you too? Consider to take a fresh perspective on why the actions module went in and why the book module improvements haven't yet. I'll share you my perspective ...
I agree with parts of the book patch, and I disagree with other parts of the book patch. Regardless my disagreements, I don't think the book patch is super-high priority. Frankly, there is no harm done when the book improvements don't make it into Drupal 6.
"Unfortunately" how the book module works, (or not works for that matter) has a high impact on the community. The Drupal Handbooks, as the main source of information for beginners and aspiring developers alike is organized with this module. Just as project module has a high impact on development in the community, book module has a high impact on documentation. Project module being in the contributions repository has a good chance of being developed with a higher pace then book module, which is tied to the Drupal release cycle. By reading through the book module patch comments, it seems obvious, that people commenting/working on the book module improvements did not take Dries' concerns seriously about where the module is going to (although he repeated them many times), and did not (visibly) investigate other paths to take. Now that project module is maturing (even more so with the current Google Summer of Code projects), bigger problems come from lack of two technical solutions in the community: content and user management. These include organization of the handbooks and often spam (content, user) prevention and deletion. People take a lot of time removing spam and blocking spammy users and as the book module patch comments show, they think the UI of the current book module could be made much better for the handbooks. Unfortunately this only describes why the book module patch could be important, but does not help solving the UI problems Dries has with it. These are explained better in the issue though. Issue: http://drupal.org/node/146425 Gabor
Unfortunately this only describes why the book module patch could be important, but does not help solving the UI problems Dries has with it. These are explained better in the issue though.
The UI can be changed past freeze. The billions of API changes can not. Please get it in today.
Karoly Negyesi wrote:
Unfortunately this only describes why the book module patch could be important, but does not help solving the UI problems Dries has with it. These are explained better in the issue though.
The UI can be changed past freeze. The billions of API changes can not. Please get it in today.
Well, maybe I was not clear enough. Dries has problems with the book concept being even more reinforced on the interface. This is a result of the overall design of the module, which shows in the database and in the API functions, not only on the UI. Anyway, as I said, the technical details are to be found in the issue, I tried to underline the possible importance of the change for the Drupal documentation as a whole, not argue about the technical details of the issue, which should be done in the issue. Gabor
As pwolanin has said before, this has 0% to do with the UI. This has nothing to do with the way users see it work. All this patch does is bring the book system up to date with the apis we have available to us. On Jul 1, 2007, at 7:16 AM, Gabor Hojtsy wrote:
Karoly Negyesi wrote:
Unfortunately this only describes why the book module patch could be important, but does not help solving the UI problems Dries has with it. These are explained better in the issue though. The UI can be changed past freeze. The billions of API changes can not. Please get it in today.
Well, maybe I was not clear enough. Dries has problems with the book concept being even more reinforced on the interface. This is a result of the overall design of the module, which shows in the database and in the API functions, not only on the UI.
Anyway, as I said, the technical details are to be found in the issue, I tried to underline the possible importance of the change for the Drupal documentation as a whole, not argue about the technical details of the issue, which should be done in the issue.
Gabor
Dear Gabor, I think there is considerable confusion about what the book patch *does* do. I encourage everyone who is unsure at this point to look at the summary a wrote last night and note that many people who are on the documentation team (as I am) have supported the changes. http://drupal.org/node/146425#comment-267769 If I wasn't convinced that these changes would substantially enhance our ability to manage the d.o handbooks, I would not have bothered to write the code. If you catch me on IRC today I'd be happy to discuss with you or anyone what's actually in the code. -Peter On 7/1/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Let me sidetrack this thread to give some insight into why some people feel strong about the book patch.
Dries Buytaert wrote:
Maybe the code freeze frenzy blinds you too? Consider to take a fresh perspective on why the actions module went in and why the book module improvements haven't yet. I'll share you my perspective ...
I agree with parts of the book patch, and I disagree with other parts of the book patch. Regardless my disagreements, I don't think the book patch is super-high priority. Frankly, there is no harm done when the book improvements don't make it into Drupal 6.
"Unfortunately" how the book module works, (or not works for that matter) has a high impact on the community. The Drupal Handbooks, as the main source of information for beginners and aspiring developers alike is organized with this module.
Just as project module has a high impact on development in the community, book module has a high impact on documentation. Project module being in the contributions repository has a good chance of being developed with a higher pace then book module, which is tied to the Drupal release cycle.
By reading through the book module patch comments, it seems obvious, that people commenting/working on the book module improvements did not take Dries' concerns seriously about where the module is going to (although he repeated them many times), and did not (visibly) investigate other paths to take.
Now that project module is maturing (even more so with the current Google Summer of Code projects), bigger problems come from lack of two technical solutions in the community: content and user management. These include organization of the handbooks and often spam (content, user) prevention and deletion. People take a lot of time removing spam and blocking spammy users and as the book module patch comments show, they think the UI of the current book module could be made much better for the handbooks.
Unfortunately this only describes why the book module patch could be important, but does not help solving the UI problems Dries has with it. These are explained better in the issue though.
Issue: http://drupal.org/node/146425
Gabor
Peter Wolanin wrote:
Dear Gabor,
I think there is considerable confusion about what the book patch *does* do.
I encourage everyone who is unsure at this point to look at the summary a wrote last night and note that many people who are on the documentation team (as I am) have supported the changes.
Well, no wonder people are/were confused. All of Dries' comments about the resulting code/UI not being a generic outliner were said in the issue, while it was marketed under the following title: make book module into a better "outliner" This was renamed two days ago in comment #121 to: improve book module: use nodeapi and menu API with the comment: "Changing title as I should have done at about #63 above". If people don't understand what it does, or if they put higher expectations against it, it does have a lot to do with how the patch was marketed... Gabor
On 7/1/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Well, no wonder people are/were confused. All of Dries' comments about the resulting code/UI not being a generic outliner were said in the issue, while it was marketed under the following title:
make book module into a better "outliner"
This was renamed two days ago in comment #121 to:
improve book module: use nodeapi and menu API
with the comment: "Changing title as I should have done at about #63 above".
If people don't understand what it does, or if they put higher expectations against it, it does have a lot to do with how the patch was marketed...
To be fair to Peter, he started out with the goal of making a better outliner. But in comment #33 Dries told him to do less with the patch and focus on "Proper integration with the menu system." He's been continually scaling the patch back since then trying to find some patch that would be committable. Now has arrived at the very modest goal of simply cleaning up the book module. andrew
participants (6)
-
andrew morton -
dmitri -
Dries Buytaert -
Gabor Hojtsy -
Karoly Negyesi -
Peter Wolanin