The next phase of Thunderbird development and TB:NG
TL:DR: We need to move forward under the assumption that TB:NG is not
likely to happen, and get on with improving our existing codebase.
It's time for Thunderbird to start hiring code code developers, and
there are a number of issues that need to be sorted to properly know the
kind of people we should be hiring, and what they will be tasked with
doing. We can all agree that in the short term, it is critical that we
have sufficient developers to keep the existing codebase buildable
against a changing Gecko. However, we can afford to devote resources
beyond that minimal requirement based on our current estimates of
technical needs and available funding. So the big issue that must be
agreed on before we can proceed with planning is what to do with the
proposals for a complete rewrite of Thunderbird from scratch, which I'll
call (following BenB) TB:NG.
We discussed this on tb-planning, and on the Thunderbird Council, but
never really reached any resolution. That is not an acceptable
situation. We are now left with the vague sense that any work to improve
our code code is somehow doomed to be thrown away soon, yet with no real
viable way to move forward with the alternative rewrite promised by TB:NG.
First, let's try to understand what it would take (from my perspective)
for TB:NG to happen.
The main premise is that it would take a substantial commitment of funds
to dedicate to this project, really beyond what we have any reasonable
hope of raising without some major changes in fund raising strategy.
Before we could have any hope of a major change in fund raising
strategy, we would need to have a much clearer sense of what our
critical contribution to the world is that would justify asking for and
receiving a vastly increased flow of donations or grants. So the first
sign that we have any hope of moving forward with TB:NG is that we
develop a compelling vision statement and communication of that
statement. Now those are beyond the scope of this mailing list, but
let's be honest, this is not happening. Even if that happens, we would
then need to actually raise those funds, AND convince ourselves
technically that the best way forward is a rewrite from scratch, rather
than a gradual improvement of the existing codebase.
Those are all very significant hurdles to overcome, and there is no
progress in that direction, nor does there seem to be much interest in
devoting resources to the marketing, PR, and strategy roles that would
be needed to move that forward initially. We can say all we want that we
can and should be doing this ourselves with our volunteers or
leadership, but the reality is that we are not.
So my premise is that we need to move forward under the assumption that
TB:NG is not likely to happen, and get on with improving our existing
codebase.
There is one possible compromise position. That would be to focus
initially on some projects that would improve Thunderbird, but would be
code that would be usable in a TB:NG. One possible candidate for that
would be a rewrite of our front-end thread pane, but that is only a
suggestion, there might be others that are better options. Those
projects might also help us to gauge how difficult it will be to rewrite
subsets of Thunderbird without redoing the design from scratch.
I would like to see if there is a rough consensus here for the statement
that we need to start devoting resources to improving Thunderbird, and
not hold back under some hope of a TB:NG project in the near future.
:rkent
+1 to R Kent's words.
And I would like to take the following compromise position and his
suggestion:
On 8/10/17 6:18 AM, R Kent James via Maildev wrote:
There is one possible compromise position. That would be to focus
initially on some projects that would improve Thunderbird, but would
be code that would be usable in a TB:NG. One possible candidate for
that would be a rewrite of our front-end thread pane, but that is only
a suggestion, there might be others that are better options. Those
projects might also help us to gauge how difficult it will be to
rewrite subsets of Thunderbird without redoing the design from scratch.
Also I'm not that a virtuous softworker as others on the list I took the
chance to support the group of students at the Victoria University of
Wellington for a new TB/Addressbook. It was developed with the mindset
to overcome mork (replace with db) and to use modern technology for the
software design (html5 and friends, using react). It was designed as a
standalone solution which could be extended later to be adapted to the
mature TB or a future TB:NG.
At least the project delivery a good impression about the obstacles and
chances for such a move.
Currently I'm working to improve the project and it's a good time to
think about bringing it to the table. For further work and direction the
project needs some very elementary decisions, points like:
-- technology base (html5/react, db, how to handle and migrate classic
XUL calls, using linting .. up to: is it necessary describe a typical
dev environment to support volunteers better for a startup helping TB),
-- how would the UI be designed (follow mature TB or take a modern
design approach)
-- should a new TB/AB be offered as an alternative alongside the classic
AB .. and also as a standalone solution with the idea to support other
platforms (mobile world)
FMPOV this project could be helpful to find answers for a lot of the
pending questions around a possible TB:NG approach.
On 8/9/2017 11:18 PM, R Kent James via Maildev wrote:
TL:DR: We need to move forward under the assumption that TB:NG is not
likely to happen, and get on with improving our existing codebase.
It's time for Thunderbird to start hiring code code developers, and
there are a number of issues that need to be sorted to properly know
the kind of people we should be hiring, and what they will be tasked
with doing. We can all agree that in the short term, it is critical
that we have sufficient developers to keep the existing codebase
buildable against a changing Gecko. However, we can afford to devote
resources beyond that minimal requirement based on our current
estimates of technical needs and available funding. So the big issue
that must be agreed on before we can proceed with planning is what to
do with the proposals for a complete rewrite of Thunderbird from
scratch, which I'll call (following BenB) TB:NG.
We discussed this on tb-planning, and on the Thunderbird Council, but
never really reached any resolution. That is not an acceptable
situation. We are now left with the vague sense that any work to
improve our code code is somehow doomed to be thrown away soon, yet
with no real viable way to move forward with the alternative rewrite
promised by TB:NG.
I've said in earlier emails that the biggest mistake we've made in the
past is holding features hostage to the kinds of rewrites envisioned by
TB:NG.
So my premise is that we need to move forward under the assumption
that TB:NG is not likely to happen, and get on with improving our
existing codebase.
There is one possible compromise position. That would be to focus
initially on some projects that would improve Thunderbird, but would
be code that would be usable in a TB:NG. One possible candidate for
that would be a rewrite of our front-end thread pane, but that is only
a suggestion, there might be others that are better options. Those
projects might also help us to gauge how difficult it will be to
rewrite subsets of Thunderbird without redoing the design from scratch.
There are some features that we lack that are utterly
inexcusable--CardDAV support first and foremost. We absolutely need some
path forward that lets us get these features in soon, and waiting on a
rewrite, or even rebuilding our architecture for that rewrite, does not
seem like the right path forward.
Very little of our codebase is in such dire condition that it is
outright unmaintainable, although there is somewhat more where the
current API impedes improvement. On the other hand, the chief problem
with TB:NG is that it envisions an end-goal that is still unclear. At
the moment, it's possible for me to initiate a discussion on how to
improve, say, our database API to allow for multithreaded, asynchronous
access. It is possible to make improvements to our codebase right now,
and possible to guide contributors to areas they could help improve.
Meanwhile, if someone wants to start working on TB:NG, where do we point
them?
Rewriting for rewriting's sake is not a good idea. Even technologies
that seem deprecated and ready to die take a long time to do so. For
example, even though XUL is supposedly going away, it's worth mentioning
that XUL tree has been implemented in Stylo.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
Agreed, moving the current codebase forwards is very logical.
The goal of moving to web technologies as much as possible should be
kept, as it will be needed eventually.
-Magnus
On 8/10/17 7:18 AM, R Kent James via Maildev wrote:
TL:DR: We need to move forward under the assumption that TB:NG is not
likely to happen, and get on with improving our existing codebase.
It's time for Thunderbird to start hiring code code developers, and
there are a number of issues that need to be sorted to properly know
the kind of people we should be hiring, and what they will be tasked
with doing. We can all agree that in the short term, it is critical
that we have sufficient developers to keep the existing codebase
buildable against a changing Gecko. However, we can afford to devote
resources beyond that minimal requirement based on our current
estimates of technical needs and available funding. So the big issue
that must be agreed on before we can proceed with planning is what to
do with the proposals for a complete rewrite of Thunderbird from
scratch, which I'll call (following BenB) TB:NG.
We discussed this on tb-planning, and on the Thunderbird Council, but
never really reached any resolution. That is not an acceptable
situation. We are now left with the vague sense that any work to
improve our code code is somehow doomed to be thrown away soon, yet
with no real viable way to move forward with the alternative rewrite
promised by TB:NG.
First, let's try to understand what it would take (from my
perspective) for TB:NG to happen.
The main premise is that it would take a substantial commitment of
funds to dedicate to this project, really beyond what we have any
reasonable hope of raising without some major changes in fund raising
strategy. Before we could have any hope of a major change in fund
raising strategy, we would need to have a much clearer sense of what
our critical contribution to the world is that would justify asking
for and receiving a vastly increased flow of donations or grants. So
the first sign that we have any hope of moving forward with TB:NG is
that we develop a compelling vision statement and communication of
that statement. Now those are beyond the scope of this mailing list,
but let's be honest, this is not happening. Even if that happens, we
would then need to actually raise those funds, AND convince ourselves
technically that the best way forward is a rewrite from scratch,
rather than a gradual improvement of the existing codebase.
Those are all very significant hurdles to overcome, and there is no
progress in that direction, nor does there seem to be much interest in
devoting resources to the marketing, PR, and strategy roles that would
be needed to move that forward initially. We can say all we want that
we can and should be doing this ourselves with our volunteers or
leadership, but the reality is that we are not.
So my premise is that we need to move forward under the assumption
that TB:NG is not likely to happen, and get on with improving our
existing codebase.
There is one possible compromise position. That would be to focus
initially on some projects that would improve Thunderbird, but would
be code that would be usable in a TB:NG. One possible candidate for
that would be a rewrite of our front-end thread pane, but that is only
a suggestion, there might be others that are better options. Those
projects might also help us to gauge how difficult it will be to
rewrite subsets of Thunderbird without redoing the design from scratch.
I would like to see if there is a rough consensus here for the
statement that we need to start devoting resources to improving
Thunderbird, and not hold back under some hope of a TB:NG project in
the near future.
:rkent
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 10.08.2017 06:18, R Kent James via Maildev wrote:
Hi,
TL:DR: We need to move forward under the assumption that TB:NG is not
likely to happen, and get on with improving our existing codebase.
what's the actual idea behind TB:NG ?
It's time for Thunderbird to start hiring code code developers, and
there are a number of issues that need to be sorted to properly know the
kind of people we should be hiring, and what they will be tasked with
doing.
Maybe hire some freelancer on per-task basis ?
We can all agree that in the short term, it is critical that we
have sufficient developers to keep the existing codebase buildable
against a changing Gecko.
It seems Gecko is currently changing a lot. Maybe just wait a while
and stay on latest stable, until things have cooled down ?
Is there anything that Tbird really needs from newer Gecko in the
near future ?
So the big issue that must be agreed on before we can proceed with planning
is what to do with the proposals for a complete rewrite of Thunderbird
from scratch, which I'll call (following BenB) TB:NG.
What's the actual goal behind a rewrite from scratch ?
What would that make better than currrent tbird and all the other MUAs
out there ?
I'd rather prefer a consequent evolution, carefully take it apart into
separate programs and try to reuse components with other projects or
collaborate with others to get common stuff in common libraries.
(eg. things like mailbox or address book handling).
IMHO, the problem isn't a lack of features, but a lack of integration.
And of course the imense size of the code base (w/ moz-central).
We are now left with the vague sense that any work to improve
our code code is somehow doomed to be thrown away soon, yet with no real
viable way to move forward with the alternative rewrite promised by TB:NG.
Why is it doomed to be thrown away ?
Which things exactly do you have in mind here ?
I would like to see if there is a rough consensus here for the statement
that we need to start devoting resources to improving Thunderbird, and
not hold back under some hope of a TB:NG project in the near future.
ACK.
--mtx
On 10.08.2017 12:35, neandr via Maildev wrote:
Also I'm not that a virtuous softworker as others on the list I took the
chance to support the group of students at the Victoria University of
Wellington for a new TB/Addressbook. It was developed with the mindset
to overcome mork
That's a good idea. Can I get the code somewhere ?
(replace with db)
Berkeley-DB ? That would make interfacing with other systems, backups,
troubleshooting, ... OTOH, sqlite is used more widely nowadays.
It was designed as a
standalone solution which could be extended later to be adapted to the
mature TB or a future TB:NG.
Actually, one of my todo's is moving out the whole contacts handling
to an external (system/user-wide) service (most likely via 9p) and let
the operator/user decide how/where that data should be actually stored.
This service, of course, is meant to be used for other applications, too
-- technology base (html5/react, db, how to handle and migrate classic
XUL calls, using linting .. up to: is it necessary describe a typical
dev environment to support volunteers better for a startup helping TB),
I'd concentrate on a service interface, first. Something that can be
easily implemented in basically any language. 9P is a good candidate
for this. Then, frontends for whatever taste can be implemented
(and deployed) independently. (yes: even for tbird, I'd like to see
that in a separate program)
--mtx
On 10/08/2017 23:37, Enrico Weigelt, metux IT consult via Maildev wrote:
Also I'm not that a virtuous softworker as others on the list I took the chance to support the group of students at the Victoria University of Wellington for a new TB/Addressbook. It was developed with the mindset to overcome mork
That's a good idea. Can I get the code somewhere ?
https://github.com/Thunderbird301/react-addon
https://bugzilla.mozilla.org/show_bug.cgi?id=1302253
I've never seen a working version.
Jörg.
Thanks Jörg for mentioning the VUW project and the pages about it.
Please move over to the current project status [*] which is based on
that VUW project. It's a fork of initial code and some further
developments and corrections.
That version should be working also it lakes much of features required
to be a real replacement of the classic TB/AB. As mentioned it's an
attempt to test how a new write can be fitted with the classic TB.
It would be helpful to not only get help for further development, but
much more important to start a discussion how a new partial app for
TB:NG should/would look like and which are the essentials for development.
[*] See here on git:
https://github.com/neandr/vContacts
https://neandr.github.io/vContacts/notes.txt
You should be able to download the XPI from here:
https://github.com/neandr/vContacts/releases
Günter
On 8/11/17 6:36 PM, Jörg Knobloch via Maildev wrote:
On 10/08/2017 23:37, Enrico Weigelt, metux IT consult via Maildev wrote:
Also I'm not that a virtuous softworker as others on the list I took
the chance to support the group of students at the Victoria
University of Wellington for a new TB/Addressbook. It was developed
with the mindset to overcome mork
That's a good idea. Can I get the code somewhere ?
https://github.com/Thunderbird301/react-addon
https://bugzilla.mozilla.org/show_bug.cgi?id=1302253
I've never seen a working version.
Jörg.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net
On 11/08/2017 19:31, neandr via Maildev wrote:
That version should be working also it lakes much of features required
to be a real replacement of the classic TB/AB. As mentioned it's an
attempt to test how a new write can be fitted with the classic TB.
Hi,
well, I installed the XPI and it does nothing as far as I can see. Where
is the UI to operate it? I couldn't detect anything.
Jörg.
You need to place an icon on the menu bar. Please use the TB hambg menu
to open the Perferences --> Toolbar Layout and d&d the "vContacts" icon
onto one of your menu/toolbars. Start with that getting two default
contacts.
Currently there is another problem, you need to use TB Daily, my current
version is 56.0a1.
Others like 45.8.0, 52.2.1, 54.0a2 don't work for me, I'm on Mint 17.3.
There is one console output saying:
XML-Verarbeitungsfehler: nicht wohlgeformt
Adresse: chrome://react/content/tab-overlay.xul
Zeile Nr. 25, Spalte 11: tab-overlay.xul:25:11
but that's also on the Daily. With the other versions I have seen
Promises errors, would have to have a deeper look for that.
Please let me know if you could start and work with it.
To work with your own addresses you can export from TB/AB with LDIF
format and import it within vContacts. There is also a random vCard
generator available. See here:
https://github.com/neandr/vContacts/tree/master/generateVCF
Günter
On 8/11/17 9:04 PM, Jörg Knobloch via Maildev wrote:
On 11/08/2017 19:31, neandr via Maildev wrote:
That version should be working also it lakes much of features
required to be a real replacement of the classic TB/AB. As mentioned
it's an attempt to test how a new write can be fitted with the
classic TB.
Hi,
well, I installed the XPI and it does nothing as far as I can see.
Where is the UI to operate it? I couldn't detect anything.
Jörg.
Maildev mailing list
Maildev@lists.thunderbird.net
http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net