Hi everybody, I have been working on Koha code for 3 years now. And for the last 2 years, I have been implied in the rebase of the BibLibre's patches and in the QA team. Many things have changed during this time. Koha is widely used throughout the world, and some great improvement have been made in the community workflow. However, I feel the need to share with you today my feelings and my frustration about our work methods. As I said, great improvements have been made in the patch integration workflow. Our process of validation and integration of the patches has lead to an improvement of the code. The respect of the basic coding rules - e.g. the indentation - makes the code easier to read and to understand, and then easier to modify. The unit test coverage has been expanded and we can now add new tests easily. It is also more secure to modify a core routine. All of these points are very positive to me: I enjoy developing in these conditions. But in parallel, I encounter difficulties with my patches queue. I try to spend time on every patch, to follow the coding guidelines and to produce clean and readable code, with unit tests. I try to write incremental patches, and understandable test plans (as far as my English level allows me to do...). I also try to QA as soon as I have spare time, and to rebase my patches as fast as possible not to block the signoffers. Concretely, the steps of the integration of a feature from my point of view as developer are: the customer orders a development. I start the development on the master branch (or a previous stable version). After several iterations, the customer agrees on the feature. I rebase the patch on a fresh master branch and I submit the patch in Bugzilla. I iterate with the signoffer and rebase the patch. At this time, the customer expects the feature to be in his production server. I then rebase the feature against his branch. The patch is finally signed after several months and several rebases against the master branch. This will usually need rebase and adjustment for the QA and/or the RM steps. When the customer version will be upgraded to the next release, I will once again adapt the feature - it may have differed from the initial feature. Sorry for this massive paragraph but the workflow is really as heavy as described (and this is the simple version...). The excessive duration of this integration process leads to several problems: - The developer is frustrated by these multiple rebases (trust me, it is really tiresome). - Regressions may be introduced following a badly fixed conflict - The development may need to be fully rewritten. - This is a lost of time not only for the developer, but also for the signoffer and the QAer. - Libraries and librarians may become frustrated too. I do not know how to fix these problems, but I would like to raise some points. The number of patches waiting for QA has decreased. This could be explained by the efforts of the QA team, but also by the decrease of SO patches - and thus by the decrease of patches going into the QA queue. The stack of patches waiting for SO is closed to 200, and my feeling is that the amount of weekly SO has never been so low. 2/3 of theses NSO are enhancements and 60 have been opened prior to 2013. This bottleneck will delay the development of future features. One of the more frustrating thing is to see passed QA patches regress to the does not apply status, because they have been queuing too long at the RM step. It regularly blocks me: I cannot make features for the customers when there are too many dependencies waiting to get pushed to the master branch. Galen, can you explain why there are patches that stay for months in a Passed QA status (26 patches are in passed QA since more than one month, without any activity)? I really would like to see activity on theses patches. I guess it is not always easy to make a decision about some patches - invaliding/rejecting them instead of pushing them. But I think it is better to go ahead or to reject a patch, rather than blocking it without explaining why. Does it mean that you would need help? Module maintainers have been elected for the 3.16 release: what will be exactly their roles? In your 3.14 proposal, you suggest naming master branch committers. Is this idea still topical or did you abandon it? I also have the feeling that the features have been pushed toward the end of the release cycle. Wouldn't it be more secure to push them at the beginning of the cycle, so they are more tested? I spend most of my time rebasing patches, instead of developing new ones or QAing others patches. I worked 40 days in 2013 for the community rebase. This includes the resolution of conflicts and the submission of followups. My time could have been better used. In my opinion, it is not by limiting the amount of pushed patches that we will reach the stability of Koha. Many "actives" patches - i.e. more than currently 600 patches with SO, need SO, Passed QA, in discussion and does not apply status - could fix problems or improve the code. Moreover, some of the submitted features refactor the code and add UT. These features are susceptible to improve the maintenance and the stability of Koha. In my opinion, the main problem is that there are too few active members in the community. The sandboxes have not been used as expected, judging by the low amount of signed patches from sandboxes. Currently most of the testers are not Koha users but rather developers. In France, some universities start to use sandboxes to signoff patches but do not have enough time to do it on a regular basis. Are there such initiatives in the other countries - for example India, Northern African countries, USA,.... ? I have tried regularly to spend personal time to develop improvements for Koha - such as rewriting the authorised values (new module), adding a logging module and rewriting the updatedatabase way. But after respectively 6 months, 1 year and 2 years of rebase, discussion, etc. Nothing happens anymore. My conclusion is sadly that it is not worth anymore investing my free time in Koha. I would like to know if this feeling is shared with other Koha developers or if I am the only one. How do you see the close future of Koha? Would you have any idea on how to improve the workflow? Do you have any idea to lead Koha users to be more implied in the testing process? Freely, Jonathan
I guess my follow up would be. Yes rebasing is frustrating and sucks a lot of time. I don't know the answers. But I would like to ask. What can we do better to get our patches accepted faster? (Is it really just sending Cait and Galen cookies everyday?)... There has got to be somethings that those devs who maybe aren't feeling the same frustration can lets us all know? -Brendan On Mon, Dec 9, 2013 at 10:36 AM, Jonathan Druart < jonathan.druart@biblibre.com> wrote:
Hi everybody,
I have been working on Koha code for 3 years now. And for the last 2 years, I have been implied in the rebase of the BibLibre's patches and in the QA team. Many things have changed during this time. Koha is widely used throughout the world, and some great improvement have been made in the community workflow. However, I feel the need to share with you today my feelings and my frustration about our work methods.
As I said, great improvements have been made in the patch integration workflow. Our process of validation and integration of the patches has lead to an improvement of the code. The respect of the basic coding rules - e.g. the indentation - makes the code easier to read and to understand, and then easier to modify. The unit test coverage has been expanded and we can now add new tests easily. It is also more secure to modify a core routine. All of these points are very positive to me: I enjoy developing in these conditions.
But in parallel, I encounter difficulties with my patches queue. I try to spend time on every patch, to follow the coding guidelines and to produce clean and readable code, with unit tests. I try to write incremental patches, and understandable test plans (as far as my English level allows me to do...). I also try to QA as soon as I have spare time, and to rebase my patches as fast as possible not to block the signoffers.
Concretely, the steps of the integration of a feature from my point of view as developer are: the customer orders a development. I start the development on the master branch (or a previous stable version). After several iterations, the customer agrees on the feature. I rebase the patch on a fresh master branch and I submit the patch in Bugzilla. I iterate with the signoffer and rebase the patch. At this time, the customer expects the feature to be in his production server. I then rebase the feature against his branch. The patch is finally signed after several months and several rebases against the master branch. This will usually need rebase and adjustment for the QA and/or the RM steps. When the customer version will be upgraded to the next release, I will once again adapt the feature - it may have differed from the initial feature. Sorry for this massive paragraph but the workflow is really as heavy as described (and this is the simple version...).
The excessive duration of this integration process leads to several problems: - The developer is frustrated by these multiple rebases (trust me, it is really tiresome). - Regressions may be introduced following a badly fixed conflict - The development may need to be fully rewritten. - This is a lost of time not only for the developer, but also for the signoffer and the QAer. - Libraries and librarians may become frustrated too. I do not know how to fix these problems, but I would like to raise some points.
The number of patches waiting for QA has decreased. This could be explained by the efforts of the QA team, but also by the decrease of SO patches - and thus by the decrease of patches going into the QA queue. The stack of patches waiting for SO is closed to 200, and my feeling is that the amount of weekly SO has never been so low. 2/3 of theses NSO are enhancements and 60 have been opened prior to 2013. This bottleneck will delay the development of future features.
One of the more frustrating thing is to see passed QA patches regress to the does not apply status, because they have been queuing too long at the RM step. It regularly blocks me: I cannot make features for the customers when there are too many dependencies waiting to get pushed to the master branch. Galen, can you explain why there are patches that stay for months in a Passed QA status (26 patches are in passed QA since more than one month, without any activity)? I really would like to see activity on theses patches. I guess it is not always easy to make a decision about some patches - invaliding/rejecting them instead of pushing them. But I think it is better to go ahead or to reject a patch, rather than blocking it without explaining why. Does it mean that you would need help? Module maintainers have been elected for the 3.16 release: what will be exactly their roles? In your 3.14 proposal, you suggest naming master branch committers. Is this idea still topical or did you abandon it? I also have the feeling that the features have been pushed toward the end of the release cycle. Wouldn't it be more secure to push them at the beginning of the cycle, so they are more tested?
I spend most of my time rebasing patches, instead of developing new ones or QAing others patches. I worked 40 days in 2013 for the community rebase. This includes the resolution of conflicts and the submission of followups. My time could have been better used. In my opinion, it is not by limiting the amount of pushed patches that we will reach the stability of Koha. Many "actives" patches - i.e. more than currently 600 patches with SO, need SO, Passed QA, in discussion and does not apply status - could fix problems or improve the code. Moreover, some of the submitted features refactor the code and add UT. These features are susceptible to improve the maintenance and the stability of Koha.
In my opinion, the main problem is that there are too few active members in the community. The sandboxes have not been used as expected, judging by the low amount of signed patches from sandboxes. Currently most of the testers are not Koha users but rather developers. In France, some universities start to use sandboxes to signoff patches but do not have enough time to do it on a regular basis. Are there such initiatives in the other countries - for example India, Northern African countries, USA,.... ?
I have tried regularly to spend personal time to develop improvements for Koha - such as rewriting the authorised values (new module), adding a logging module and rewriting the updatedatabase way. But after respectively 6 months, 1 year and 2 years of rebase, discussion, etc. Nothing happens anymore. My conclusion is sadly that it is not worth anymore investing my free time in Koha.
I would like to know if this feeling is shared with other Koha developers or if I am the only one. How do you see the close future of Koha? Would you have any idea on how to improve the workflow? Do you have any idea to lead Koha users to be more implied in the testing process?
Freely, Jonathan
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: Redding, CT Phone # (888) 900-8944 http://bywatersolutions.com info@bywatersolutions.com
On 10 December 2013 08:58, Brendan Gallagher <info@bywatersolutions.com> wrote:
I guess my follow up would be.
Yes rebasing is frustrating and sucks a lot of time. I don't know the answers. But I would like to ask. What can we do better to get our patches accepted faster? (Is it really just sending Cait and Galen cookies everyday?)... There has got to be somethings that those devs who maybe aren't feeling the same frustration can lets us all know?
Speaking for myself, I find if I do small patches, in a set, it is much easier for me to rebase. I also find rebase -i --onto a useful tool too. I prefer lots of tiny conflicts, to one patch with massive ones. Hopefully that is useful. I am also trying to work on some tools (in my spare time) to help make it easier to find patches to sign off. http://dashboard.koha-community.org/taskboard This is not finished yet, but it is all patches awaiting sign off, in date order (oldest first) colour coded by severity. If you mouseover you can see the description, if you click you can claim one. (The claim is not fully working yet) I plan to finish this, and have it refreshing so its up to date, so we can not double up on patches/bugs. I then plan to do one for the signed off patches, where the colours are who can QA them. I spent a lot of time when I was on the QA team clicking on a bug, then seeing oh its a Catalyst patch, or oh a Catalyst person signed this off. I want to make it easy to see which ones are available. Chris
Hi, On Mon, Dec 9, 2013 at 11:58 AM, Brendan Gallagher < info@bywatersolutions.com> wrote:
Yes rebasing is frustrating and sucks a lot of time. I don't know the answers. But I would like to ask. What can we do better to get our patches accepted faster? (Is it really just sending Cait and Galen cookies everyday?)... There has got to be somethings that those devs who maybe aren't feeling the same frustration can lets us all know?
As a general response to the specific question, which applies to all levels of the patch review process: one thing that helps is making one's patches easy to read. How? There's no magic formula, but several things that improve readability include: * Keep each patch small. Smaller patches are also easier to rebase. * Keep each patch focused -- ideally, each patch does one thing, and one thing only. By "one thing" I mean that it expresses one idea and that every part of that patch supports that idea. For example, a patch may add a new parameter to a routine and update each use of that routine, but it shouldn't *also* clean up an unrelated routine. * Make sure that the commit message expresses the idea that the patch is trying to achieve. * If you need to write several patches to implement a feature, try to make the patch series as a whole tell a story. For example (and this is *just* an example): patch 1: doom, doom has taken us all! (a summary of the problem, how the patch series will fix it, and the test plan) patch 2: but wait, here's a plan for happiness (automated test cases for changes to a core routine) patch 3: Achievement unlocked: happiness! (patch that fixes the core routine and the callers of it) patch 4: Make our happiness visible (patch that does user-visible template changes) * If at all possible, organize a patch series so that it is conceivable that a subset of the series can be pushed to master -- that would be one way of dealing with controversial parts of the series. * For a patch that goes through a lot of iterations of review: don't be afraid to squash them so that they tell a consistent story. Be sure to retain attribution if you squash, of course. * Don't get overly attached to your development branch or particular patches -- what ultimately matters is the master branch and the maintenance branches. Making sure that master is reasonably readable and definitely stable takes precedence. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
I can say Jonathan has pretty much summed up my feelings and experience as well. I think even now the vast majority of sign-offs are still done by developers. I try to balance my community work between sign-offs and qa'ing. I think the answer to the RM bottleneck is to push more work to the module maintainers. 1) MM pushes patches to each respective module branch 2) RM pulls from these branches to master Of course, there is a higher likelihood for merge conflicts, but I see no way around that, except to allow MMs to push to master. As for the SO bottleneck, I see know answer except for more encouragement for the end-users to test and sign-off, as well as absolutely clear, step-by-step test plans. Kyle
As for the SO bottleneck, I see know answer except for more encouragement for the end-users to test and sign-off, as well as absolutely clear, step-by-step test plans.
Yep, that's all I can see too, maybe I could work on some openbadges stuff, you could win badges by signing off... or a certificate .. do you think that would help? Chris
Salvete!
As for the SO bottleneck, I see know answer except for
more encouragement
for the end-users to test and sign-off, as well as absolutely clear, step-by-step test plans.
Yep, that's all I can see too, maybe I could work on some openbadges stuff, you could win badges by signing off... or a certificate .. do you think that would help? Hooray badgers! :D Then we can let them overrun the Patrons in the far flung future, too. >:) An even easier (read even *I* can manage this) way to do this is to shamelessly copy the Wikipedia Barnstar approach. Or we can merge the too. Whatevahs. :D Cheers, Brooke
Le 09/12/2013 21:25, Kyle Hall a écrit :
I can say Jonathan has pretty much summed up my feelings and experience as well.
I think even now the vast majority of sign-offs are still done by developers. I try to balance my community work between sign-offs and qa'ing.
I think the answer to the RM bottleneck is to push more work to the module maintainers.
1) MM pushes patches to each respective module branch 2) RM pulls from these branches to master
Of course, there is a higher likelihood for merge conflicts, but I see no way around that, except to allow MMs to push to master.
As for the SO bottleneck, I see know answer except for more encouragement for the end-users to test and sign-off, as well as absolutely clear, step-by-step test plans.
Hi Having been on the both sides for 1 year and half ("customer" and patch-tester), I agree too with most of Jonathan's remarks. For example, when your companies secure a contract with a new customer, do you make a demonstration of bugzilla and sandboxes ? And, in the different countries where you have contracts, do libraries using Koha organize meetings or local hackfest ? In France we try to do that, and even if it's not yet perfect, but I think the results are globally positive. Regards Mathieu
Kyle
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Mathieu Saby Service d'Informatique Documentaire Service Commun de Documentation Université Rennes 2 Téléphone : 02 99 14 12 65 Courriel : mathieu.saby@univ-rennes2.fr
On 10 December 2013 09:49, Mathieu Saby <mathieu.saby@univ-rennes2.fr> wrote:
Hi Having been on the both sides for 1 year and half ("customer" and patch-tester), I agree too with most of Jonathan's remarks.
For example, when your companies secure a contract with a new customer, do you make a demonstration of bugzilla and sandboxes ? And, in the different countries where you have contracts, do libraries using Koha organize meetings or local hackfest ? In France we try to do that, and even if it's not yet perfect, but I think the results are globally positive.
Yes we do, however there are only ever going to be a small percentage of patches that are able to be signed off in the sandboxes. Developers will (and should) have to do most of the sign offs, what we might need is a better way to 'swap' patches. I sign off yours, you sign off mine for example. So yep getting more clients to sign off is a cool goal, however getting more developers to sign off is even better. Chris
Developers will (and should) have to do most of the sign offs, what we might need is a better way to 'swap' patches. I sign off yours, you sign off mine for example.
I completely agree. I recall you were working on some sort of Karma system to track sign-offs and QA? Has then gotten off the ground? I think it would be helpful to be able to see who is signing patches both on an individual and organizational basis. If I know that Jonathan is spending a lot of time on my patches, I'll be more motivated to look at his to return the favor. On an organizational level, maybe a group of Catalyst employees have each tested my patches, so I know I should get more ByWater employees to test Catalyst submissions to balance it out. Kyle
On 11 December 2013 08:46, Kyle Hall <kyle.m.hall@gmail.com> wrote:
Developers will (and should) have to do most of the sign offs, what we might need is a better way to 'swap' patches. I sign off yours, you sign off mine for example.
I completely agree. I recall you were working on some sort of Karma system to track sign-offs and QA? Has then gotten off the ground? I think it would be helpful to be able to see who is signing patches both on an individual and organizational basis. If I know that Jonathan is spending a lot of time on my patches, I'll be more motivated to look at his to return the favor. On an organizational level, maybe a group of Catalyst employees have each tested my patches, so I know I should get more ByWater employees to test Catalyst submissions to balance it out.
Yep working on it, it will go somewhere on the dashboard, or maybe on the taskboard http://dashboard.koha-community.org/taskboard# You can see the signoffs currently on the dashboard http://dashboard.koha-community.org/ In the left hand column, by month. Mathieu and Katrin are winning for December so far. But it's not telling you which patches, so yes I still plan to work on that. Chris
Hi Jonathan
The number of patches waiting for QA has decreased. This could be explained by the efforts of the QA team, but
also by the decrease of SO patches - and thus by the decrease of patches going into the QA queue. The stack of
patches waiting for SO is closed to 200, and my feeling is that the amount of weekly SO has never been so low.
2/3 of theses NSO are enhancements and 60 have been opened prior to 2013. This bottleneck will delay the
development of future features.
I would suspect that these numbers will always fluctuate. In one or two weeks we might just have 150 in NSO and 100 in SO.
One of the more frustrating thing is to see passed QA patches regress to the does not apply status, because they
have been queuing too long at the RM step. It regularly blocks me: I cannot make features for the customers
when there are too many dependencies waiting to get pushed to the master branch.
I can understand that Galen does not always have the time to examine each patch when it enters PQA. But I would really like to see here more-or-less FIFO (first in, first out). First out could of course mean Failed QA or Discussion, but at least a change of state with some comments. The current situation, leaving them in PQA for long without any visible activity, does not motivate developers. (The FIFO rule would be fair also for the QA team, and even for signing off (bug wranglers !).. ) A FIFO rule should perhaps lower rebasing time too? When I joined the QA team, I did more or less adhere to FIFO when QAing, but the current workflow made me leave that approach.. If I have the idea that a patch set will probably go to sleep in PQA (without obvious reasons for failing it), I will not start QA on it either.
I spend most of my time rebasing patches, instead of developing new ones or QAing others patches. I worked 40
days in 2013 for the community rebase. This includes the resolution of conflicts and the submission of followups.
My time could have been better used. I have tried regularly to spend personal time to develop improvements for Koha - such as rewriting the
authorised values (new module), adding a logging module and rewriting the updatedatabase way. But after
respectively 6 months, 1 year and 2 years of rebase, discussion, etc. Nothing happens anymore. My conclusion is
sadly that it is not worth anymore investing my free time in Koha.
Your conclusion is very familiar (recognizable). More than once or twice I wrote patches that did not receive much attention; after rebasing a few times I now usually abandon them. A mechanism that would push us to sign off less-popular patches could perhaps help. Note that I still think that your investment of (free) time in Koha is worth it! Unfortunately do not assume that every patch will make it, but lots of them will .. Marcel
On 11/12/2013 3:08 am, "Marcel de Rooy" <M.de.Rooy@rijksmuseum.nl> wrote:
Hi Jonathan
The number of patches waiting for QA has decreased. This could be
explained by the efforts of the QA team, but
also by the decrease of SO patches - and thus by the decrease of
patches going into the QA queue. The stack of
patches waiting for SO is closed to 200, and my feeling is that the
amount of weekly SO has never been so low.
2/3 of theses NSO are enhancements and 60 have been opened prior to
2013. This bottleneck will delay the
development of future features.
I would suspect that these numbers will always fluctuate. In one or two
weeks we might just have 150 in NSO and 100 in SO.
One of the more frustrating thing is to see passed QA patches regress
to the does not apply status, because they
have been queuing too long at the RM step. It regularly blocks me: I
cannot make features for the customers
when there are too many dependencies waiting to get pushed to the
master branch.
I can understand that Galen does not always have the time to examine each
patch when it enters PQA. But I would really like to see here more-or-less FIFO (first in, first out). First out could of course mean Failed QA or Discussion, but at least a change of state with some comments. The current situation, leaving them in PQA for long without any visible activity, does not motivate developers. (The FIFO rule would be fair also for the QA team, and even for signing off (bug wranglers !).. ) A FIFO rule should perhaps lower rebasing time too? When I joined the QA team, I did more or less adhere to FIFO when QAing, but the current workflow made me leave that approach.. If I have the idea that a patch set will probably go to sleep in PQA (without obvious reasons for failing it), I will not start QA on it either.
In theory this sounds good, with the caveat bug severity can override it too. Of course we can make tons of suggestions, but it is really up to the RM how they use their time and we should be seeking to support them in what ultimately is a thankless role. Speaking from my experience of RMing (4 releases I think) almost all you ever get is complaints. Chris
I spend most of my time rebasing patches, instead of developing new
ones or QAing others patches. I worked 40
days in 2013 for the community rebase. This includes the resolution of
conflicts and the submission of followups.
My time could have been better used. I have tried regularly to spend personal time to develop improvements
for Koha - such as rewriting the
authorised values (new module), adding a logging module and rewriting
the updatedatabase way. But after
respectively 6 months, 1 year and 2 years of rebase, discussion, etc.
Nothing happens anymore. My conclusion is
sadly that it is not worth anymore investing my free time in Koha.
Your conclusion is very familiar (recognizable). More than once or twice
I wrote patches that did not receive much attention; after rebasing a few times I now usually abandon them. A mechanism that would push us to sign off less-popular patches could perhaps help.
Note that I still think that your investment of (free) time in Koha is
worth it! Unfortunately do not assume that every patch will make it, but lots of them will ..
Marcel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Le 10/12/2013 20:10, Chris Cormack a écrit :
In theory this sounds good, with the caveat bug severity can override it too. Agreed. When I was RM (4 releases too, 2 with the current workflow ;-) ), I used FIFO, except for BLO & CRI, which I was always dealing with 1st. And that was easy because bugzilla display them in red !
Of course we can make tons of suggestions, but it is really up to the RM how they use their time and we should be seeking to support them in what ultimately is a thankless role. It's the RM final cut, but it does not mean all other must shut up & just wait for another RM election (& candidate ;-) )
Speaking from my experience of RMing (4 releases I think) almost all you ever get is complaints. In the short term, maybe. But in the long term ... look at your karma Highest karma: "rangi" (962), "oleonard" (806), and "jcamins" (662)
... -- Paul POULAIN - BibLibre http://www.biblibre.com Free & Open Source Softwares for libraries Koha, Drupal, Piwik, Jasper
Hi, On Wed, Dec 18, 2013 at 8:49 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 10/12/2013 20:10, Chris Cormack a écrit :
In theory this sounds good, with the caveat bug severity can override it too. Agreed. When I was RM (4 releases too, 2 with the current workflow ;-) ), I used FIFO, except for BLO & CRI, which I was always dealing with 1st. And that was easy because bugzilla display them in red !
To be explicit, and no doubt obvious: I don't use FIFO. Patches for security bugs, blockers, and criticals will take precedence, but I tend to mull over patches, and in some cases wait for other patches to pass QA so that a clump of patches on the same topic can be pushed. As I'm sure is obvious, I both reject a lot of patches and write a lot of follow-ups, including resolving merge conflicts. My primary emphasis is ensuring that regressions are minimized and that the new release will be as stable as possible. If I were to suggest one micro enhancement to to the process -- or perhaps just sing the same old tune -- if you want to increase the changes that your patch goes through signoff, QA review, and RM review quickly -- keep your patches small and focused and don't be afraid to split up large patches into series. As far as larger enhancements to the process -- the module maintainer project has been slow to get off the ground, but I'll be pushing more on it after the holidays.
Of course we can make tons of suggestions, but it is really up to the RM how they use their time and we should be seeking to support them in what ultimately is a thankless role. It's the RM final cut, but it does not mean all other must shut up & just wait for another RM election (& candidate ;-) )
Indeed. Accountability is important to the process, and I agree that waiting for the next RM election is a bit long to wait. So, no need to shut up -- but also please remember that simply making complaints is not necessarily the most productive way to go about offering a critique. There are no robots involved in the process of signing off, QAing, or pushing patches (and keeping that in mind is why, if I had a *lot* more money, I would be organizing in-person global hackfests at least once every quarter).
Speaking from my experience of RMing (4 releases I think) almost all you ever get is complaints. In the short term, maybe. But in the long term ... look at your karma Highest karma: "rangi" (962), "oleonard" (806), and "jcamins" (662)
The IRC karma score is a bit of a game, and while I don't begrudge anybody that bit of fun, for various reasons I think it best that it not travel outside of #koha for risk of it being taken to seriously. There is a practice on the #code4lib channel that I think is a good one: each year, during the conference, karma scores are zeroed out. At the risk of derailing this thread -- I'm inclined to do that at the beginning of 2014. At Chris Cormack's request, I've zeroed his (and zeroed mine as well). Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Le 19/12/2013 06:53, Galen Charlton a écrit :
As far as larger enhancements to the process -- the module maintainer project has been slow to get off the ground, but I'll be pushing more on it after the holidays. +1
Indeed. Accountability is important to the process, and I agree that waiting for the next RM election is a bit long to wait. So, no need to shut up -- but also please remember that simply making complaints is not necessarily the most productive way to go about offering a critique. I've something to share here: I complain "a lot" on koha-devel. With a very limited success in convincing others. I was wondering why, and saw 2 possibilities: the 1st was my english, the second was that I came with a description of the problem, a suggested change/improvement/... , and, most of the time, the answers were criticising my suggestion, instead of agreeing about the problem.
My conclusion was = maybe I'm wrong, and should just explain the problem, not suggest a solution. Was I wrong ? About the problems Jonathan rised (and, as Jonathan boss, he showed me the email before sending it), I endorse the fact that there were maybe no suggested changes/improvements (or not enough). But it was not to be criticizing only. Our (Joubu & I) hope was that we could first agree that there was something to improve. Then find a way to improve it.
There are no robots involved in the process of signing off, QAing, or pushing patches (and keeping that in mind is why, if I had a *lot* more money, I would be organizing in-person global hackfests at least once every quarter). me too ;-) Announcement = We're organizing one every year since 2011, the next one will be in 2014, March, 10th - 14th (will announce it more visibly in a separate mail in january)
There is a practice on the #code4lib channel that I think is a good one: each year, during the conference, karma scores are zeroed out. At the risk of derailing this thread -- I'm inclined to do that at the beginning of 2014. At Chris Cormack's request, I've zeroed his (and zeroed mine as well). I was mostly kidding (and just wanted to express the fact that chris karma, outside from IRC, is very far from "*all* you get is complains")
I'm completely fine with zeroing karmas every year. -- Paul POULAIN - Associé-gérant Tel : (33) 4 91 81 35 08 http://www.biblibre.com Logiciels Libres pour les bibliothèques et les centres de documentation
I can understand that Galen does not always have the time to examine each patch when it enters PQA. But I would really like to see here more-or-less FIFO (first in, first out). First out could of course mean Failed QA or Discussion, but at least a change of state with some comments. The current situation, leaving them in PQA for long without any visible activity, does not motivate developers. (The FIFO rule would be fair also for the QA team, and even for signing off (bug wranglers !).. ) A FIFO rule should perhaps lower rebasing time too? When I joined the QA team, I did more or less adhere to FIFO when QAing, but the current workflow made me leave that approach.. If I have the idea that a patch set will probably go to sleep in PQA (without obvious reasons for failing it), I will not start QA on it either.
I concur with the caveat that bugs should always trump enhancements! So the queue should be ordered by bug severity, and by age within those severity groups. For example, right now I see a bug fix that I submitted first at the end of last year, and the last iteration in June, that still needs signed off! Kyle
participants (9)
-
Brendan Gallagher -
BWS Johnson -
Chris Cormack -
Galen Charlton -
Jonathan Druart -
Kyle Hall -
Marcel de Rooy -
Mathieu Saby -
Paul Poulain