{"thread":{"id":"14460","subject":"Increased maintainer work during Summer of Code","startedAt":"2008-07-15T06:04:27Z","lastAt":"2008-07-15T15:52:37Z","messageCount":2,"participants":["Shawn O. Pearce","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"83366","messageId":"20080715060427.GB3337@spearce.org","threadId":"14460","inReplyTo":null,"subject":"Increased maintainer work during Summer of Code","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-07-15T06:04:27Z","receivedAt":"2008-07-15T06:04:27Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"In reading through the submitted mid-term surveys from students I\nfound this excellent answer from Stephan Beyer:\n\nQ: What advice would you give to future would-be Summer of Code\nmentoring organizations?\n\n> I am wondering about one thing in git which is perhaps true for\n> a lot of other mentoring organizations: There is one person, the\n> maintainer, that is the final authority of deciding what patches\n> go into the repositories and what not. (This is ok and good and if\n> somebody disagrees a lot with such decisions he or she can make up\n> a fork repo without problems.) But the point is that the maintainer\n> has to review and add a lot of patches each day and _during GSoC\n> this is even a lot more_. I sometimes wonder how the maintainer is\n> able to handle that much work ;-) So my \"advice\" could be to think\n> about the \"problem\" of more contributions during GSoC, and if it\n> is useful to have co-maintainers or something. :)\n\nJunio, I know you have been working extra hard lately with the\nmerge of builtin merge, and now gitweb and the sequencer are also\nbeing looked at in much greater detail.\n\nWhat can we do to smooth out this workload better?  Its awesome\nthat we were so fortunate to get these great students this year,\nand have so much contributed in so little time, but we also do\nnot want to see maintainer burn-out.  We also want to avoid a\nhuge backlog of patches.\n\nI don't think we really ever talked about how to help Junio work\nthrough these large contributions that are coming his way.\n\n-- \nShawn.\n"},{"id":"83411","messageId":"7vr69v16wq.fsf@gitster.siamese.dyndns.org","threadId":"14460","inReplyTo":"20080715060427.GB3337@spearce.org","subject":"Re: Increased maintainer work during Summer of Code","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-15T15:52:37Z","receivedAt":"2008-07-15T15:52:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> Junio, I know you have been working extra hard lately with the\n> merge of builtin merge, and now gitweb and the sequencer are also\n> being looked at in much greater detail.\n\nI do not currently perceive much problem.  If they are being looked at in\nmuch greater detail, that is good.\n\n> What can we do to smooth out this workload better?  Its awesome\n> that we were so fortunate to get these great students this year,\n> and have so much contributed in so little time, but we also do\n> not want to see maintainer burn-out.  We also want to avoid a\n> huge backlog of patches.\n\nFor GSoC participants, it might be of utmost importance that their patches\nare looked at, reviewed and integrated.  To me, there is no reason to give\nany preferential treatment for GSoC students.  Students may need to learn\nhow to cope with busy, overloaded, and/or grumpy maintainer. It is a\nnecessary skill to work effectively in an open source project they need to\nacquire.\n\nWhen there are more urgent issues than their projects, patches from GSoC\nstudents may drop through the crack in the floor just like any other\nsubmitters', and more importantly, the urgency is determined solely by\njudging how important the issue is for git.git project, not GSoC.  Usually\nwhen patches are dropped, its the original submitters job to remind,\nresend, or make it easier for the maintainer to take any corrective\nmeasure (e.g. host her own tree to be pulled from) --- GSoC students\nshould learn to do the same, and their mentors would help them with this.\n\nThe community has matured to the point that there are a few areas with\ntrustworthy area experts, and I do not have to look at certain patches\nvery deeply myself.  To name only a few, I just apply patches to git-svn\nthat are either from Eric or acked by him without looking at them (I may\nspot obvious typos by accident and fix them up, though); patches to\n\"archive\" from René are the same way.\n\nPeople can help widen areas that are covered like so.  I admit that I am\nhesitant to let go of certain areas, e.g. sha1_file.c layer, even though I\nknow Nico and you are as competent and knowledgeable in that area as I am\nif not more, simply because such a very core part of the system really\nmatters.  I expect there will always be areas in which I have to look at\nall changes for my own peace of mind, but even in these areas I do not\nhave to be the only person to look at and review the patches.\n"}]}