Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 03/26/2013 09:55 PM, Manuel Quiñones wrote: 2013/3/26 Daniel Narvaez dwnarv...@gmail.com: [...] We also had periodic design meetings guiding features. I wonder if that kind of discussion could be had on the mailing list rather than in meetings. It's problematic to find a time that works for everyone and many people just doesn't have time to spend in irc. Yes after coordination issues we concluded we better keep discussing design topics in the mailing list. We have a prefix [DESIGN] for this. I will try to be more responsive to those threads from now on. Discussing design after the development is made isn't good, imho. I couldn't agree more. The feature process has some guidelines in regard to Features that add UI: If your feature adds UI or changes the current UI please add as well the [DESIGN] tag to the subject. Please add the flag as well if the work flow does change or new ones are added. The Design Team should be involved in the discussion to guarantee a consistent design and a consistent work flow in Sugar. When presenting the feature to the release manager the design does not have to be ready but the discussion should have been started. [1] Regards, Simon [1] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 26 March 2013 21:55, Manuel Quiñones ma...@laptop.org wrote: Right Daniel, could be. At some point of the gtk3 port and touch feature development it became a waste of efforts to bother the list with our patches. It was like a theatre play, Simon or me sending a patch, the other ack-ing or nack-ing, no other actor intervening. And we wanted to speed up that transition. But yes I'd favor going back to post the patches on the mailing list. Or maybe better, discuss the tickets in the mailing list without posting the patches here. Could be any of both, as the sender prefers. I personally prefer to have my patches in the tracker. Why do you prefer to have them in the tracker? And how would you feel about a pull request based workflow? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
2013/3/27 Daniel Narvaez dwnarv...@gmail.com: On 26 March 2013 21:55, Manuel Quiñones ma...@laptop.org wrote: Right Daniel, could be. At some point of the gtk3 port and touch feature development it became a waste of efforts to bother the list with our patches. It was like a theatre play, Simon or me sending a patch, the other ack-ing or nack-ing, no other actor intervening. And we wanted to speed up that transition. But yes I'd favor going back to post the patches on the mailing list. Or maybe better, discuss the tickets in the mailing list without posting the patches here. Could be any of both, as the sender prefers. I personally prefer to have my patches in the tracker. Why do you prefer to have them in the tracker? And how would you feel about a pull request based workflow? Note this is very personal: for me it is easier to store my patches in the tracker whlie I work on a bug or feature. - It could be ongoing work, not yet in shape to publish on the mailing list - The attachment serves me as a backup - Is easy for another dev to get them and apply, for test, review or improve. Is easy for me to do the same with someone else's patch - I use webmail (gmail) and althrough git-send-mail is easy to configure, applying someone else's patch is more difficult. I always end copy/pasting the email text. - Going through the archive to find a patch is a pain. Having a ticket number to track it is easier. I know all this can be replaced by a fork pull workflow, and I'm used to do that in github. But gitorius interface is not as good as github, in my opinion. By the way, if we have consensus for a fork pull workflow, I have no problem switching. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 03/25/2013 09:32 PM, Daniel Narvaez wrote: Forgot to reply all... -- Forwarded message -- From: Daniel Narvaez dwnarv...@gmail.com Date: 25 March 2013 21:12 Subject: Re: [Sugar-devel] Proposal on how to speed up patch reviews To: Simon Schampijer si...@schampijer.de On 25 March 2013 12:37, Simon Schampijer si...@schampijer.de wrote: To improve that situation, I think we have to put some lights on all those roles and I think often the situation of the maintainer is not understood well enough. I can at least say that we had this discussions for the last years in Sugar, with different maintainers and I have seen it happening in many other projects as well. It is a known issue, and it is not an easy one, never less I think we can improve. In my experience Sugar has been much worst than both GNOME and mozilla though. I know it's not easy but we should keep trying. (I hope it's absolutely clear that I'm not blaming anyone for the situation, just pointing out the importance of fixing it or at least trying to) [bugfix] A bugfix is the simplest case. The submitter is interested in solving the specific issue he is working on. It is not hard to find a reviewer or tester. Either someone from the community that has been annoyed by the same issue or the maintainer himself because he is interested in seeing the issue solved, his interest is a working code base in the end. Here it is easy as well for a maintainer to trust another reviewer and acknowledge based on his positive review. In my experience those patches are not laying around for long if there is not a technical blocker in the patch itself. Evaluation is relatively easy here. I had at least one obvious bug fix patch unreviewed for months. Maybe I was unlucky. Anyway I agree this is the easiest of the cases and where things work best. That is bad of course. Could have been several reasons. Maybe the decoupling of patches and the bug tracker, maybe just felt of the table... Sometimes a ping is valid option. But yes, the easiest area to solve. [feature] When it gets to Features things get more tricky. For a Feature first of all the high level goals are important: what need does the Feature address, is it wanted by the community, is the technical approach taken a good one, basically the maintainer has to decide if it is worth taking on maintainership of this feature or not. In the end it might be him who has to deal with arising bug fixes and who is blamed if the software is not a solid product. While I agree with you in general, I think maybe we are exagerating a bit the responsibility of the maintainers a bit. I tend to think it's the whole community which will get the blame if things goes wrong... Maintainers have of course a very important role, but they should not feel like they alone into this. From my experience the work on a feature and the polish of it gets often underestimated. The first 90% are done in 10% of the time the last 10% are done in 90% of the time. I would like to establish a sense of the work needed to finish a feature, not to make people afraid of starting to work on features but to be realistic. That might explain a general bigger resistance to features by maintainers. How can we help each other to make this a better process? I think narrowing the focus is the best we can do, but I'll elaborate more about that while answering Gonzalo email. [feature/UI] All what have been said above applies to the feature that adds UI as well. I have separated that item because it adds another complexity. We have the UI process for this (as written in the feature policy [1]). Basically it adds more care taking of all the roles involved. Even if we go with my propiosal, I think maintainers should keep a strong supervision role on features, UI or not. I'd say it's responsibility of the reviewer to make sure the maintainer is happy in this regard... we should add it to our review checklist (well we don't have one yet afaik, but we should). Yes, from my experience, the UI review part of a Feature takes even longer than the code review. First of all we do not have as many designers as people who can do review and good consistent UI is not easy. Gary and Manuel are currently helping on that end. Probably good to hear them, if they have anything to add that could help to make things go more smooth. Online services patches, unreviewed for more than one month http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041808.html Unreviewed for more than one month This one is part of the [feature] category. It can be mostly explained with the maintainers having their heads still in bug fixing for 0.98. Here applies as well what I said with high level descriptions of features and the feature process [2]. In an ideal world, a reviewer which is not busy with 0.98 should have given a first pass to the patches and at the same time started a discussion, involving the maintainer, about the
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 26 March 2013 10:53, Simon Schampijer si...@schampijer.de wrote: That is bad of course. Could have been several reasons. Maybe the decoupling of patches and the bug tracker, maybe just felt of the table... Sometimes a ping is valid option. But yes, the easiest area to solve. I did try to ping a couple of times on that specific patch. The thing is that if you see maintainers are busy with a ton of stuff you just don't dare pinging too hard and at some point you give up... (Just trying to give a contributor perspective here). [feature] When it gets to Features things get more tricky. For a Feature first of all the high level goals are important: what need does the Feature address, is it wanted by the community, is the technical approach taken a good one, basically the maintainer has to decide if it is worth taking on maintainership of this feature or not. In the end it might be him who has to deal with arising bug fixes and who is blamed if the software is not a solid product. While I agree with you in general, I think maybe we are exagerating a bit the responsibility of the maintainers a bit. I tend to think it's the whole community which will get the blame if things goes wrong... Maintainers have of course a very important role, but they should not feel like they alone into this. From my experience the work on a feature and the polish of it gets often underestimated. The first 90% are done in 10% of the time the last 10% are done in 90% of the time. I would like to establish a sense of the work needed to finish a feature, not to make people afraid of starting to work on features but to be realistic. That's my experience too. But are you saying the hardest 10% is in the hands of maintainers? That happens in my experience, but it doesn't have to, or at least not most of the time. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 03/26/2013 11:13 AM, Daniel Narvaez wrote: On 26 March 2013 10:53, Simon Schampijer si...@schampijer.de wrote: That is bad of course. Could have been several reasons. Maybe the decoupling of patches and the bug tracker, maybe just felt of the table... Sometimes a ping is valid option. But yes, the easiest area to solve. I did try to ping a couple of times on that specific patch. The thing is that if you see maintainers are busy with a ton of stuff you just don't dare pinging too hard and at some point you give up... (Just trying to give a contributor perspective here). Ok, it is good to hear the different stories from the parties involved. This is a thread to analyze the situation and see how we can do better. Appreciated. [feature] When it gets to Features things get more tricky. For a Feature first of all the high level goals are important: what need does the Feature address, is it wanted by the community, is the technical approach taken a good one, basically the maintainer has to decide if it is worth taking on maintainership of this feature or not. In the end it might be him who has to deal with arising bug fixes and who is blamed if the software is not a solid product. While I agree with you in general, I think maybe we are exagerating a bit the responsibility of the maintainers a bit. I tend to think it's the whole community which will get the blame if things goes wrong... Maintainers have of course a very important role, but they should not feel like they alone into this. From my experience the work on a feature and the polish of it gets often underestimated. The first 90% are done in 10% of the time the last 10% are done in 90% of the time. I would like to establish a sense of the work needed to finish a feature, not to make people afraid of starting to work on features but to be realistic. That's my experience too. But are you saying the hardest 10% is in the hands of maintainers? That happens in my experience, but it doesn't have to, or at least not most of the time. Yes, I think that happens sometimes. Part of it is maybe if the submitter feels responsible or not for a feature after it has been landed and how much he is willing to follow up during the process. Of course for the contributor it does not help if the process (a) takes long and (b) if the process has not started for a long time after he has sent the patches and he is already doing something else. If roles and responsibilities are clear and we have a timeframe and guidelines to enforce things can get better. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
I would like to applaud the discussion. Yes, I think we are blocking too much, in regards to stuff that is out of bugfixing, and polishing the gtk3 port. This is indeed not good for the community. When I started in this project, my patches received reviews from many people, not only maintainers. Many discussions went by. I don't see that happening anymore. We also had periodic design meetings guiding features. Discussing design after the development is made isn't good, imho. It would be great if someone can stand up and become a maintainer. Maybe you, Daniel? You have demonstrated your skills with sugar-build, and helping on the gtk3 port. 2013/3/26 Simon Schampijer si...@schampijer.de: On 03/26/2013 11:13 AM, Daniel Narvaez wrote: On 26 March 2013 10:53, Simon Schampijer si...@schampijer.de wrote: That is bad of course. Could have been several reasons. Maybe the decoupling of patches and the bug tracker, maybe just felt of the table... Sometimes a ping is valid option. But yes, the easiest area to solve. I did try to ping a couple of times on that specific patch. The thing is that if you see maintainers are busy with a ton of stuff you just don't dare pinging too hard and at some point you give up... (Just trying to give a contributor perspective here). Ok, it is good to hear the different stories from the parties involved. This is a thread to analyze the situation and see how we can do better. Appreciated. [feature] When it gets to Features things get more tricky. For a Feature first of all the high level goals are important: what need does the Feature address, is it wanted by the community, is the technical approach taken a good one, basically the maintainer has to decide if it is worth taking on maintainership of this feature or not. In the end it might be him who has to deal with arising bug fixes and who is blamed if the software is not a solid product. While I agree with you in general, I think maybe we are exagerating a bit the responsibility of the maintainers a bit. I tend to think it's the whole community which will get the blame if things goes wrong... Maintainers have of course a very important role, but they should not feel like they alone into this. From my experience the work on a feature and the polish of it gets often underestimated. The first 90% are done in 10% of the time the last 10% are done in 90% of the time. I would like to establish a sense of the work needed to finish a feature, not to make people afraid of starting to work on features but to be realistic. That's my experience too. But are you saying the hardest 10% is in the hands of maintainers? That happens in my experience, but it doesn't have to, or at least not most of the time. Yes, I think that happens sometimes. Part of it is maybe if the submitter feels responsible or not for a feature after it has been landed and how much he is willing to follow up during the process. Of course for the contributor it does not help if the process (a) takes long and (b) if the process has not started for a long time after he has sent the patches and he is already doing something else. If roles and responsibilities are clear and we have a timeframe and guidelines to enforce things can get better. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 03/26/2013 12:21 PM, Manuel Quiñones wrote: I would like to applaud the discussion. Yes, I think we are blocking too much, in regards to stuff that is out of bugfixing, and polishing the gtk3 port. This is indeed not good for the community. When I started in this project, my patches received reviews from many people, not only maintainers. Many discussions went by. I don't see that happening anymore. We also had periodic design meetings guiding features. Discussing design after the development is made isn't good, imho. It would be great if someone can stand up and become a maintainer. Maybe you, Daniel? You have demonstrated your skills with sugar-build, and helping on the gtk3 port. A reviewer with the authority described in this discussion is probably a good first start. I think that is what Daniel would be able to help us with. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 26 March 2013 12:26, Simon Schampijer si...@schampijer.de wrote: On 03/26/2013 12:21 PM, Manuel Quiñones wrote: I would like to applaud the discussion. Yes, I think we are blocking too much, in regards to stuff that is out of bugfixing, and polishing the gtk3 port. This is indeed not good for the community. When I started in this project, my patches received reviews from many people, not only maintainers. Many discussions went by. I don't see that happening anymore. We also had periodic design meetings guiding features. Discussing design after the development is made isn't good, imho. It would be great if someone can stand up and become a maintainer. Maybe you, Daniel? You have demonstrated your skills with sugar-build, and helping on the gtk3 port. A reviewer with the authority described in this discussion is probably a good first start. I think that is what Daniel would be able to help us with. Sure, I'm happy to help with the reviews :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 26 March 2013 12:21, Manuel Quiñones ma...@laptop.org wrote: When I started in this project, my patches received reviews from many people, not only maintainers. Many discussions went by. I don't see that happening anymore. Could it be because most patches are posted in trac now? I'm not sure it's the only reason, though those are pretty much invisible to people not involved directly in the issue. (I know there are issues with mailing list reviews too, just trying to analyze the situation here) We also had periodic design meetings guiding features. I wonder if that kind of discussion could be had on the mailing list rather than in meetings. It's problematic to find a time that works for everyone and many people just doesn't have time to spend in irc. Discussing design after the development is made isn't good, imho. I couldn't agree more. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
I don't have a dog in the fight, but I can give my two cents (disclaimer: I'm sorry if I misunderstood facts or misquoted people): With dextrose, we had the same bottleneck problem, of patches getting stuck in the review queue, then the commit queue. One associated problem is that the longer a patch lingers on, the more it loses contextual value and the harder it is to remember/understand for everyone what the patch was for or what it did (even with good commit messages). What would happen many times is that once the patch finally reaches the maintainer, he has to make an effort to recall the relevance of the patch and spend time in reviewing it again. Gonzalo also raises pertinent points: * We don't have enough reviewers * We don't have enough maintainers In dextrose, addressed this problem this way: * There was one release manager * There were multiple people with the access and the authority to commit patches * There were dedicated testers * There were foul-ups initially, but this increased the pace of development by at least 2x. What could this mean in context of sugar/mainline: * Have one or two maintainers. Simon and Manuq are excellent. They are responsible for setting roadmaps, deadlines, and making releases. * Have multiple people with commit access authority. Daniel and Gonzalo perhaps? I don't know who else. * The criteria for committing could be as simple as: ** The patch has been reviewed by atleast one person from this group ** The patch has been *tested* by atleast one person from this group Normally, one wouldn't recommend this as it increases the chance of breakage, but I guess we're at the other end of the spectrum. If development pace needs to be ramped up, I'd recommend the above. Cheers, Anish On Tue, Mar 26, 2013 at 7:26 AM, Simon Schampijer si...@schampijer.de wrote: On 03/26/2013 12:21 PM, Manuel Quiñones wrote: I would like to applaud the discussion. Yes, I think we are blocking too much, in regards to stuff that is out of bugfixing, and polishing the gtk3 port. This is indeed not good for the community. When I started in this project, my patches received reviews from many people, not only maintainers. Many discussions went by. I don't see that happening anymore. We also had periodic design meetings guiding features. Discussing design after the development is made isn't good, imho. It would be great if someone can stand up and become a maintainer. Maybe you, Daniel? You have demonstrated your skills with sugar-build, and helping on the gtk3 port. A reviewer with the authority described in this discussion is probably a good first start. I think that is what Daniel would be able to help us with. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Anish | an...@sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On Tue, Mar 26, 2013 at 11:27 PM, Anish Mangal an...@sugarlabs.org wrote: I don't have a dog in the fight, but I can give my two cents (disclaimer: I'm sorry if I misunderstood facts or misquoted people): With dextrose, we had the same bottleneck problem, of patches getting stuck in the review queue, then the commit queue. One associated problem is that the longer a patch lingers on, the more it loses contextual value and the harder it is to remember/understand for everyone what the patch was for or what it did (even with good commit messages). What would happen many times is that once the patch finally reaches the maintainer, he has to make an effort to recall the relevance of the patch and spend time in reviewing it again. Gonzalo also raises pertinent points: * We don't have enough reviewers * We don't have enough maintainers In dextrose, addressed this problem this way: * There was one release manager * There were multiple people with the access and the authority to commit patches * There were dedicated testers * There were foul-ups initially, but this increased the pace of development by at least 2x. What could this mean in context of sugar/mainline: * Have one or two maintainers. Simon and Manuq are excellent. They are responsible for setting roadmaps, deadlines, and making releases. * Have multiple people with commit access authority. Daniel and Gonzalo perhaps? I don't know who else. * The criteria for committing could be as simple as: ** The patch has been reviewed by atleast one person from this group ** The patch has been *tested* by atleast one person from this group Normally, one wouldn't recommend this as it increases the chance of breakage, but I guess we're at the other end of the spectrum. If development pace needs to be ramped up, I'd recommend the above. Very well put - practical, and not too bothersome to anyone !! Cheers, Anish On Tue, Mar 26, 2013 at 7:26 AM, Simon Schampijer si...@schampijer.de wrote: On 03/26/2013 12:21 PM, Manuel Quiñones wrote: I would like to applaud the discussion. Yes, I think we are blocking too much, in regards to stuff that is out of bugfixing, and polishing the gtk3 port. This is indeed not good for the community. When I started in this project, my patches received reviews from many people, not only maintainers. Many discussions went by. I don't see that happening anymore. We also had periodic design meetings guiding features. Discussing design after the development is made isn't good, imho. It would be great if someone can stand up and become a maintainer. Maybe you, Daniel? You have demonstrated your skills with sugar-build, and helping on the gtk3 port. A reviewer with the authority described in this discussion is probably a good first start. I think that is what Daniel would be able to help us with. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Anish | an...@sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Regards, Ajay ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On 26 March 2013 18:57, Anish Mangal an...@sugarlabs.org wrote: What could this mean in context of sugar/mainline: * Have one or two maintainers. Simon and Manuq are excellent. They are responsible for setting roadmaps, deadlines, and making releases. * Have multiple people with commit access authority. Daniel and Gonzalo perhaps? I don't know who else. * The criteria for committing could be as simple as: ** The patch has been reviewed by atleast one person from this group ** The patch has been *tested* by atleast one person from this group Yup. That sounds pretty much like what I was proposing (reassuring to know that it worked well for you guys!) with a couple of improvements * Reviewer == committer I think that makes a lot of sense. * One committer should also test the patch I like it but I think we should extend this to everyone willing to test (except the author of the patch). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
On Tue, Mar 26, 2013 at 2:57 PM, Anish Mangal an...@sugarlabs.org wrote: I don't have a dog in the fight, but I can give my two cents (disclaimer: I'm sorry if I misunderstood facts or misquoted people): What could this mean in context of sugar/mainline: * Have one or two maintainers. Simon and Manuq are excellent. They are responsible for setting roadmaps, deadlines, and making releases. * Have multiple people with commit access authority. Daniel and Gonzalo perhaps? I don't know who else. * The criteria for committing could be as simple as: ** The patch has been reviewed by atleast one person from this group ** The patch has been *tested* by atleast one person from this group Normally, one wouldn't recommend this as it increases the chance of breakage, but I guess we're at the other end of the spectrum. If development pace needs to be ramped up, I'd recommend the above. Cheers, Anish But this proposal does not add more people to the dance :) Anybody can test, and should be encouraged, and may be not all, but there are more people who can review. Quozl, Walter, dsd, did reviews. I did reviews, but of course does not have sense spend time on the reviews if are not useful to the maintainers. That is the reason I think we need a plan, and clarify what is useful and what should be accepted. Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Proposal on how to speed up patch reviews
2013/3/26 Daniel Narvaez dwnarv...@gmail.com: On 26 March 2013 12:21, Manuel Quiñones ma...@laptop.org wrote: When I started in this project, my patches received reviews from many people, not only maintainers. Many discussions went by. I don't see that happening anymore. Could it be because most patches are posted in trac now? I'm not sure it's the only reason, though those are pretty much invisible to people not involved directly in the issue. Right Daniel, could be. At some point of the gtk3 port and touch feature development it became a waste of efforts to bother the list with our patches. It was like a theatre play, Simon or me sending a patch, the other ack-ing or nack-ing, no other actor intervening. And we wanted to speed up that transition. But yes I'd favor going back to post the patches on the mailing list. Or maybe better, discuss the tickets in the mailing list without posting the patches here. Could be any of both, as the sender prefers. I personally prefer to have my patches in the tracker. (I know there are issues with mailing list reviews too, just trying to analyze the situation here) We also had periodic design meetings guiding features. I wonder if that kind of discussion could be had on the mailing list rather than in meetings. It's problematic to find a time that works for everyone and many people just doesn't have time to spend in irc. Yes after coordination issues we concluded we better keep discussing design topics in the mailing list. We have a prefix [DESIGN] for this. I will try to be more responsive to those threads from now on. Discussing design after the development is made isn't good, imho. I couldn't agree more. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fwd: Proposal on how to speed up patch reviews
Forgot to reply all... -- Forwarded message -- From: Daniel Narvaez dwnarv...@gmail.com Date: 25 March 2013 21:12 Subject: Re: [Sugar-devel] Proposal on how to speed up patch reviews To: Simon Schampijer si...@schampijer.de On 25 March 2013 12:37, Simon Schampijer si...@schampijer.de wrote: To improve that situation, I think we have to put some lights on all those roles and I think often the situation of the maintainer is not understood well enough. I can at least say that we had this discussions for the last years in Sugar, with different maintainers and I have seen it happening in many other projects as well. It is a known issue, and it is not an easy one, never less I think we can improve. In my experience Sugar has been much worst than both GNOME and mozilla though. I know it's not easy but we should keep trying. (I hope it's absolutely clear that I'm not blaming anyone for the situation, just pointing out the importance of fixing it or at least trying to) [bugfix] A bugfix is the simplest case. The submitter is interested in solving the specific issue he is working on. It is not hard to find a reviewer or tester. Either someone from the community that has been annoyed by the same issue or the maintainer himself because he is interested in seeing the issue solved, his interest is a working code base in the end. Here it is easy as well for a maintainer to trust another reviewer and acknowledge based on his positive review. In my experience those patches are not laying around for long if there is not a technical blocker in the patch itself. Evaluation is relatively easy here. I had at least one obvious bug fix patch unreviewed for months. Maybe I was unlucky. Anyway I agree this is the easiest of the cases and where things work best. [feature] When it gets to Features things get more tricky. For a Feature first of all the high level goals are important: what need does the Feature address, is it wanted by the community, is the technical approach taken a good one, basically the maintainer has to decide if it is worth taking on maintainership of this feature or not. In the end it might be him who has to deal with arising bug fixes and who is blamed if the software is not a solid product. While I agree with you in general, I think maybe we are exagerating a bit the responsibility of the maintainers a bit. I tend to think it's the whole community which will get the blame if things goes wrong... Maintainers have of course a very important role, but they should not feel like they alone into this. That might explain a general bigger resistance to features by maintainers. How can we help each other to make this a better process? I think narrowing the focus is the best we can do, but I'll elaborate more about that while answering Gonzalo email. [feature/UI] All what have been said above applies to the feature that adds UI as well. I have separated that item because it adds another complexity. We have the UI process for this (as written in the feature policy [1]). Basically it adds more care taking of all the roles involved. Even if we go with my propiosal, I think maintainers should keep a strong supervision role on features, UI or not. I'd say it's responsibility of the reviewer to make sure the maintainer is happy in this regard... we should add it to our review checklist (well we don't have one yet afaik, but we should). Online services patches, unreviewed for more than one month http://lists.sugarlabs.org/archive/sugar-devel/2013-February/041808.html Unreviewed for more than one month This one is part of the [feature] category. It can be mostly explained with the maintainers having their heads still in bug fixing for 0.98. Here applies as well what I said with high level descriptions of features and the feature process [2]. In an ideal world, a reviewer which is not busy with 0.98 should have given a first pass to the patches and at the same time started a discussion, involving the maintainer, about the oppurtunity of adding such a feature etc. * Let's separate the maintainer from the reviewer roles. Maintainers should be very expert because ultimately the future of the project is in their hands. Those kind of people are very rare. Though I think there are many more people that could do reviews on areas of the code they feel comfortable with. That sounds good to me. We actually are doing this more or less already. We can maybe make this more explicit and foster that principle. Especially for bug fixes I do not see a reason why I should not merge a patch that has r+/t+ from a trusted person if there is not an obvious issue. There a couple of important differences compared to what we are doing: * The reviewers are explicitly entrusted by the maintainers. So they know if they review the patches will most likely go in. It's often not very motivating to do reviews without being able to approve. * The reviewers takes care of
