[OPEN-ILS-DEV] Mr. Rylander, we have a problem.

[Mike Rylander]

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 <bshum at biblio.org> 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:  miker at esilibrary.com
 | web:  http://www.esilibrary.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20130314/1afd4892/attachment-0001.htm>