You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The entire community is welcome to tune in and observe the meeting live at the time below. The following people are listed here as explicit invitees to get an email notification about the upcoming meeting:
Invited:
@expressjs/express-tc
@expressjs/triagers
Please use the following emoji reactions in this post to indicate your
availability.
@wesleytodd and @dougwilson - In this case, the only credentials to share are for Zoom, so that you can log in as host and kick off live streaming.
For YouTube, we don't share credentials. Instead, you add accounts as manager or owners. Please feel free to share with me (bwarner@linuxfoundation.org) as an Owner, and that way I can escrow the ownership and add people if they need it.
In general, anybody who will kick off a live stream just needs to be a manager.
@wesleytodd for number 4 (the YouTube channel) I am 100% on board but I just don't know how to do that and need some kind of instructions. The only method I know if needs a phone number. See #94
@brianwarner The goal, as you say, is that someone on the foundation also has access to the YT credentials in case of an emergency. And I already have the zoom credentials, we just need @dougwilson to also have them shared with him on whichever email he registers with LastPass on.
For the YT account, is there a foundation phone number we can use on the account? I am happy to offer up my number if we need it, but I agree it would be better to use a shared one instead of one of our personal numbers.
I ran up against this with other YouTube accounts... I've verified as many as I can before my own timer resets (two per number per year). Are you able to verify it with yours? Otherwise, I'm not sure when I get to start verifying again.
@dougwilson Do you have time tonight to work this out? At least before tomorrow morning can we get the new google account created and the account shifted over? Like I said, I am happy to use my personal phone as a stop gap.
Let me see about starting it. I think Doug might not be able to attend, but we can go at it for now, but it still means that it wont be streamed. Here is the new link: https://zoom.us/j/570940962
IIRC, re: req/res extraction change being included in 5:
pro: good to go with other breaking changes, or else we will have to wait till 6, which may be an year or more from now
con: more change in 5, more work to do
I guess @wesleytodd said he will be able to develop, test, land and publish in 2 week's time. If so, I am leaning towards that option, but would be good to know if there are other considerations than I quoted above?
I would like to get breaking changes completed by this weekend so we can publish an RC instead of a beta version. I believe @gireeshpunathil that was something you were championing before? To move on and not start like a beta cycle? If we're not doing with breaking changes I can't actually publish it as an RC, it would be another alpha or a beta.
The other consideration I had also came fro. your feedback of having too many breaking changes piled in to the same release. This one seems more so as the breaking change it not enabling some new use case or feature, right? Seems that it would at this point be a breaking change for the sake of it, which seems weird to try and smoosh into 5 at this point.
There is the settings breaking change that actually seems useful compared to this, yet it seems odd this would be more important than the settings change?
This one seems more so as the breaking change it not enabling some new use case or feature, right?
Seems that it would at this point be a breaking change for the sake of it, which seems weird to try and smoosh into 5 at this point.
There is the settings breaking change that actually seems useful compared to this, yet it seems odd this would be more important than the settings change?
unfortunately, my experience in this project is insufficient to make an assertion in either way on these points. @wesleytodd - can you please pitch in and ratify with @dougwilson on this?
I believe @gireeshpunathil that was something you were championing before? To move on and not start like a beta cycle?
Yes. I am still holding on to that; we should do what it takes to release RC -> GA, not alpha or beta
The other consideration I had also came fro. your feedback of having too many breaking changes piled in to the same release.
Yes. For the wider interest of the ecosystem (to consume majors / migrate with less pain). But from the nature of the change in question, it is not necessarily a definite breaking change? only code that assumed internal code layout and depended on that will be affected?
In either way, I think this is something that can be sorted out quickly between you and @wesleytodd , unless others have strong opinions!
Yes. I am still holding on to that; we should do what it takes to release RC -> GA, not alpha or beta
Yea, and I have come to agree with you on that, as a way to get this out. The path to regexp giant breaking change is compete and just needs to be released. The sooner we can release for community to test, I think the smoother it will be. But that then means that we can delay the release of that for testing to wait for more of these other changes to land and then make a RC or not wait and release another alpha or a beta...
I just sent the recording to @dougwilson. The plan is to upload it to YT. I will try to follow up on the rest of the stuff later, but I have some stuff to do today before I am OOO next week, so sorry for the delayed responses.
This might be silly, but couldn't we move req/res into their own modules, but then also export those modules from the lib/response.jslib/request.js files, while adding a deprecation message?
If the assumption is people are requiring deep into the lib, that should be enough to prevent breakage of specifically that behavior.
at this point I would like to know the list of existing repo owners and committers for the relevant items above, so that I can individually follow up with them too.
[ edit: moving this conversation to #98 as that is tracking this topic]
thanks!
at this point I would like to know the list of existing repo owners and committers for the relevant items above, so that I can individually follow up with them too.
I have not read everything, but the list I posted above was volunteers as repo captians. We would still want to ratify the proposed governance changes and vote on the proposed people (as per the process).
Also, agree this issue covers too much now. We should probably split it out into a few.
I opened #100 for specifically tracking express 5.0 release, for some reason discussions happen at the TC meeting tracker. I am going to cross-post the heavy-weight comment above, to #100
Activity
jonchurch commentedon Mar 2, 2020
It was requested that folks review the Repo Captains proposal prior to the meeting, as it will be the first topic discussed
ghinks commentedon Mar 3, 2020
I'll be there Jon.
wesleytodd commentedon Mar 3, 2020
@dougwilson Let me know when you want to tackle getting the streaming setup right. We have a few things to do:
@brianwarner, do you who on the foundation side we should share the new Express YT account credential with, is it you?
brianwarner commentedon Mar 3, 2020
@wesleytodd and @dougwilson - In this case, the only credentials to share are for Zoom, so that you can log in as host and kick off live streaming.
For YouTube, we don't share credentials. Instead, you add accounts as manager or owners. Please feel free to share with me (bwarner@linuxfoundation.org) as an Owner, and that way I can escrow the ownership and add people if they need it.
In general, anybody who will kick off a live stream just needs to be a manager.
Make sense?
dougwilson commentedon Mar 3, 2020
@wesleytodd for number 4 (the YouTube channel) I am 100% on board but I just don't know how to do that and need some kind of instructions. The only method I know if needs a phone number. See #94
wesleytodd commentedon Mar 3, 2020
@brianwarner The goal, as you say, is that someone on the foundation also has access to the YT credentials in case of an emergency. And I already have the zoom credentials, we just need @dougwilson to also have them shared with him on whichever email he registers with LastPass on.
For the YT account, is there a foundation phone number we can use on the account? I am happy to offer up my number if we need it, but I agree it would be better to use a shared one instead of one of our personal numbers.
brianwarner commentedon Mar 4, 2020
I ran up against this with other YouTube accounts... I've verified as many as I can before my own timer resets (two per number per year). Are you able to verify it with yours? Otherwise, I'm not sure when I get to start verifying again.
wesleytodd commentedon Mar 5, 2020
@dougwilson Do you have time tonight to work this out? At least before tomorrow morning can we get the new google account created and the account shifted over? Like I said, I am happy to use my personal phone as a stop gap.
dougwilson commentedon Mar 5, 2020
Yep, I definitely do. Let's coordinate on our Lastpass email chain, especially if we need to pass not super public information back and forth :)
LinusU commentedon Mar 5, 2020
I'm getting a "Webinar has expired." error when trying the link 🤔
wesleytodd commentedon Mar 5, 2020
Let me see about starting it. I think Doug might not be able to attend, but we can go at it for now, but it still means that it wont be streamed. Here is the new link: https://zoom.us/j/570940962
ghinks commentedon Mar 5, 2020
the zoom link above has expired
wesleytodd commentedon Mar 5, 2020
I just updated the new link. I think that above one was an accidental copy from last week.
wesleytodd commentedon Mar 5, 2020
routerandgeneratorsessionapi-error-handler(add to statusboard)expressjs.comundefined7 remaining items
gireeshpunathil commentedon Mar 6, 2020
IIRC, re: req/res extraction change being included in 5:
pro: good to go with other breaking changes, or else we will have to wait till 6, which may be an year or more from now
con: more change in 5, more work to do
I guess @wesleytodd said he will be able to develop, test, land and publish in 2 week's time. If so, I am leaning towards that option, but would be good to know if there are other considerations than I quoted above?
dougwilson commentedon Mar 6, 2020
I would like to get breaking changes completed by this weekend so we can publish an RC instead of a beta version. I believe @gireeshpunathil that was something you were championing before? To move on and not start like a beta cycle? If we're not doing with breaking changes I can't actually publish it as an RC, it would be another alpha or a beta.
The other consideration I had also came fro. your feedback of having too many breaking changes piled in to the same release. This one seems more so as the breaking change it not enabling some new use case or feature, right? Seems that it would at this point be a breaking change for the sake of it, which seems weird to try and smoosh into 5 at this point.
There is the settings breaking change that actually seems useful compared to this, yet it seems odd this would be more important than the settings change?
gireeshpunathil commentedon Mar 6, 2020
@dougwilson - thanks.
unfortunately, my experience in this project is insufficient to make an assertion in either way on these points. @wesleytodd - can you please pitch in and ratify with @dougwilson on this?
Yes. I am still holding on to that; we should do what it takes to release RC -> GA, not alpha or beta
Yes. For the wider interest of the ecosystem (to consume majors / migrate with less pain). But from the nature of the change in question, it is not necessarily a
definitebreaking change? only code that assumed internal code layout and depended on that will be affected?In either way, I think this is something that can be sorted out quickly between you and @wesleytodd , unless others have strong opinions!
dougwilson commentedon Mar 6, 2020
Yea, and I have come to agree with you on that, as a way to get this out. The path to regexp giant breaking change is compete and just needs to be released. The sooner we can release for community to test, I think the smoother it will be. But that then means that we can delay the release of that for testing to wait for more of these other changes to land and then make a RC or not wait and release another alpha or a beta...
gireeshpunathil commentedon Mar 6, 2020
Change default setting of query parser, deprecation in 4.x line - PR in place, expressjs/express#4208 . Please review, and do the needful, thanks!
ryhinchey commentedon Mar 6, 2020
Is there a recording of this meeting?
wesleytodd commentedon Mar 6, 2020
I just sent the recording to @dougwilson. The plan is to upload it to YT. I will try to follow up on the rest of the stuff later, but I have some stuff to do today before I am OOO next week, so sorry for the delayed responses.
jonchurch commentedon Mar 6, 2020
This might be silly, but couldn't we move req/res into their own modules, but then also export those modules from the
lib/response.jslib/request.jsfiles, while adding a deprecation message?If the assumption is people are requiring deep into the lib, that should be enough to prevent breakage of specifically that behavior.
gireeshpunathil commentedon Mar 9, 2020
just want to track the progress of items planned for this week:
at this point I would like to know the list of existing repo owners and committers for the relevant items above, so that I can individually follow up with them too.[ edit: moving this conversation to #98 as that is tracking this topic]
thanks!
gireeshpunathil commentedon Mar 9, 2020
repo captain proposal : expressjs/express#4210 , pls review!
dougwilson commentedon Mar 9, 2020
Please, as I specificly asked above in https://github.com/expressjs/discussions//106#issuecomment-595345208 move this conversation to #98 since it has a dedicated issue so we can discuss it without things getting lost. This issue is already a bit unwieldy with the number of different things all being discussed in the same thread.
wesleytodd commentedon Mar 9, 2020
I have not read everything, but the list I posted above was volunteers as repo captians. We would still want to ratify the proposed governance changes and vote on the proposed people (as per the process).
Also, agree this issue covers too much now. We should probably split it out into a few.
gireeshpunathil commentedon Mar 9, 2020
I opened #100 for specifically tracking express 5.0 release, for some reason discussions happen at the TC meeting tracker. I am going to cross-post the heavy-weight comment above, to #100
gireeshpunathil commentedon Mar 9, 2020
closing this as:
please re-open if I am wrong here!