CHAOSS Evolution Working Group, 7 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: CHAOSS.Evolution.October.7.2020

Description

CHAOSS.Evolution.October.7.2020

A

Okay, so we're now recording the evolution meeting for today. Here's a link out to our minutes- and today is september. No it's october, 7th, is what it.

A

A

Just somebody else could go above me, but I wanted to get. The list started. Put your own name in there. um Last time um we looked at a lot of the different open, pr's and created some dependency metrics.

A

So this time we have, I think, the good news that.

A

We can, we can rename.

A

Reviews to change requests, as approved at the community level,.

A

And we'll go through the 30-day community review period as well as well. I think I don't think anybody can object to the changing of the name, since we brought it up at two community meetings, but they may have other feedback for us. So um I think we need action items to actually go through and address those.

A

A

A

Open issue for review period matt: do we create a an issue for every metric that changes during the interim review period? uh I can't remember yeah. I can't remember if it was one issue for the whole thing or in the interim period it may be an issue. I think it is an issue per metric. It'll be an issue for each one. Okay,.

A

I won't assign or ask for volunteers on that, since armstrong is the only uh participant at this moment in time, so just be putting you on the spot. I don't wanna do that. um Let's take a look at.

A

Ben armstrong: are you.

B

Are you looking for participants to take on that job.

A

um Well, I mean I would ordinarily, but there's there's really. You know me and armstrong. I don't want to. I don't we'll, do it really, okay, it needs to be done so hold it. Right now appreciate.

A

That read the issues too sure.

A

Thank you. Thank you. Thank you. uh There's some.

A

A

So I didn't address the open pr's that are possibly minor things that we could address. um Let's just take a look at the issues at metrics about branch lifecycle.

A

So let me actually let me share my screen, so I went from our meeting minutes to this pull request that we discussed last time about branch cycle, and I wanted to make sure we had a good understanding of what the metric was, because it was. uh This is an issue opened by king and uh his. uh He agreed with the examples that these are the kind of metrics.

A

He's looking for so how many branches merged, but not deleted, how long branches have been merged and not deleted. Many branches have been opened more than x days. um So I think this is clear enough that we can at least name a metric for development regarding branch life cycle.

A

What do you think armstrong matt elizabeth.

C

Yeah yeah, I agree. I don't have any yeah any concern against that.

D

It's it seems like there are filters, though, maybe on current metrics. We have already that's a good point.

A

um What are these hearing tests from so branches branches exist in a repository.

A

And so the question is, I look at evolution.

A

A

Make this wider.

D

Like by by branches this it's a code.

A

Does that mean like change.

D

Yeah, would it be like the same as a change request then or.

A

It's it's more, it's more static than that, because sometimes branches it exists. I mean you probably know this in perpetuity. There's projects that use feature branches and projects that use developer branches, and so in the example that king provides, um which I I don't know I lost it.

A

I lost track of. um Let me try to open it again, how many branches are merged, but not deleted, so that really implies if it's merged and not deleted. That implies you're, probably using developer branches. In my opinion, and so if we use the goal question metric really, the the question is: how is a project using branching and what is the life cycle and another question might be: what are what are the life cycles of branches on a project?

A

So if a branch has been merged and not deleted that that's likely an indicative developer branch, wait a minute how long how many okay yeah these are both indications of developer type branches. How many branches have been open that that feels?

A

That question feels more like it's really about pull requests, um but if a branch is uh you would so, if you're, using featured branches, you're gonna see a lot of branches coming and going and if you're, using developer branches, you're gonna see a lot of branches, just continuing to exist over time and there's also branch counting which can give you some kind of indication of activity.

A

So I guess the question is: can we filter the code changes by.

A

Branch, we have an included branch.

C

Can we see that code changes by branch? uh If, if that happens, then it should surely be a future branch for a change that it's taking a longer iteration along the development line.

A

Yeah yeah, I mean that's the like pulling branch, data and analyzing. It is so I'm thinking. Unfortunately, I'm thinking in my tool, brain and my tool brain knows that it's quite different than than what the analysis that grimoire, lab and auger are doing right now is because we're not navigating to the different branches or listing them, but just listing branches would probably be easily accomplished, but we wouldn't be. I don't know that we would want to commit ourselves to building a metric that does deep code change analysis on branches.

A

um That would be a different kind of thing.

C

We are looking like this cyclosomatic complexity,.

C

That would be too complex for code changes. Yeah, it is doable. There are tools that really exist that are doing things like that. Yeah, like the sauna, keeps on up and things like that, but I think we should focus more on the lower level of granularity and try to see how we capture those changes.

A

So so we did put this branch life cycle under considering and named the issue in last weeks or two weeks ago. So um I think we could, based on king's response.

A

I I don't, I don't see a place where it exists as a filter on a current metric. um Do you armstrong.

C

uh Let me tell you I don't remember, I don't recall that right now.

A

um Yeah yeah, I don't know if you can see my screen sharing or if you're yes like. Yes, I can see it.

A

Just make it a little.

A

D

Hey sean, I have a dumb question.

D

Oh, that sounds like a challenge, but anyway, um if something is not available through the github api, for instance, is there a way that you can still get that information.

A

D

Or something yeah.

A

For branch lifecycle, it is all in the get log. um Okay, I I think the the thing that that um armstrong- and I are talking about- is it we know from navigating get logs that sort of analysis of each branch that exists at a point in time would be.

A

I don't know it would be perhaps not exponentially, but in some cases exponentially more computing work than just looking at the master branch, but counting branches like looking at the enumerated branches at a moment in time and storing that and looking and observing their evolution of just how many branches exist. And what are they called over time?

A

And even I mean I think that simple kind of a metric is easily obtained the, um and we can do that from the git log or from the github api.

D

A

That makes sense to answer your question. Yeah.

D

A

uh I'm burdened by understanding that technically what we would have to do- and I guess I'm I'm trying to understand the question king's asking and I I do think he's really asking more for information about like branches appearing and disappearing and how long they exist and I think he's asking about the inclusion and pull requests.

A

When I look at it. When I look at this last one.

A

D

Yeah, because if you um can easily compare branches from day one to day two and you could easily say, oh, this branch is no longer listed, but would would it then tell you had it been deleted or merged or any of that stuff like that's what you would have to go and dig deeper for correct.

A

Yeah, right and and the way that tooling works, I don't think any of the apis. Give us like branch disappearance dates, although they might, I I can look. We can definitely list the branches at a moment in time and we can do that directly against the git repository it's whether or not github and gitlab maintain um like a branch history in the api there's been.

A

There are some things that are are not available unless there's something they're not available or something they're not available unless you're a maintainer on a repository so like clone count, is a good example of a statistic: that's not available unless you're a maintainer on.

E

A

um So I would just have to technically look at the api to see what we can get, but I just I just I know we can list the branches that currently exist.

D

Yeah I'm looking at it right now. I don't see anything about uh branch deletion, um yeah.

A

So um and I don't I don't, I think the risk of making I mean, I guess I'm interested in your thoughts. So if we make it a filter on code changes, we potentially.

A

Would potentially commit ourselves to that exponentially, more complex analysis, and if we try to constrain the filter, then I think we're doing some kind of mental gymnastics. We've never done with filters before you know where it's like we're just actually going to do this other thing, but stop um at a place that we aren't stopping when we do the main master branch, and so I worry about creating a confusing a confused. I worry about creating confusion if we use it as a filter. I don't know if I'm stronger, damn yeah, I'm filling up that.

C

Well, I just want. I just want to be uh to find out something like the script. You have a script that actually does something like that right that you are trying to apply it to this context. Well, we.

A

Could we could get the branch list from I think we can get the? I know we can get the branch list from the git log at a point in time.

C

A

C

If we, if we could use if we could use the git, lock method, I think we could. uh We could easily get the branches and possibly get the history of it, because.

E

C

Even if, even if it is at some time a scratch, we can see at what point you know everything was squadged.

C

So to my to me, the best bet would be to go with a good luck approach.

C

D

Hey, I have a side question: uh what happens when someone does not have their main branch listed as master? Do you have a way to control that or.

E

D

C

A

C

Okay, go ahead.

C

Now I just want to clarify that the main branch of the project is not master.

A

I've in my teaching, when I teach software engineering, I I create a branch called production, because I don't like the implications historically of the master branch, and I think that's why people are getting away from it and I get help. I've read an article. Am I right about this elizabeth that you know of that that they are actually going to change the default name of the.

D

Branch, I know that that's on their their plan. I know it's also not an easy thing to change um right for github overall, but I know that people are. I have seen people just individually, making that change and github does. Let you do that pretty easily, if you're, obviously the owner of the repo, you can change it pretty easily, but um yeah. So I think that they're pushing for for overall the the default to be like main or something like that. Yeah.

A

Yeah- and I mean the way that auger works is if, when we do a get pull, it's just going to keep it in the main in the I have to have to check this, but I think I think the we probably have to note that the new branch master, the new branch, the main branch- is no longer named master and do a get check out of the new name um by default. When we do the initial git clone, it just tells us what the main branch is, and I don't know if we get pull.

A

I just have to look at the get syntax to make sure. I know how that's addressed.

A

I want to say it just works, but I'm not. I haven't actually tested it.

D

What does that? What did git lab do? Do they do they use master? Do you all know, I'm just curious. I know we're getting off. I'm sorry.

A

C

I I don't know, I think the default I think the default is master, but you then you you change depending on. If you are doing, let's say kind of developmental experiment or something like production, yeah.

A

The default is master uh yeah. I created a gitlab account. I have one project it's empty on. It called auger, but.

A

So yeah the main branch on git lab is also tur. Right now,.

C

Called because I know a lot of projects are trying to keep the master branch clean so that, at any point in time, people can get a clean copy from the master. Some people are doing that. Then they try to make let's say like if they are doing a kind of depending kind of releases they are doing you know, then they try to make this kind of uh production branch or a developmental branch where they test a lot of things and once the code is stable, they try to push it somewhere.

C

That you know people visiting can just pick it up from there. So it all depends on the philosophy of the project and how they want to address things. I remember like a project like openstack. They tried to keep this future branch going in every release they after they release. They just made it to the master and they thought they just continue with a new uh development cycle.

C

So as soon as this week they released today, they like, following the same today. They create development cycle for the next release.

A

Okay, I created a document for branch life cycle. I think the question.

A

I think we should probably create an issue for elizabeth's question about how how to tools um handle the change in the name of the main branch.

A

And probably I think that's under. I think that would be a question for evolution to answer, because I think it's more of a tooling question than.

C

F

What was this, this question? Sorry, I just joined um so github.

A

Is uh ultimately going to change the name of the main branch or the default name, the main branch from master to something else? And.

B

uh I think it already does that. Last time I cloned a repo, it tried to set up my default branches main instead of master interesting.

C

B

Just in the past couple days, even like.

F

B

When I, when I copy the commands like when you, when you click the little plus button, create a new repo, the command you copy use main instead of master.

B

E

B

E

My photo right now, so I can verify it.

A

That they are planning to do that so they're, probably not they're, probably not going to force existing repos just to rename their their master branch, because yeah break a lot of things.

B

If they did that there would be an uprising in the community, I think the likes of which they would not have ever seen or want to deal with.

A

Well, yeah, I know just I think projects can do it uh themselves and then yeah. The question is that makes.

B

A

This tooling needs to handle it.

A

um Like auger, I know handles like if the me, if the, if the main branch is called main, when we clone it we're fine. What I don't know is if they change. If the name of the of the main branch is, if that's handled, I got a bad feeling that, because we're doing get clone and get pull from the region.

B

Yeah, I'm almost certain that it's.

B

D

I did not mean to derail that sorry, that's.

A

A it's actually a very um it's a very important question, though, because uh it's essentially, I think, all of the both grammar, lab and auger are in a good situation um for nude clones. um It's when it changes that we have to check that we've identified that the new main branch is called.

B

Sean, I would change the language to say default branch. I think that's what most people know it as, and it also reduces the confusion of having a main branch. That's named main versus mass.

A

Right default, you could have a good point, so the full parameter is not mean so master current tooling won't handle whatever.

B

My current tooling, do you just refer to most logger.

A

I think daughter and grammar lab.

B

Okay, I thought this just wasn't more. Generic, like most tools, would not support. The renaming verb will not understand moving a uh default branch right, which I think is probably a fair assumption, anyways, that most tools don't usually like to handle changing default branches because they usually don't change.

C

But I think they will start doing right now, because if again yes making such a move, then they'll just have to make that option. Yeah yeah, I hope.

B

So that would be. That would be the the great outcome because everybody changes but we'll see.

D

Well- and I guess that is sort of related to what we were talking about before, because you were saying that you wanted to try to dig deep on the whole history of the branch, so that would unearth where, if, if the main or default branch, the sorry, the main branch got changed at some point right. So that would be maybe a there's a way to flag that when you're kind of searching through the history of a branch, maybe.

D

C

The default range, I think they if they have to change a name. Let's say they have been using the master branch they want to switch. Do you want to change to mean it'd mostly be like refactoring? They cannot just delete all the history and all the commits that have been going in the master to create a complete new mean.

C

It will just be a kind of pointer.

A

Basically, the way that we it would I mean I could just do a quick demo. What would happen is um I can create a branch called main and create branch main from master. This is likely what people would do and then, if I go to settings on github and I'm sure, there's a place on git lab as well, um there is this.

B

Go up it's on the branches section! It's on the left! Oh right, you got it. It's the the top. Deciding is your default so right.

A

So default branch, so it's changing this default branch to main, which I am not going to do right now,.

F

Yeah, it probably doesn't yeah just detroit.

A

Yeah, um so this is the x. This is the action that um would be probably it would mo for most tooling, it's going to be problematic. Initially, um I imagine, as time goes goes on, there will be ways that get gets updated to actually deal with. This um it'll probably be a get command to address the default.

A

Actually, maybe there already is.

B

uh I don't think git has any oh, like yeah, when you clone a repository, what it sets the first branch as yeah or like everyone, you make a new one, I'm not sure. Well, the thing is is that you can yeah. I don't know how I don't know how useful this is in terms of the concepts of an evolution metric, but there's not necessarily any correlation between the branches.

B

The local branches on the people use on git versus, what's on github, like branches on github, could be completely different from how they do development locally, uh which is something to consider, because you can. You can push from any branch to any branch so long as the history matches on github like I could push to a branch, I could push from a branch. That's called main on my computer to some 64 long, random, hash string on github, and it doesn't matter, um and the other thing is that you can rename branches in place.

B

So some people might not even make that new branch, like you did sean they might just rename master in place to me.

A

That's what I was saying.

B

A

Know exactly I didn't realize you could do that.

B

Yeah, so on the command line you just have to use, I don't think you can do it on github, but if you on the command line, if you do dash m like if I'm on master- and I.

E

B

Branch m uh get branch dash.

E

B

It will just change the name of master to main.

A

Oh, that way that I know auger would handle it yeah. um I should update the issue I just created, then.

B

uh But most people probably won't do that and it's still a little bit different because on github it doesn't replace the branch on github. It just makes a new one. That's got all of the same history as master and it, but then moving you know. Changing the branches in other ways is probably not still not supported, so I would say that we we should update the you, can move branches, but I don't know for certain that means auger handles it. To be honest,.

A

um If the default branches change like, if so it's a git dash m main, would change the name of the main branch.

B

Get branch dash capital in right, we'll change the name of whatever branch you're on to the argument that you passed this command. So in this case main.

B

And it's only a get command.

D

So how would you come like? How would you know that that happened? This is again a dumb question, but like so, if you're, if you're, comparing stats from last year to stats from this year- and you made the change on january 1st like how, how would you be able to continue.

A

D

Apples to apples is that.

B

Is that that's what we're trying.

D

To figure out right now.

B

Yeah, I'm actually not even sure if you could do it just by looking at that branch itself like you might have to kind of hope that I you know, I don't really know. I don't know if there would be a way to look at a branch from just within that branch and tell when the name got changed.

B

Maybe that's a maybe that's a question for hacking.

C

Against internals, if you know, if you do good luck, if you do get locked you could you would.

A

Change will tell.

C

A

I didn't get like branch and mostly what I'm seeing are branch merges. I'm not seeing I get a lot of our branch deletions actually.

B

Well, the are you looking at a local git log yeah, I am get get log, doesn't it the getlog doesn't show branch deletions and the branches that you have on your deleting a branch on github does nothing to it on your local machine.

B

There's no there's again again, there's no correlation, not necessarily there almost always is, but there's not a hard a hard one. You know what I mean.

A

There's a way to list the branches that currently exist and.

B

Get branch: it's just get branch; uh no, no.

E

B

And that lists all of the branches yeah.

A

B

Should just list your branches locally? Oh wait! No, you wanted all branches, never mind.

A

Yeah yeah sorry get branch dash a will list, all the branches so.

A

I'm just gonna note under.

A

A

Make that note in the branch lifecycle document that I just created.

A

All right, so this has been an important discussion, because I think we know a way that if people do this, if you do the name changes at the get level, I think current tooling is likely to work so how people make these kinds of changes is probably important and we're worth socializing in the community.

A

um So in agenda notes, I just.

A

A

So, let's let me create this issue.

C

Did that answer.

A

C

B

D

A

Thank you. Yeah now answer your question: oh okay, good somebody did that.

B

Yeah, because those are from last week.

A

Well, yeah, but I wanted to so I got rid of the I wanted to still like 368 was the we discussed it and actually decided to make it.

B

Oh wait. Sorry, those were the merged ones, not the discussed ones. I'm an idiot. Sorry.

A

No, it's okay! I just can't it's the and then 360.. I would just take a look at 360 and then.

F

Oh yeah, yeah yeah. I remember visualizing issues in prs.

A

A

I guess I have to open this powerpoint.

A

A

So let me change my share here, really quick.

A

This is the powerpoint that this issue refers to and the issues asking us to include this figure in the work evolution does as a way of visualizing the pull request process, and I think this this life cycle makes so new issues. How many open issues by new contributors.

A

People opening issues average time percentile distribution, so I think.

A

I think we have atomic metrics that cover all of these.

A

A

Because the new contributor is metric include, is there's an issue sub class of that either in common or in our working group.

A

Opening issue, you know, issue opening time average time open issues and percentile distribution cell distribution may not be a current filter, but it's certainly something that we could.

B

Is people like is people opening issues? The count is it just? Is people another word for contributors? I don't know what that means. I don't I'm unclear on the the semantics of probably do have it, but I'm just not familiar with using that language in a metric in this term.

B

B

Because everything else.

B

um Same thing, over with issues submitted.

A

Enclosed I apologize for the the scale of this. um It's pretty tiny if I can make the sidebar smaller, yeah, um sorry, savage and carter.

B

Issues submitted slash closed over there on the right is the same thing I just on the right to the right down a little bit. It's the fourth, it's a fifth one. It's the fifth box. uh Okay, yeah! I mean that's, that's one of those, I'm not sure what which I think that refers to like opened and closed. I would assume I just submitted. I don't know if there's a different yeah.

E

B

Means something different in different contexts, maybe in different bug, trackers or something.

A

Yeah here's my insert comment.

A

I created that question and I think so there's a few and reopened issues. We have.

A

um I don't know if we've defined reopened issues as a metric. I know auger has a set of reports that it can generate that look at issue reopened. Data.

A

Reopened issues I mean essentially uh I'm gonna change my share again and just look at our existing metrics to see if we handle reopened, because I don't.

B

Like the regular, the regular.

A

B

I'm fairly fairly confident that we don't. I can tell you that right now,.

A

In the in the current existing metrics yeah all right, we know.

F

A

So there would be one of the other results of.

A

A

A

A

And I don't know if um we would.

A

Add add that here or if that should be its own metric, I'm uncertain candidly. But let's leave it here for now which one um it's for the issue. We open uh need to add history open as a filter on the current issue, metrics that that seems like it would be a filter right or would it be a.

B

um Not certain I got instinct is that it probably wouldn't I don't know it feels like issue reopening is a significant event that might warrant like opening the issue from the first for the first time is very different than reopening it. When it's been closed already, like the reasons that you that you would close, that you would open it again are probably different like it didn't it actually didn't fix it or you found something else or it suddenly became relevant again, which all of which, I think, suggests something else that might be interesting there. Just.

A

A head, so it's.

B

Just another action that you could take, I just haven't thought about it: yeah, yeah, okay, so I'm just gonna have an off-the-cuff.

C

Brainstorm so atlantis, I miss the point that you are making here that you open it for the first time is different from reopening it multiple times. uh I.

B

Think usually, the reasons that you would re-open it are different than the reason that you would open it in the first place. But that's not. I don't know if that's exactly what I wanted to say, but I think reopening it is significant because it's not you, I don't usually reopen stuff, and so there might be something interesting happening. If I have to reopen a bunch of metric a bunch of issues or if I you know, one issue gets closed and reopened four times.

B

It's probably really contentious, maybe- and you know something's going on there um yeah. I don't.

E

B

Just it's something interesting that I don't know if those would normally be reasons that you would open the issue to begin with, like when you open it versus when you reopen it. The context of what you're trying to do with it is different.

A

Yeah and and the fact that we don't account for reopened issues means that, when we're counting it, you know length of time that an issue is open. The default will be that if an issue is closed like four different times and reopen four different times, the actual calculation will be from the final close time on to the original open date. um For for augur, I've done some there's some queries that I've used for our users that show the reopen.

A

You know time from original opening to original closing and then time from original opening to final closing, um to distinguish issues that are that have been reopened right because it can be, it can really skew the data, like issues are sometimes reopened like a year later. Thank you, um and so we create these bizarre outliers.

A

So that's that's.

C

One thing: one thing we just that came over my mind right now and each time we open an issue. We should just keep track if it touches a fire, because any time we touch a fire it becomes substituted to workers becomes what it becomes more vulnerable.

C

Like this book inducing commits uh yeah, it can introduce a berk, that's a study. That is it's like an empirical findings. Is that.

A

But is that related to issues armstrong.

C

Well, I'm just saying it's something that we should think if we do not think of it as at some point, because each time we open and each time we touch a fire yeah, they propose the the percentage of that fire becoming bug, increases.

A

So it's the association of the issue with an open door or a series of pull requests. I think, is the point that you're making yeah.

C

So if we, if we become familiar with these ssh algorithms and anything that deals with this but inducing commits those are well explained in those kind of works.

A

A

We're about at time here so um I'm gonna, just upload since I made the comments on the powerpoint and you can't access.

A

That I'll just put it right.

A

A

And now king didn't open this so I'll just make this comment sounds good all right and um I think I think that's a wrap for the for the.

A

Meeting looking for the evolution notes, so so what we said about 360 is.

A

A

B

Did you mean to paste that link afterwards.

A

Yeah, I think this 371 is actually I think that was a google doc.

A

Two people touching the same thing. At the same time,.

B

A

That wouldn't be stressed, wouldn't be the first time.

A

A

That's the issue: it's about issue flow dynamics discussed in the vp working group, and I think it's a really good. um I think discussing these these issue flow questions is pretty important, so I'm glad that we did it and um now that's a wrap that I've edited the documents. I will stop recording and.