Developer hire for mailnews
I'd like to start the discussion here about hiring another developer for
core mailnews code. Generally the expectation is that we would discuss
the need here, and if we reach a consensus make a recommendation to the
Thunderbird Council, who would have to agree that this makes sense
financially, and move that forward. Yes we are still in process with
some other hires, but this initial discussion can be done now.
I assume that our first priority is keeping Thunderbird buildable from
the current mozilla-central code. It's been clear for a long time that
there is more work to be done keeping comm-central compatible with
mozilla-central than can be done by our existing half-time staff
developer (Jörg). Also, we get warnings from Mozilla folks about
upcoming issues, and rarely do we have the resources to actually do the
required code changes ahead of time.
This position has been tentatively budgeted for awhile, but we have put
if off due to urgent needs to hire the infrastructure and build
engineers, as those were major pain points with Mozilla. Now we should
move forward with this.
The only real question that I have is, how much work do we believe there
is to keep up with m-c, guessing over the next year or so? Is that
another half-time? More than another full-time? Or maybe you don't agree
with this approach, and think we should be focused on feature
development or bug fixes?
:rkent
On 02/08/2017 23:03, R Kent James via Maildev wrote:
The only real question that I have is, how much work do we believe there is to keep up with m-c, guessing over the next year or so? Is that another half-time? More than another full-time? Or maybe you don't agree with this approach, and think we should be focused on feature development or bug fixes?
My person belief is that with another half-time position we should be able to keep up with M-C, even though the next few weeks will be hard since we're at mozilla57 and they will begin the slashing of unneeded code since for them XUL/XPCOM add-ons have been retired.
Any more resources could go into addressing some long-standing issues which will of course also fix bugs. Kent, you have a more comprehensive list, so I'll just mention a few things:
- Restructure search so that body search works on the decoded body and not the (base64) encoded one.
- Replace Mork
- Fix LDAP
- Kent recently mentioned something with views(?), I can't find it now.
Jörg.
On 02/08/2017 23:50, Jörg Knobloch via Maildev wrote:
My person belief is that with another half-time position we should be able to keep up with M-C, even though the next few weeks will be hard since we're at mozilla57 and they will begin the slashing of unneeded code since for them XUL/XPCOM add-ons have been retired.
... which I already said on the Council mailing list:
On 13/05/2017 10:06, Jörg Knobloch wrote:
- Gecko breakage: 2 - I think, 2 part-time positions should cover this, maybe with occisional help from the people from the next item.
- Review and bug fixes: 1 - Here you can stick as many as you want depending on what level of bug fixes you want. If you want to address technical debt (Mork, filters/MIME, etc. (Kent has a list)) then the sky is the limit. 2 part-time positions at least would be nice here. Note that currently we're operating far below an emergency level.
So if we hire one full-time person, they can help on keeping up with M-C and do grander things the rest of the time.
Jörg.
On 02.08.2017 21:03, R Kent James via Maildev wrote:
Hi folks,
I assume that our first priority is keeping Thunderbird buildable from
the current mozilla-central code. It's been clear for a long time that
there is more work to be done keeping comm-central compatible with
mozilla-central than can be done by our existing half-time staff
developer (Jörg).
I would appreciate if making things easier for external people (like
myself ;-)), to hack on the code, customize, trim down, package for
various targets, etc, etc. (most of that isn't tbird specific, but
moz in general) would become a high priority.
The biggest problem I see here is we've got a huge code base,
which is hard to undertand (if you're not working with it on a daily
basis). So, allocating some resources for helping newcomers
seem to be a good starting point.
I believe, if these things are solved, there'll be a lot more
contributors from the community, and tbird will get a bigger userbase
for non-standard environments (where customizations, eg. for specific
workflows, are required). Thus finally reduce the load on full time
developers in the long run.
The introduction of Rust added introduced a lot of new complexity
on distro/packaging side (toolchain handling, cargo vs. distro
packaging, etc, etc), which still take some time to sort out.
So I'm focusing on esr52.
My primary interests here are:
a) trim down - disable things I don't need (multimedia, geoloc, ...)
b) integration w/ other systems / external agents
c) improving performance / responsiveness (eg. I regularily observe
it hanging for several seconds)
By the way: if you've got open issues on esr52, just let me know.
--mtx
Hey Enrico,
would be nice to chat and get to know each other. My phone number is
+49-611-377777 .
Ben
Enrico Weigelt, metux IT consult via Maildev wrote on 03.08.2017 12:42:
On 02.08.2017 21:03, R Kent James via Maildev wrote:
Hi folks,
I assume that our first priority is keeping Thunderbird buildable from
the current mozilla-central code. It's been clear for a long time that
there is more work to be done keeping comm-central compatible with
mozilla-central than can be done by our existing half-time staff
developer (Jörg).
I would appreciate if making things easier for external people (like
myself ;-)), to hack on the code, customize, trim down, package for
various targets, etc, etc. (most of that isn't tbird specific, but
moz in general) would become a high priority.
The biggest problem I see here is we've got a huge code base,
which is hard to undertand (if you're not working with it on a daily
basis). So, allocating some resources for helping newcomers
seem to be a good starting point.
I believe, if these things are solved, there'll be a lot more
contributors from the community, and tbird will get a bigger userbase
for non-standard environments (where customizations, eg. for specific
workflows, are required). Thus finally reduce the load on full time
developers in the long run.
The introduction of Rust added introduced a lot of new complexity
on distro/packaging side (toolchain handling, cargo vs. distro
packaging, etc, etc), which still take some time to sort out.
So I'm focusing on esr52.
My primary interests here are:
a) trim down - disable things I don't need (multimedia, geoloc, ...)
b) integration w/ other systems / external agents
c) improving performance / responsiveness (eg. I regularily observe
it hanging for several seconds)
By the way: if you've got open issues on esr52, just let me know.
--mtx
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
R Kent James via Maildev wrote on 02.08.2017 23:03:
I'd like to start the discussion here about hiring another developer
for core mailnews code. Generally the expectation is that we would
discuss the need here, and if we reach a consensus make a
recommendation to the Thunderbird Council, who would have to agree
that this makes sense financially, and move that forward. Yes we are
still in process with some other hires, but this initial discussion
can be done now.
I assume that our first priority is keeping Thunderbird buildable from
the current mozilla-central code. It's been clear for a long time that
there is more work to be done keeping comm-central compatible with
mozilla-central than can be done by our existing half-time staff
developer (Jörg). Also, we get warnings from Mozilla folks about
upcoming issues, and rarely do we have the resources to actually do
the required code changes ahead of time.
This position has been tentatively budgeted for awhile, but we have
put if off due to urgent needs to hire the infrastructure and build
engineers, as those were major pain points with Mozilla. Now we should
move forward with this.
The only real question that I have is, how much work do we believe
there is to keep up with m-c, guessing over the next year or so? Is
that another half-time? More than another full-time? Or maybe you
don't agree with this approach, and think we should be focused on
feature development or bug fixes?
+1 from me for another part-time hire, to keep TB working after Gecko
changes.
Ben
On 8/3/2017 3:42 AM, Enrico Weigelt, metux IT consult via Maildev wrote:
I would appreciate if making things easier for external people (like
myself ;-)), to hack on the code, customize, trim down, package for
various targets, etc, etc. (most of that isn't tbird specific, but
moz in general) would become a high priority.
That issue is a main reason that we are trying to hire a community
manager at the moment.
:rkent
On 03/08/2017 17:34, R Kent James via Maildev wrote:
On 8/3/2017 3:42 AM, Enrico Weigelt, metux IT consult via Maildev wrote:
I would appreciate if making things easier for external people (like
myself ;-)), to hack on the code, customize, trim down, package for
various targets, etc, etc. (most of that isn't tbird specific, but
moz in general) would become a high priority.That issue is a main reason that we are trying to hire a community manager at the moment.
With all due respect, I don't see how a (mostly non-technical) community manager can make the highly complex code base more accessible. For that you need technical people to share their knowledge, but the technical people are flat out with keeping the show on the road and keeping up with reviews.
Jörg.
Jörg is probably in a prime position to evaluate how much work that will
take.
I do imagine the next months will be more intense than usual now that
they can and will remove all things that was kept just to play nice with
(traditional) extensions.
-Magnus
On 8/3/17 12:03 AM, R Kent James via Maildev wrote:
I'd like to start the discussion here about hiring another developer
for core mailnews code. Generally the expectation is that we would
discuss the need here, and if we reach a consensus make a
recommendation to the Thunderbird Council, who would have to agree
that this makes sense financially, and move that forward. Yes we are
still in process with some other hires, but this initial discussion
can be done now.
I assume that our first priority is keeping Thunderbird buildable from
the current mozilla-central code. It's been clear for a long time that
there is more work to be done keeping comm-central compatible with
mozilla-central than can be done by our existing half-time staff
developer (Jörg). Also, we get warnings from Mozilla folks about
upcoming issues, and rarely do we have the resources to actually do
the required code changes ahead of time.
This position has been tentatively budgeted for awhile, but we have
put if off due to urgent needs to hire the infrastructure and build
engineers, as those were major pain points with Mozilla. Now we should
move forward with this.
The only real question that I have is, how much work do we believe
there is to keep up with m-c, guessing over the next year or so? Is
that another half-time? More than another full-time? Or maybe you
don't agree with this approach, and think we should be focused on
feature development or bug fixes?
:rkent
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 03.08.2017 19:20, Jörg Knobloch via Maildev wrote:
That issue is a main reason that we are trying to hire a community
manager at the moment.
With all due respect, I don't see how a (mostly non-technical) community
manager can make the highly complex code base more accessible.
ACK. For that task a Community Manager (as I understand the term)
wouldn't be right thing - needs to be done by people w/ deeper
understanding of the code.
OTOH, a technically-skilled community manager could monitor the
discussions and write FAQ lists. Well, would be more a role of an
documentation manager.
By the way: if you're looking for people to hire, feel free to send
me your requirements and terms - perhaps I've got some suggestions
(no, I'm not a headhunter ;-)).
For that you need technical people to share their knowledge, but the
technical people are flat out with keeping the show on the road and
keeping up with reviews.
Smells like the typical scaling problem: add some point just adding more
resources doesn't speed up anymore.
Maybe retune the priorities - put new features aside for a while and
concentrate on cleanups and documentation and try to get more new people
involved as much as possible.
For the time being I'd suggest focusing on esr52, until the whole rust
complex is sorted out (supported by distros, ABIs stabelized, etc).
There's sill a lot to do yet.
--mtx
