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
