Ben, Thank you. I wholeheartedly agree that we need further open and professional discussion about development procedures, and I think the conference is a great place to start. I know some folks that should be involved in the discussion won't be in attendance, but they have IRC in Canada :) and we can take notes, and nothing will be carved in stone on day one.
I understand and agree with your desire for more notice before the merge of feature branches, and I will commit to making sure I always provide that. I acted, as the release manager facing both a beta deadline and the needs of users who require the code represented in those branches, in what I believe to be the best interest of Evergreen, and I feel I succeeded as far as the code is concerned. I will work harder to succeed where my fellow Evergreen developers are concerned. Thanks again, --miker On Thu, Mar 14, 2013 at 11:53 AM, Ben Shum <[email protected]> wrote: > I was not around much yesterday, so I'm still playing catch up with > everything that's happened. But I feel that I need to say something in > this area as well. > > First of all, I'd like to emphasize that I am very grateful and > appreciative of efforts made by *all* developers in this community to bring > forward exciting new features and fixes for Evergreen over the last several > years. I've always felt that we do more good for the world with our > participation. > > That said, I am disappointed over the situation regarding Launchpad bug > 1154766 and other tickets merged suddenly yesterday. The one week waiting > period for pushing new features to master was agreed upon as only a > "recommendation" during the January dev meeting, but I have also taken it > close to my heart to abide more strictly by that recommendation. Prior, > I'd been at least twice approached by other core committers (not Jason or > Thomas) for pushing new features to master from bug tickets that they > wished to have had some more time to comment/work on, so I've been very > careful to pay attention to my own timing of commit work ever since. > > While I may not comment on every bug ticket that comes into Launchpad, > either for lack of time, knowledge, or otherwise, I do make great efforts > to read them all and assist with management of tickets to the best of my > ability. Jason and Thomas are not the only ones who are looking at tickets > in Launchpad regarding upcoming new features. I also was in the process of > informing catalogers at Bibliomation about potential upcoming changes to > the Acquisitions interface yesterday and getting geared up to help > test/review the changes. Seeing those changes committed so soon after they > were announced did not give us much opportunity there alas. This is not to > say we cannot do our testing directly off code committed to master (it's an > ever-changing target and we often do that since we can't possibly test out > everything on our own end), but I do think it could have been handled a > little differently. > > In the future, I would appreciate a little more notice (perhaps begging > the patience of all developers) and consideration for a stronger adherence > to the recommended waiting period before pushing any new features. > Evidently, we have passed over an unseen line alluded to in the January > meeting and need to be clearer in our development processes and approaches. > I do think that certain exceptions should be made available to the release > managers for handling various situations, but I'd like to see the role and > options available to them more clearly defined as well. > > Motivations aside, I feel that we're all very passionate about how > Evergreen development happens, so I'd like to encourage further open and > professional discussion about this in channels or perhaps when we meet in > Vancouver next month. > > -- Ben > > > > On 03/14/2013 09:11 AM, Jason Stephenson wrote: > >> Mike, >> >> You don't pay enough attention when someone is trying to tell you >> something. >> >> Yesterday, I was very angry about Launchpad bug 1154766 >> (https://bugs.launchpad.net/**bugs/1154766<https://bugs.launchpad.net/bugs/1154766>). >> I did not appreciate that >> the first email I received from Launchpad had a "Fix Committed" >> status. I objected to this fact rather vociferously on the bug and in >> IRC. My point was that no one outside of ESI had a chance to even >> look at this new feature before it had gone into master. >> >> You took this as a complaint that *I* had not had a chance to look at >> it. You seemed to imply that this was a contest about who had more >> commits, or something. >> >> While your point that very few people are reviewing other people's >> commits and that many branches have sat for months with no apparent >> action on them is well taken. That is, however, beside the point of >> my argument. >> >> It was agreed at the January developers' meeting that new features >> should wait a week before going into master. This was in order to >> give others in the community a chance to look at, to ask questions >> about, and to comment on the new functionality or its implementation. >> >> You seem to be under the mistaken apprehension that no one in the >> community outside of Equinox is looking at Launchpad. Thomas and I do >> regularly look at code posted via Launchpad. In the vast majority of >> cases, we have no opinion on the code or don't feel competent to judge >> the code on its merits. (The latter is most often true with >> acquisitions and serials since our consortium does not use these >> features.) I do, however, regularly update my development branches >> with branches posted from Launchpad. When I have the chance to test >> something to my satisfaction, I will sign off and commit it. I also >> load acquisitions and serials branches on this server for Kathy >> Lussier to review. In fact, she was looking at all of the >> acquisitions improvements branches that went into master yesterday, >> plus a couple of others. Perhaps we are not fast enough for you, but >> we are looking at this work. We do have other responsibilities, you >> know. >> >> You also mistakenly asserted that development is Thomas's primary role >> at MVLC. It is not. He spends most of his day resolving internal >> issues for our members and making sure that our servers continue to >> run smoothly. Development of Evergreen is only a secondary part of >> his job, if even that. He produces the volume of code that he does >> because he enjoys programming enough to work on Evergreen on his own >> time at home. You made your assumption and you accused Thomas of not >> helping the community based solely on the commit statistics from the >> last year that you posted to Launchpad yesterday >> (https://bugs.launchpad.net/**evergreen/+bug/1154267/**comments/2<https://bugs.launchpad.net/evergreen/+bug/1154267/comments/2> >> ). >> >> Looking at these statistics, I think you will have to admit that I am >> probably the most balanced of the committers when it comes to number >> of commits of my own that go in compared to the number of commits of >> others that I push. I am just about 50/50 in that regard. Further, >> if you look at who the authors are of the branches that I commit, the >> vast majority are from Equinox developers. I also push more commits >> from non-committers than I have committed of Thomas's code. >> >> Thomas and I have an agreement to push as little of each others' code >> as possible precisely to avoid contentious arguments such as this with >> the rest of the community. >> >> Furthermore, I cannot count the number of times that we have told our >> members--the people who pay our salaries!--that they cannot have some >> feature they desired because we knew that the community would not like >> it, or would not like the way that our members want us to implement >> it. The community is larger than MVLC, or ESI and her customers. The >> community is larger than C/W MARS, NOBLE, and MassLNC. The community >> includes Indiana, Georgia PINES, SC LENDS, MELCAT, Bibliomation, >> Laurentian University, Mohawk College, TADL, and a whole host of >> others. We do our best to consider everyone's needs as well as we >> understand them before we undertake any development work, and if we >> are unsure we ask, via IRC, Launchpad, and/or email. >> >> Hence, the desire for the waiting period. Many of the above have >> developers either on staff or under contract. They can look at >> Launchpad and can comment on development. However, when code is >> pushed and bugs practically created in the Fix Committed status, none >> of them have the opportunity to look, to comment, nor to test the code >> if they so desire. This, Mr. Rylander, is the reasone for my >> expression of anger in IRC and on Launchpad yesterday. No one outside >> of Equinox was given so much as a "Hey, we're working on this," before >> the code was committed to master. This is not a personal contest >> between MVLC and ESI about the number of commits. This is about the >> community, communication and respect for the same. ESI's actions with >> this new feature show a lack of regard for the community. >> >> I understand that as 2.4 Release Manager you have some prerogatives in >> this domain. However, that title does not grant you a dictatorial >> positon, and you should in fact have a greater regard for the >> community as a whole in that position, and not just your company's >> contractual obligations to her customers. >> >> Finally, I want to apologize to everyone for exploding on the >> Launchpad ticket and in IRC as I did yesterday. It was unprofessional >> of me and inexcusable. I also no longer consider myself the Chief Bug >> Wrangler. I do not deserve the title, since I have not really kept up >> with the duties of that position over the past several months. If you >> like, consider this a formal and final resignation from that position. >> >> >> > -- > Benjamin Shum > Open Source Software Coordinator > Bibliomation, Inc. > 32 Crest Road > Middlebury, CT 06762 > 203-577-4070, ext. 113 > > -- Mike Rylander | Director of Research and Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
