"I'm disappointed by the freeze"
On 20 Feb 2006, at 10:29, Bèr Kessels wrote:
Updated by: Bèr Kessels
Personally I am getting more and more dissapointed by the actual "frozenness" of HEAD. So if nothing changes in the current behaviour, why should this issue wait?
Ber, you can stop sprinkling "I'm disappointed by the freeze"- messages all over drupal.org. There is no need to attach them to each issue you update. Let's use the issues for technical discussions rather than for spreading FUD. Thanks. We can continue to discuss this in a central place (this mailing list, this thread) if you wish. -- Dries Buytaert :: http://www.buytaert.net/
Op maandag 20 februari 2006 11:34, schreef Dries Buytaert:
Ber, you can stop sprinkling "I'm disappointed by the freeze"- messages all over drupal.org. There is no need to attach them to each issue you update. Let's use the issues for technical discussions rather than for spreading FUD. Thanks. We can continue to discuss this in a central place (this mailing list, this thread) if you wish.
Two people reopened that specific thread with a question whether or not we should press that specific issue into 4.7 I reacted to that, with a message about "we were in a feature freeze, that is why this particular (rather important issue) is on halt. However, if there are still a lot of features are still going in, then why not this one?" And yes, I am dissapointed. :) We (that includes me) fail to get the 4.7 out of the door. Why? Is that really only due to lack of reviewers? Lack of reviewers, is, IMO, only a part of the puzzle. Maybe we should focus on the "how to get 4.7 out" instead? My first shot on the "why" is, indeed, "because we are not strict enough in what to allow and what not". This behaviour has two downsides: 1) new issues arise as we introduce new features. 2) people will remain focussed on their pet peeves, becuase there still appears a small chance that they get in. Bèr
Ber, you can stop sprinkling "I'm disappointed by the freeze"- messages all over drupal.org. There is no need to attach them to each issue you update. Let's use the issues for technical discussions rather than for spreading FUD. Thanks. We can continue to discuss this in a central place (this mailing list, this thread) if you wish.
Two people reopened that specific thread with a question whether or not we should press that specific issue into 4.7 I reacted to that, with a message about "we were in a feature freeze, that is why this particular (rather important issue) is on halt. However, if there are still a lot of features are still going in, then why not this one?"
No, you're creating FUD. The past 3 weeks there have been significantly less patches. Is that because I committed new features? I don't think so. Yes, occasionally a critical feature slipped in, but overall the stability of Drupal HEAD has been improving on a daily basis. Feel free to proof me wrong, but I don't think I committed sweeping changes that didn't need committing. Everyone knows we're in a feature freeze and that new features have little or no chance of being committed. In another issue (http:// drupal.org/node/18018#comment-74279) you used false facts to push your political message through people's throat. Tell me, what is wrong with people working on new features during the code freeze? These kind of issue follow-ups are counter-productive and serve no purpose other than to create FUD. If you think you can do a better job, you're welcome to take over and coordinate the Drupal 4.7.0 release process. -- Dries Buytaert :: http://www.buytaert.net/
political message
Aside from Ber, I can barely remember anyone mentioning politics in regard Drupal. There will be an election in April here and I am seriously sick from even _hearing_ this word. So please stop and roll patches :) Thanks a lot Karoly Negyesi
On Mon, February 20, 2006 12:37, Karoly Negyesi wrote:
political message
Aside from Ber, I can barely remember anyone mentioning politics in regard Drupal. There will be an election in April here and I am seriously sick from even _hearing_ this word.
Okay, i will gladly call it something different. "Make noise around an issue"? "spread the word to get it reviewed"? I am *not* talking about bugs. IMO the system works great for that. We get a lot of them fixed. I am talking about "nice", more complex features. Anyone who disagrees with me that it is hardly impossible without killes-patience, or a cross-community frenzy like FAPI-team-ups to get anything bigger then a five liner in, please speak up.
So please stop and roll patches :)
Wat? even more patches to sit on my todolist? Some keywords: "codemonkeyXs/better archive system", "simple inline images", "online status by CSS classes", "let _links return structured data, the one-but oldest issue", "renice the upload modules code". Those are a few patches, from the top of my mind, that are around for a looong while. Got loads of reviews, loads of people saying things about them, and lots of "noise", "word-spreading" had been done. All have different issues why they are still around. All seem to have rather nice code, or had(have) very good code even. So? what made ALL the open feature patches still be around? And what made others slip in after one or two reviews? What made some features get in and break stuff, while others went trough tens of rehauls and are still "not perfect", or even more often, are orphaned because the maintainer gave up? Is that coïncidence? I think not. You can call it "teamwork", "hanging around on IRC", or "mailing reviewers personally" or anything else. I call that politics. And last, but absolutely certainly not least: I am *NOT* trying to say Dries is doing a bad job, not at all! I made sure to speak about "WE"! We, including me: I am to blame too, others might feel the same. I am not pretending that I know all the stuff better (I see a few particular problems, that I try to fix), and I am NOT telling Dries should do his job better. Please, no! I am (trying to, at least) saying that we, all of us who really want 4.7 to stabilise, should try to hold back our features, and put more efforts in "real" 4.7 stuff. And that those that want 4.7 to go out of the door, should try to hold back those that seem to care less about that and try to put some pressure on small features before 4.7, and thus delaying that release. Bèr
Some keywords: "codemonkeyXs/better archive system", "simple inline images", "online status by CSS classes", "let _links return structured data, the one-but oldest issue", "renice the upload modules code".
Yes, sometimes it takes persistence to get a patch accepted. AFAIK the above mentioned patches were not committed based on technical reviews. I'm pretty sure I reviewed all of them, often on more than one occasion. That said, I'd love to see them become part of Drupal 4.8/5.0. Keep working on them! -- Dries Buytaert :: http://www.buytaert.net/
Yes, sometimes it takes persistence to get a patch accepted.
Persist and prevail. My first big contribution was the hook_db_rewrite_sql patch. On Dec 23, 2004 I contributed the first patch, and Dries' first comment began with "I'm not likely to commit this". A mere 21 versions later (real revisions, not the doh-i-attached-the-wrong- file variety), on January 16, 2005 it was committed. The issue http://drupal.org/node/18260 is open since last March, true, but the first patch happened in October only and saw only 10 patches (I saved the issue HTML and grep'd for Attachment:). I used db_rewrite_sql as an example because a) you can't say I had the advantage as a "household name" -- back then I was a rookie but you *are* a household name, longer than I am b) in the end, rewrite sql was three times the size of this patch. I could continue long analysing the similarities between the db_rewrite patch and this one but I won't. Regards NK Ps. As you all know, I am for the structured links patch. I even rerolled it once or twice.
On Tue, February 21, 2006 00:45, Karoly Negyesi wrote:
The issue http://drupal.org/node/18260 is open since last March, true, but the first patch happened in October only and saw only 10 patches (I saved the issue HTML and grep'd for Attachment:).
I was actually hoping that people did not start about separate issues. Every issue has a reason why it is not in, if you dig deep enough. This particular issue, however, goes back WAY furhter. It started in the time when we still mailed patches over the ML! When we manage to not pick at specific issues and particular patches, we come to the point that Robert Douglas presented in Amsterdam. The chaotic, open, nonstructural, non chronological way of working, makes it so, that even now, after a huge release slip, certain features can still make it in. While others that are maintained by single developers did not even make it when we were still "officially" open for features. I mentioned too, that features only seem to make it with either killes-patience (I was referring to the enourmous effort he made to get the revisions revised) or with a lot of luck ("luck", since I am no longer allowed to call it politics :)). We must recognise that not all of us have that patience, or even that time, but that we do produce code fixes and nice features. Robert recognised it, and even spent his complete presentation on this. I see this "chaos" as one of the reasons why we are still delaying and still moving the release forward and forward. I try to get this release out sooner, not only by reviewing patches (for which I simply have not enough time, to do structurally) but also by pointing my fellow developers at the fact that their persistance in a certain issue/feature will delay the release. And last: I know that release managers often have the guts and power, to revert changes, or take out complete features, if these endanger the release date. I think it is not bad to take out certain changes that are holding back our release and save that particular feature for post 4.7. Is this maybe a route to take? Bèr --
The chaotic, open, nonstructural, non chronological way of working, makes it so, that even now, after a huge release slip, certain features can still make it in. While others that are maintained by single developers did not even make it when we were still "officially" open for features.
There has never been an official release date; only estimated timelines. So, "delay" might be better than "slip". That said, we all agree that it is taking us longer than expected. Yes, I screwed up estimating the release cycle. I felt it was 'safe' to provide a rough estimate of when Drupal 4.7.0 might be released. I screwed up because I underestimated the overall impact of the forms API, because I underestimated the complexity of some bugs, and because we had a slow start (it took a while before we managed to mobilize contributors/developers to start fixing bugs). However, in my view, the occasional (critical) feature that got committed had no or very little impact on the delay. I haven't committed sweeping new features in weeks. The main reason is the forms API, the complexity of bugs, and the resource availability.
I mentioned too, that features only seem to make it with either killes-patience (I was referring to the enourmous effort he made to get the revisions revised) or with a lot of luck ("luck", since I am no longer allowed to call it politics :)). We must recognise that not all of us have that patience, or even that time, but that we do produce code fixes and nice features.
The revision patch took a lot of time an energy to get committed. Not only from Gerhard (killes) but also from me; while Gerhard obviously did most of the work, I spent hours reviewing and benchmarking that patch. If you don't have the time or persistence it takes to work on your patch, that is OK. If your patch is important enough, someone will step forward to help work on your patch. If that doesn't happen, don't blame the system. I won't commit patches that I don't fully support. As for 'luck' or 'politics'. Yes, some patches are more easily accepted than other patches. The reason can be manifold; sometimes I don't see why the patch is needed, sometimes it takes more time and energy to convince me that the proposed changes scale, sometimes my attention goes to a patch that I feel is more pressing, sometimes the reviewers have conflicting views, etc. Some decisions are easy, some decisions are hard. That's life. Frustrations are included. -- Dries Buytaert :: http://buytaert.net/
Op dinsdag 21 februari 2006 13:53, schreef Dries Buytaert:
The revision patch took a lot of time an energy to get committed. Not only from Gerhard (killes) but also from me; while Gerhard obviously did most of the work, I spent hours reviewing and benchmarking that patch.
If you don't have the time or persistence it takes to work on your patch, that is OK. If your patch is important enough, someone will step forward to help work on your patch. If that doesn't happen, don't blame the system. I won't commit patches that I don't fully support.
For which I thank you two a lot! IMO this revisions patch needs more kudo's then the forms API, because the latter was caried by a whole lot of shoulders, while the first mostl by four shoulders. What concerns me more is how to deal with this in future. * How to make sure 4.8 comes quicker and more 'in time'. * How to make sure that we can get bigger changes in, better and easier(profiles as nodes, taxonomy.module's code overhaul, upload module partly rewrite, aggregator.module is lagging behind with the current technlogies, just to name a few that i suspect will become hot 4.8 issues) Did Roberts idea of the cooker get any follow-ups yet? -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
Bèr Kessels wrote:
Did Roberts idea of the cooker get any follow-ups yet?
No, mostly because I haven't had time to pursue it. I'll summarize quickly here for people who weren't in Amsterdam. The GOAL: Assist Dries and whoever else is wearing the "core committer" badge process patches more efficiently by separating the ones with clear merit from those that are clearly not ready, clearly not desirable, or otherwise not worthy of Dries' 5 minutes. The PROPOSAL: Adjust the user privileges and workflow of the issue queue so that there are, in fact, two queues: -- the first queue is the mess we now know and love. Everything goes into it and it is everyone's task to evaluate the issues. The difference is that there is a user role that has the extra-magical-superhero power to promote an issue to the second queue. -- In Amsterdam I called this second queue the "pressure cooker" because patches/issues that are inside of it are known to be the ones that Dries will focus on. These are the ones where everybody should be paying extra special attention because Drupal core is about to change in some way. These are the ones that could hold up a release candidate because they are critical. The advantage of having them separate is that they will, by nature, receive more attention. And the attention of the important people. In Amsterdam I also introduced the idea of having the issue queue be a real fifo queue, but lets not discuss that right now. In summary, the most important two aspects of my proposal are: 1) there is a user role that is more empowered to make decisions about patches than they are today. This group of trusted developers has the magical power to promote an issue to the "pressure cooker". 2) the "pressure cooker" organizes the queue into wheat and chaff. When Dries reviews patches, he knows that unless someone trusted has promoted it into the pressure cooker, he doesn't need to fool with it (he still can if he wants, of course). This will negate the "pester-Dries-on-IRC" necessity since any issue in the pressure cooker will automatically get his attention. It also galvanizes the community around the issues in the pressure cooker since it is clear that those are the issues being taken seriously, the ones that are likely to "make it". cheers, Robert
Nice, thanks for your summary: Op woensdag 22 februari 2006 11:58, schreef Robert Douglass:
2) the "pressure cooker" organizes the queue into wheat and chaff. When Dries reviews patches, he knows that unless someone trusted has promoted it into the pressure cooker, he doesn't need to fool with it (he still can if he wants, of course). This will negate the "pester-Dries-on-IRC" necessity since any issue in the pressure cooker will automatically get his attention. It also galvanizes the community around the issues in the pressure cooker since it is clear that those are the issues being taken seriously, the ones that are likely to "make it".
Here i foresee a problem, one that you might have thought of already: Often patches and fixes are abandoned after a while. I do think that the cooker system will greatly reduce that amoutn. But what if suddenly a few cooker patches are halted and collect some dust (because there is a FAPI thing goign on, for example). Will that queue then not grow into a similar messy heap of code as the current queue-that-is-not-a-queue. Bèr ps http://www.guardian.co.uk/gallery/image/0,8543,-11104901402,00.html imagine them pushing to the hut at the back as a hoge mob. That is a bit how I envision the issue-queue if we continue to grow the wa we did the last year. :) Those with the strongest arms and loudest voice will make it first :) -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Op woensdag 22 februari 2006 11:58, schreef Robert Douglass:
2) the "pressure cooker" organizes the queue into wheat and chaff. When Dries reviews patches, he knows that unless someone trusted has promoted it into the pressure cooker, he doesn't need to fool with it (he still can if he wants, of course). This will negate the "pester-Dries-on-IRC" necessity since any issue in the pressure cooker will automatically get his attention. It also galvanizes the community around the issues in the pressure cooker since it is clear that those are the issues being taken seriously, the ones that are likely to "make it".
What's the difference between the above and RTC? But I think that adding one or two more priority settings will be really improve issue handling and help focus on certain issues as necessary. Something along the lines of: a) Immediate Importance (or its equivalent): To signify something that needs to be looked at immediately. This would include issues that need to be included in an impending release and even security issues which need to be tackled immediately. and b) Fundamental Change (or its equivalent): To denote issues that make important changes that everybody should be aware of so that they can add in their opinions. These priorities can ideally only be set by users belonging to a certain role, and should be a cinch to implement IMO. Just a thought ... -K
Karthik wrote:
What's the difference between the above and RTC?
I don't understand the question (RTC)... But here is the essence of my idea stated differently: There is currently no way to delegate the task of reviewing patches to trusted developers with lots of Drupal experience and a proven track record (and give the results of their review extra meaning). Giving some people the "promote patch" permission enables a group of people to do more of the workload without the risk that their work gets wasted (buried in the queue). The separate patch queue is, of course, just a matter of classification. Issues will have the "promoted" field checked, and then they're in the second queue. At this point, however, they have a special status that is codified by the fact that a view exists to display just this set of issues. So two goals are met: delegated responsibility for reviewing issues and heightened visibility for the issues that get promoted. One could argue that we just add another status to the current list and rely on the search filter to display it, but imo that isn't special enough, not visible enough. An issue entering the pressure cooker needs to send strong signals throughout the community: - this is an important issue and some trusted developer has looked at it carefully. - this issue is guaranteed to be evaluated by a core committer. - this issue will leave the pressure cooker either by entering the Drupal codebase or by being rejected, at which point it will not likely be worthwhile to revive it. Furthermore, it will be easier to open up subscription and notification channels for this queue if there is a clear distinction: - mail notifications when issues enter the pressure cooker - RSS feed for all pressure cooker issues. Finally, we have a chance to add some marketing value to these issues. I'm calling it the pressure cooker, but my intention is that whatever we call it, people should be able to immediately understand that "this is where it's happening... this is the space to watch". It will be easier to motivate large efforts (testing, reviewing, commenting etc.) if there is a real distinction. We can have a link on the front page. It is easier to say "Focus on the pressure cooker" than it is to say "Focus on all issues with status xyz". Did I hit your question? cheers, Robert
I don't understand the question (RTC)...
I meant patch status: Ready To be Committed - something that I seem to have picked up from #drupal :P What do you think about just adding an extra or perhaps two more priority (not status) classes? Won't that serve just as well? Feeds/notifications etc. can all be added to them if need be. Thanks -K
On 2/22/06, Robert Douglass <rob@robshouse.net> wrote:
The PROPOSAL:
This may not be the time or place to comment but I have some opinions on this subject which I have voiced in the past. I'll comment below.
Adjust the user privileges and workflow of the issue queue so that there are, in fact, two queues: -- the first queue is the mess we now know and love. Everything goes into it and it is everyone's task to evaluate the issues. The difference is that there is a user role that has the extra-magical-superhero power to promote an issue to the second queue.
It isn't really clear to me what you mean by a queue. We currently have 10 status' which may be applied to an issue (which could be considered as queues if one knows how to use the search form). Are you suggesting we need a separate field to designate which queue an issue is in? There would be problems with doing this but it is also unnecessary as I'll explain below.
In summary, the most important two aspects of my proposal are: 1) there is a user role that is more empowered to make decisions about patches than they are today. This group of trusted developers has the magical power to promote an issue to the "pressure cooker". 2) the "pressure cooker" organizes the queue into wheat and chaff. When Dries reviews patches, he knows that unless someone trusted has promoted it into the pressure cooker, he doesn't need to fool with it (he still can if he wants, of course). This will negate the "pester-Dries-on-IRC" necessity since any issue in the pressure cooker will automatically get his attention. It also galvanizes the community around the issues in the pressure cooker since it is clear that those are the issues being taken seriously, the ones that are likely to "make it".
First of all, we are in agreement that project.module needs improved access control to support better issue management and prevent misuse of some states. As far as your idea of queues though, unless you're speaking of them in some metaphorical sense which would have no impact on the system itself, I disagree with the approach for a couple of reasons. First, having queues is against the idea of the node concept. I should be able to find a list of all nodes with properties x, y, and z (priority being one of those) and not have to think in terms of queues. This would lead to tunnel vision in my opinion. Second, the "list of pressure cooker issues" which you describe above could easily be a pre-defined (or better yet user definable) search. Third, queues would only help core committers but would leave the rest of us in the cold. The idea to make Dries job easier should play a primary role but Dries is not the only player here. Issue management functionality is currently lacking for all users. For example, anyone including anonymous users can currently create an issue and modify it to any state. Issue states are ambiguous (this is a whole discussion unto itself) and priorities are not well defined or presented to the user. Issue search is not perfect. The fact that "anyone" can set an issue to "ready to commit" status is the problem. Not a lack of queues. My proposal (which I've written in the past) would, in short, be the following. 1. Add access control such that certain status values (and possibly other properties) are restricted to certain roles. 2. Further define and disambiguate issue status values. 3. Add a "resolution" property. 4. Perhaps in the long term add pre-defined and/or user-definable searches. This proposal would provide the following. 1. Issues would no longer be permitted to be elevated to "ready to commit" status by anyone but allowed roles. Core committers could be certain that a search for that value would result in only issues that had been reviewed and accepted by a moderator. 2. More clearly defined status values would provide greater transparency to "actual" issue state and greater search flexibility (e.g., "find all unconfirmed bugs", "find all bugs being not being worked on"). 3. A resolution property would allow us to identify "why" a bug was closed. We currently have no less than 4 different "closed" status values (i.e., won't fix, by design, duplicate, closed) when we should have only one. Cheers, Chris
Add access control such that certain status values (and possibly other properties) are restricted to certain roles.
We sort of have this, but it only works for all projects at once. So, if we restricted 'ready to commit' or 'fixed' to a certain role, that would be true not only for the Drupal project but for all others as well. We would end up with project maintainers who didn't have the ability to reset their own project's issues. We would need to refactor the current code to have project-specific permission control.
participants (8)
-
Ber Kessels -
Bèr Kessels
-
Chris Cook -
Dries Buytaert -
Karoly Negyesi -
Karthik -
Nedjo Rogers -
Robert Douglass