Who wants to fork this project?

[advancingu]

Seeing that this extension is broken to the point of being unusable in a business context in Thunderbird 52+ (e.g. #542, #580)and seeing that there are 200+ open issues and several unmerged pull requests that are months old, I suggest that this project should be forked (once again) under a new maintainer.

@trim has been doing a lot of cleanup work in his fork already and seems to be farthest ahead @rkent has implemented fixes for Thunderbird 52 in his fork @jaroslawp has implemented timezone fixes in his fork

Does anyone of you have the time to maintain a fork?

[Trim]

Does anyone of you have the time to maintain a fork?

On my side, I clearly can't maintain a fork of this project: I'm not an experienced JavaScript/XUL developer and I have not access to exchange services except to an Exchange 2013 server provided by OVH (a French web hoster). So, I can't support anything else, because I don't have access to other Exchange version and other configurations (so I can't test Kerberos, Basic Auth connections,... IIRC only NTLM support is available).

As you noticed, I'm trying to do some experimental clean up of code to b at least compatible with current ECMAScript (as advised by the console debugger) and Exchange 2013. I'll be interested in helping on this scope, but I can't do more because of small spare time and little access to Exchange technologies.

As a developer I would be happy to help to maintain a fork by trying to use experimental/beta Thunderbird/Lightning builds at home and, may be, propose some patches, but I can't do more outside the scope defined above.

Hoping that it can clarify my current work/hobby about this project, Adrien

PS: More I'm working on this project, more I'm fascinated by the XUL/JavaScript technologies, that's really interesting ! Unfortunately, we all know that in some future these technologies (especially XUL) will be outdated and so we'll have to move further.

[zelch]

So, my suggestion would be a group project with several maintainers.

Clearly, one of the limits is going to be that most developers don't have access to an Exchange environment that they can modify at will, so the next obvious question is this:

Do we have people willing to give the developers accounts on their Exchange servers? Stuff like Kerberos and Basic Auth connections are less common, and so probably more valuable, but different Exchange versions would also help.

[martok]

Exchange 2010 currently connecting with Basic Auth here. But: The core developer(s) don't have to be able to test everything, that's what pull requests and approval votes are for... I'd guess that since this extension is still the main/only one available for TB, finding contributors with different setups won't be that much of a problem. That kinda reduces the workload to management and somewhat regular releases...

[bavincen]

Can someone help me with exchange account for contribution to this project ?

Thanks

On Fri, May 26, 2017, 19:30 martok notifications@github.com wrote:

Exchange 2010 currently connecting with Basic Auth here. But: The core developer(s) don't have to be able to test everything, that's what pull requests and approval votes are for... I'd guess that since this extension is still the main/only one available for TB, finding contributors with different setups won't be that much of a problem. That kinda reduces the workload to management and somewhat regular releases...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Ericsson/exchangecalendar/issues/598#issuecomment-304289605, or mute the thread https://github.com/notifications/unsubscribe-auth/AIAymWfKsh5GKYhoA3rvkM4cehb_Y-lJks5r9trogaJpZM4Nk2VZ .

[zelch]

So, I'm not a EMCAScript guy, and my time is limited, but I'm perfectly willing to help review and approve/deny pull requests and to try and do some release wrangling.

Like everyone else involved, I have access to a single Exchange setup which I am not an admin for, and so the testing that can be done before a release will be limited.

So, @trim @rkent @jaroslawp and @Cifik

Is there interest in setting up a new project for this and running with it? Again, I'm happy to help wrangle things and get it moving, but I'll be up front and say that my time is pretty limited and I'll probably vanish from time to time. I'm guessing that we are all in close to the same boat on that though.

(I'm also happy to not be involved and let the people actually writing the code handle it, but I want to see it happen and I'm happy to help.)

[StianOby]

Seems like @Trim has already put up an active fork here: https://github.com/Trim/exchangecalendar/tree/ec-4.0

Why not just pool all your resources into it?

[jaroslawp]

I'm afraid I will not be able to maintain such fork on my own due to time constraints (and I'm not that much up to date with XUL/JavaScript either ..), but would happily contribute / test (especially features alike autodiscovery / kerberos auth. support) to an existing fork ..

[advancingu]

I've just created an organization ExchangeCalendar and forked this repository into it. @Trim and @zelch are presently invited as members. If anyone else wants to join, let me know.

I think we can find a way to move this forward by working together. Can't be much worse than the current situation.

[advancingu]

@StianOby Ok, maybe I should have been more precise in specifying the goal of forking. The goal is not in the fork itself but to get patches integrated and releases going again.

[advancingu]

Oh, and https://github.com/ExchangeCalendar/exchangecalendar is the repository location. I'll look into merging the various PRs that are floating around later today.

[rkent]

I am way, way over committed at the moment so I am in no position to take over maintenance of this addon. But I am experienced both in EWS and Thunderbird (developer of ExQuilla, core reviewer in Thunderbird) so I am in a good position of being the last resort fixer of critical issues, such as the NTLM authentication issues that occurred in Thunderbird 52. I also maintain NTLM, Basic, and Office365 Exchange accounts for testing purposes. By "last resort" what I mean is that after several months of a critical issue, and failures by several other people to resolve the issue, I might consider looking at it. I make no claims this is adequate for anybody. But I do not actually use this addon myself, I only do this because some ExQuilla users rely on it.

I would strongly suggest that the addon be submitted to The Mozilla addon site so that updates are handled from a central location and not from a custom location. The custom nature of updates makes it very difficult to manage change when a maintainer abandons an addon. I've seen this movie several times before.

When that is done, a few issues. First, this is a massive addon with many violations of standards for listed Thunderbird addons, so it will have a hard time passing review without changes. The Thunderbird Council chair Philipp is also a member of the Mozilla addons team, including doing admin reviews, so he will probably end up doing the review, but under the normal process that might take several months. But I can negotiate with him on this. Second, to prevent a future crisis when the next maintainer goes away, please add thunderbird-accounts@mozilla.org as a co-owner of the addon, so that the Thunderbird Council can take control of the addon in the future if it is necessary to change ownership.

[advancingu]

@rkent Thanks for your input. I'm well aware that this is a big add-on with many issues. My primary goal is to at least get updates moving again and the add-on itself into a non-broken state. This will be at least better than the status quo where the add-on is de-facto abandoned. For now, I also don't have the resources to move the add-on forward to the point where it will pass a review but I will look into listing it, assuming this can be done without review. Is there anyone from Thunderbird who I could make member of the Github organization under which the new repository runs?

[rkent]

Thunderbird is now using the organization "thundernest" on github for projects. You can see the people list on https://github.com/orgs/thundernest/people Github has a "real user" policy so it is hard to support a virtual name like thunderbird-accounts like we do in other contexts. You should feel free to add me though (rkent) to the github organization for this addon.

[Trim]

Thanks @advancingu for the invitation to the ExchangeCalendar organization.

I think that was a good idea to create a commuity driven organization, but I think it was a bite fast to fork as this issue has been opened less than 1 week and there was few answers.

I understand you want to have things moving ahead, but I think we should let more time to @bavincen to give it's point of view. Indeed, it has answered here he needs some help to do tests with exchange accounts.

I propose to let some more time to current developpers to clarify the current situation of this repository. If they are interested to continue work here, I hope they can add more community developpers as member of this repository. If they can't, so we should work on a community based organization and invite them inside this one.

If there's no answer for few more days/weeks (?), we could then officialy fork the project, ask to Thunderbird to be integrated in their addon market place and modify code to point users to the new fork.

[advancingu]

@rkent I added you to the organization. The organization you linked has no visible members to the outside.

[camypaj]

Hi all, I would like to help/donate something to the project, but I'm not a developer (any more). I guess I could help with testing, but maybe you should figure out a model for donations, so that we could "tip" the project? Does that make sense at this point? Regards

[advancingu]

Closing this issue since the fork is now established and due to lack of response from original owner here.