Re: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 1:05 PM, Jeremy Dunck wrote: > On Tue, Dec 8, 2009 at 12:56 PM, Alex Gaynor wrote: > >> This line of reasoning makes 0 sense IMO. Your argument is people >> provide sub-par patches because they think trunk moves too quickly, >> and a committer will need to rewrite it anyways. > > OK, I declare bikeshed. > > I'll run the experiment as Russ suggested, and we'll see if it does > any good. :-) Here's my report-- The Dallas sprint had 10 people participating for various amounts of time. About half were comfortable enough with git to participate in the queue. I think we closed got about 8 patches ready; 5 went into my queue. After I reviewed them, I marked them ready-for-checkin in trac, attaching the relevant diffs. I'd intended to publish my merge queue at the end of the sprint, but I had reservations about one ticket -- 11753. By the time Jacob and I had gone back and forth cleaning that up, a couple of the other tickets in my queue had been checked in and closed. At this point, I don't think it's worth having the queue merged as a special dance, since there's only a couple small diffs outstanding and they are also in trac. Though the queue wasn't used for merging into SVN, it was still useful to me in the sprint coordination role. It served as a list of patches ready for my review and facilitated iteration on the patches with sprinters. It also served, just now, as a handy checklist to see that people's work got committed and that I did an OK job of marking things ready. I think this kind of positive feedback is good for sprinter morale. If anyone has specific questions on the process or utility, let me know. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 12:56 PM, Alex Gaynor wrote: > This line of reasoning makes 0 sense IMO. Your argument is people > provide sub-par patches because they think trunk moves too quickly, > and a committer will need to rewrite it anyways. OK, I declare bikeshed. I'll run the experiment as Russ suggested, and we'll see if it does any good. :-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 1:47 PM, mrts wrote: >> On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck wrote: >> > Sorry to hear that. The document you linked is a start, but I'm a bit >> > concerned by this goal: >> > "to keep the main integration branch as stable as the official trunk >> > so that it can be used in actual deployments" >> >> > My concern here would be that people become dependent on your >> > selections for prod, and some of these changes never get merged to >> > mainline, so that there's functionally a fork in terms of support and >> > community. > > I would really, really want to avoid that. The merge branch would > let people test things out properly, perhaps even in production, and > run a buildbot off it. But the goal of the effort as a whole is just > getting > high-quality reviewed, tested and integrated patches back to Django > trac. > > The wording is just a sketch, seems I have to re-iterate that no > forking in the "bad" sense of the word will occur. The work is meant > for merging back and the main value lies in ticket branches, not in > the merge branch. > > What I envision is the following: > * there's a specific goal and deadline (i.e. fix 10 bugs in 2 weeks), > * sprinters claim tickets in trac, > * sprinters create ticket branches in their corresponding forks of > the Django SVN mirror and work off their branches, > * when the work is ready, it will be reviewed and merged into the > mq by sprint lieutenants, > * buildbots run tests off the mq, > * if all is well, the sprinter uploads the final patch to the > corresponding ticket, > * when the deadline is reached, the tickets that were properly > fixed during the spring are presented to core and will be eventually > merged to SVN trunk simply via the patches in trac. > > As far as I can understand, core has been opposed to taking > more work upon themselves, so the last step should be > effortless, i.e. core can assume that the patch is > well reviewed, tested and non-controversial. > > This workflow is suitable for janitor-type work, not for > epic or controversial changes. > > On Dec 8, 7:40 pm, Alex Gaynor wrote: >> Because of this work to review tickets, provide feedback, and get them >> into an RFC state is far more important IMO. > > Exactly. However, there needs to be a coordinated effort and a > deadline to rally the masses :). The Django community is vast > and certainly full of excellent people who are more than able > to fix a couple of the 1700 open tickets. However, people who > provide patches are few and the patches are mostly > proof-of-concept quality. > > I myself am used to providing somewhat proof-of-concept > quality patches. > > Analyzing the reasons, I noticed that I semi-consciously > am thinking that the trunk changes too much to make > polishing feasible and that a core reviewer "knows better" > and will rewrite it anyway. This attitude doesn't work > within the merge queue workflow, where most of the work > is quickly integrated and thus the contributor needs to pay > more attention to polish. > > So, there's a psychological benefit of the mq besides > the real one. > > Over and out for today, > best, > MS > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > This line of reasoning makes 0 sense IMO. Your argument is people provide sub-par patches because they think trunk moves too quickly, and a committer will need to rewrite it anyways. I've written quite a few patches, I can count on one hand's fingers the number that have needed to be updated for changes in Django itself. Your argument further supposes that by having a target that merges things in more quickly contributors will be more inclined to provide "merge ready" patches since they will in fact be merged. This is completely inconsistent line of reasoning. The reason their patches weren't accepted in the first place was because they weren't good patches, the issue needed a fundamental design decision, or a committer never saw the ticket and patch (I'm ignoring no committers had time, time is going to be a limiting reagent no matter what the solution is). As Russ and others have pointed out elsewhere if a merge queue regularly accepts patches that would be rejected from core it doesn't do anyone much good, therefore all of these items need to be satisfied, *regardless* of whether the patch ends up in a merge-queue or trunk. Therefore to say that people will pay more attention to polish because it's more quickly merged to me seems to indicate a fundamental disconnect, or that the merge-queue reviewers have huge amounts of available time ;) (which I've already said I view as being best spent providing fe
Re: Sprint issue tracking / triaging
> On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck wrote: > > Sorry to hear that. The document you linked is a start, but I'm a bit > > concerned by this goal: > > "to keep the main integration branch as stable as the official trunk > > so that it can be used in actual deployments" > > > My concern here would be that people become dependent on your > > selections for prod, and some of these changes never get merged to > > mainline, so that there's functionally a fork in terms of support and > > community. I would really, really want to avoid that. The merge branch would let people test things out properly, perhaps even in production, and run a buildbot off it. But the goal of the effort as a whole is just getting high-quality reviewed, tested and integrated patches back to Django trac. The wording is just a sketch, seems I have to re-iterate that no forking in the "bad" sense of the word will occur. The work is meant for merging back and the main value lies in ticket branches, not in the merge branch. What I envision is the following: * there's a specific goal and deadline (i.e. fix 10 bugs in 2 weeks), * sprinters claim tickets in trac, * sprinters create ticket branches in their corresponding forks of the Django SVN mirror and work off their branches, * when the work is ready, it will be reviewed and merged into the mq by sprint lieutenants, * buildbots run tests off the mq, * if all is well, the sprinter uploads the final patch to the corresponding ticket, * when the deadline is reached, the tickets that were properly fixed during the spring are presented to core and will be eventually merged to SVN trunk simply via the patches in trac. As far as I can understand, core has been opposed to taking more work upon themselves, so the last step should be effortless, i.e. core can assume that the patch is well reviewed, tested and non-controversial. This workflow is suitable for janitor-type work, not for epic or controversial changes. On Dec 8, 7:40 pm, Alex Gaynor wrote: > Because of this work to review tickets, provide feedback, and get them > into an RFC state is far more important IMO. Exactly. However, there needs to be a coordinated effort and a deadline to rally the masses :). The Django community is vast and certainly full of excellent people who are more than able to fix a couple of the 1700 open tickets. However, people who provide patches are few and the patches are mostly proof-of-concept quality. I myself am used to providing somewhat proof-of-concept quality patches. Analyzing the reasons, I noticed that I semi-consciously am thinking that the trunk changes too much to make polishing feasible and that a core reviewer "knows better" and will rewrite it anyway. This attitude doesn't work within the merge queue workflow, where most of the work is quickly integrated and thus the contributor needs to pay more attention to polish. So, there's a psychological benefit of the mq besides the real one. Over and out for today, best, MS -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 11:40 AM, Alex Gaynor wrote: ... > Personally I think merge queues ignore where the real work is. > Applying a patch (as a diff, or pulling from another repo myself) is a > trivial amount of work, and the number of times I have had actual > conflicts between 2 patches that were going to be applied is tiny, and > where there was a conflict it usually indicated something more > fundamental was wrong with the patch. I agree, though I think this depends on the depth of the unapplied queue. > Because of this work to review tickets, provide feedback, and get them > into an RFC state is far more important IMO. Agreed. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck wrote: > On Tue, Dec 8, 2009 at 11:27 AM, mrts wrote: > ... >> I have thought about the process a bit and even wrote some >> helper code. >> >> Unfortunately I fell ill and haven't fully recovered (and am >> therefore horribly off-schedule with my work), so I haven't >> had the chance to continue with the effort. >> *Notoriously* bad timing, considering we had a similar >> discussion before and that the sprint is coming up soon. > > Sorry to hear that. The document you linked is a start, but I'm a bit > concerned by this goal: > "to keep the main integration branch as stable as the official trunk > so that it can be used in actual deployments" > > My concern here would be that people become dependent on your > selections for prod, and some of these changes never get merged to > mainline, so that there's functionally a fork in terms of support and > community. > > I guess people will vote with their feet if your queue is really > better. If I do run sprint repos, my specific purpose will be to > provide patchsets for easy integration, but no expectation of people > using those branches for deployment. :-/ > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > Personally I think merge queues ignore where the real work is. Applying a patch (as a diff, or pulling from another repo myself) is a trivial amount of work, and the number of times I have had actual conflicts between 2 patches that were going to be applied is tiny, and where there was a conflict it usually indicated something more fundamental was wrong with the patch. Because of this work to review tickets, provide feedback, and get them into an RFC state is far more important IMO. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 11:27 AM, mrts wrote: ... > I have thought about the process a bit and even wrote some > helper code. > > Unfortunately I fell ill and haven't fully recovered (and am > therefore horribly off-schedule with my work), so I haven't > had the chance to continue with the effort. > *Notoriously* bad timing, considering we had a similar > discussion before and that the sprint is coming up soon. Sorry to hear that. The document you linked is a start, but I'm a bit concerned by this goal: "to keep the main integration branch as stable as the official trunk so that it can be used in actual deployments" My concern here would be that people become dependent on your selections for prod, and some of these changes never get merged to mainline, so that there's functionally a fork in terms of support and community. I guess people will vote with their feet if your queue is really better. If I do run sprint repos, my specific purpose will be to provide patchsets for easy integration, but no expectation of people using those branches for deployment. :-/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Dec 8, 5:32 am, Russell Keith-Magee wrote: > On Tue, Dec 8, 2009 at 11:11 AM, Tobias McNulty > wrote: > > On Mon, Dec 7, 2009 at 6:31 PM, Russell Keith-Magee > > wrote: > >> I was thinking more of having one person at the sprint to take the > >> role of integrator - that is, the patches still go up on trac, but one > >> trusted person at the sprint takes the role of lieutenant for the > >> sprint, and selects patches that they consider trunk-ready. The end > >> deliverable is a branch that a core developer could theoretically just > >> git merge and push to SVN. In practice, there will probably be further > >> review by the core, but the idea is to provide a single rich vein of > >> high quality patches. > > > Yes, personally I don't see the need to be overly organized about > > branching for each feature developed at the sprint. There's no need > > to dictate what version control system, if any, participants use to > > develop code for Django. Some prefer git, some hg, and some small > > tickets might not need a branch at all. > > > The role of integrator does sound like a good one, though, both in > > terms of making sure things work (and work together) and also for > > keeping track of what actually gets done at the sprint. Simply > > merging that branch directly into trunk sounds a little dicey, > > however, as commit granularity in terms of features (even small bug > > fixes) is usually a Good Thing. > > I should clarify - I wasn't talking about an SVN style merge where N > branch commits become 1 trunk commit. I meant a git/hg style merge, > where each commit on the branch becomes a commit on the trunk. I have thought about the process a bit and even wrote some helper code. Unfortunately I fell ill and haven't fully recovered (and am therefore horribly off-schedule with my work), so I haven't had the chance to continue with the effort. *Notoriously* bad timing, considering we had a similar discussion before and that the sprint is coming up soon. Unfortunately only the less important general guidelines are up as of now at http://wiki.github.com/django-mq/django-mq What I had in mind was to write proper guidelines so that people can hop on easily and to keep things properly organized. I also planned to run an example sprint by myself to demonstrate how things actually work. Alas, I can not do that presently. I'll get to it eventually though. Best, MS -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 11:11 AM, Tobias McNulty wrote: > On Mon, Dec 7, 2009 at 6:31 PM, Russell Keith-Magee > wrote: >> I was thinking more of having one person at the sprint to take the >> role of integrator - that is, the patches still go up on trac, but one >> trusted person at the sprint takes the role of lieutenant for the >> sprint, and selects patches that they consider trunk-ready. The end >> deliverable is a branch that a core developer could theoretically just >> git merge and push to SVN. In practice, there will probably be further >> review by the core, but the idea is to provide a single rich vein of >> high quality patches. > > Yes, personally I don't see the need to be overly organized about > branching for each feature developed at the sprint. There's no need > to dictate what version control system, if any, participants use to > develop code for Django. Some prefer git, some hg, and some small > tickets might not need a branch at all. > > The role of integrator does sound like a good one, though, both in > terms of making sure things work (and work together) and also for > keeping track of what actually gets done at the sprint. Simply > merging that branch directly into trunk sounds a little dicey, > however, as commit granularity in terms of features (even small bug > fixes) is usually a Good Thing. I should clarify - I wasn't talking about an SVN style merge where N branch commits become 1 trunk commit. I meant a git/hg style merge, where each commit on the branch becomes a commit on the trunk. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Mon, Dec 7, 2009 at 6:31 PM, Russell Keith-Magee wrote: > I was thinking more of having one person at the sprint to take the > role of integrator - that is, the patches still go up on trac, but one > trusted person at the sprint takes the role of lieutenant for the > sprint, and selects patches that they consider trunk-ready. The end > deliverable is a branch that a core developer could theoretically just > git merge and push to SVN. In practice, there will probably be further > review by the core, but the idea is to provide a single rich vein of > high quality patches. Yes, personally I don't see the need to be overly organized about branching for each feature developed at the sprint. There's no need to dictate what version control system, if any, participants use to develop code for Django. Some prefer git, some hg, and some small tickets might not need a branch at all. The role of integrator does sound like a good one, though, both in terms of making sure things work (and work together) and also for keeping track of what actually gets done at the sprint. Simply merging that branch directly into trunk sounds a little dicey, however, as commit granularity in terms of features (even small bug fixes) is usually a Good Thing. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 7:11 AM, Jeremy Dunck wrote: > > On Dec 7, 2009, at 5:02 PM, Russell Keith-Magee > wrote: > >> Looking at new ideas to try - if someone trusted at the sprint (such >> as yourself) were to take the role of developing a merge-ready git >> branch, we (the committers) could use that branch to feed into trunk. >> This hasn't been done in the past, but if you want to try an >> experiment, it would be interesting to see if we can make it work. > > I assume one branch per feature/ticket, plus maybe a meta branch for > integration test? > > I'd imagined people would still like one (or more) commit per feature. Herein lies the experiment :-) Speaking personally, simply having a patch applied and available in a git branch doesn't actually make my job any easier. It's just as easy for me to apply a patch from trac - possibly easier, since I don't have to spend as much time gardening my git remotes. I was thinking more of having one person at the sprint to take the role of integrator - that is, the patches still go up on trac, but one trusted person at the sprint takes the role of lieutenant for the sprint, and selects patches that they consider trunk-ready. The end deliverable is a branch that a core developer could theoretically just git merge and push to SVN. In practice, there will probably be further review by the core, but the idea is to provide a single rich vein of high quality patches. Of course, I'm open to any other suggestions. Like I said, this is an experiment - if it works, we can repeat it, or we can improve on it as we go forward. Russ %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Dec 7, 2009, at 5:02 PM, Russell Keith-Magee wrote: > Looking at new ideas to try - if someone trusted at the sprint (such > as yourself) were to take the role of developing a merge-ready git > branch, we (the committers) could use that branch to feed into trunk. > This hasn't been done in the past, but if you want to try an > experiment, it would be interesting to see if we can make it work. I assume one branch per feature/ticket, plus maybe a meta branch for integration test? I'd imagined people would still like one (or more) commit per feature. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Tue, Dec 8, 2009 at 5:46 AM, Jeremy Dunck wrote: > Hey all, > I was wondering if I could do anything to streamline applying > sprint-created patches. > > Obviously, I can do triaging and provide feedback on patches. Can > I be blessed to say "Ready for checkin"? > > What else can I do? I think getting patches which are actually > ready to be committed quickly will help sprinters be motivated and > want to participate in future sprints. One technique that has worked in past sprints is to use the wiki to keep a log of tickets that have been worked on. This provides a handy way for committers to identify recently modified patches out of the list of all possible ready-for-checkin tickets. An alternate version of the same approach is to add a common tag (e.g., sprint-dec09) to tickets that are modified; this means we can use trac itself to find candidate RFCs. Looking at new ideas to try - if someone trusted at the sprint (such as yourself) were to take the role of developing a merge-ready git branch, we (the committers) could use that branch to feed into trunk. This hasn't been done in the past, but if you want to try an experiment, it would be interesting to see if we can make it work. Russ %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Mon, Dec 7, 2009 at 3:46 PM, Jeremy Dunck wrote: > Obviously, I can do triaging and provide feedback on patches. Can > I be blessed to say "Ready for checkin"? Please - that'd really help me. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Sprint issue tracking / triaging
On Mon, Dec 7, 2009 at 4:46 PM, Jeremy Dunck wrote: > Hey all, > I was wondering if I could do anything to streamline applying > sprint-created patches. > > Obviously, I can do triaging and provide feedback on patches. Can > I be blessed to say "Ready for checkin"? > > What else can I do? I think getting patches which are actually > ready to be committed quickly will help sprinters be motivated and > want to participate in future sprints. > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > I don't see why normal code review procedures aren't enough. If a patch is RFC it should be marked as such, no sooner, no later than if it were a "regular" patch. Being able to provide feedback in person to new contributers is far more valuable than an *additional* RFC designation IMO. As far as who can mark tickets RFC, I don't know if there's a special "hat" they have to wear, I thought it was just people who are familar with the code, so I think you qualify ;) Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
