[OPEN-ILS-DEV] Mr. Rylander, we have a problem.
Ben Shum
bshum at biblio.org
Thu Mar 14 11:53:07 EDT 2013
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). 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).
>
> 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
More information about the Open-ils-dev
mailing list