random idea: declaring CL bankruptcy

[Mike Frysinger]

as part of the master->main git migration, i've come across some repos that have a lot of stale CLs.  how would people feel about a tool that automatically abandoned CLs that have had no activity for more than some time frame ?  we could start with 5 years as a "no one will disagree with that" policy and see how devs react.

if the CL owner wanted to keep the CL, they can always hit the Restore button.

we do this with bugs already as sheriffbot automatically closes stale bugs after a year or two of no activity.

some random open CL stats to fuel discussion.  these are cumulative: <2013 == 72 CLs from 2011 & 200 CLs from 2012.  these numbers are also after i manually abandoned 100s of really old ones from some CrOS repos.

<2012 72
<2013 272
<2014 448
<2015 956
<2016 1694

<2017 3022

<2018 10k+

so if we nerfed all CLs older than 5 years, it'd affect ~1.7k right now.

-mike

[Bruce Dawson]

What would be the advantage of abandoning old CLs? I can understand not supporting them (whatever that means) but what is the cost to leaving them around?

I tend to have some "DO NOT SUBMIT" CLs that I keep around for reference purposes. All I want to be able to do is look at the diffs. If I can't rebase them that would be fine.

That said, 5+-year-old CLs are unlikely to have any residual value.

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAAbOScmEmNko6Dc6dX28z7KXixnZC734PtDcBGZgUzgQYtKm9g%40mail.gmail.com.

--

Bruce Dawson

[Mike Frysinger]

On Mon, Dec 21, 2020 at 2:41 PM Bruce Dawson <bruce...@google.com> wrote:

What would be the advantage of abandoning old CLs? I can understand not supporting them (whatever that means) but what is the cost to leaving them around?

it speeds up Gerrit searches when looking at open CLs, unclutters user's dashboards, and is less work when having to do things like migrate branches

I tend to have some "DO NOT SUBMIT" CLs that I keep around for reference purposes. All I want to be able to do is look at the diffs. If I can't rebase them that would be fine.

abandoning is not deleting them.  you can still star/view them at any time.  they're just no longer in the "open" state.

-mike

[Bruce Dawson]

Okay, good to know what the advantages are.

While abandoning isn't technically deleting them, it essentially is for my use-case because it means that I can't easily find them anymore. I'd need to find some way to tag the interesting-abandoned CLs to distinguish them from the boring-abandoned CLs (or bookmark them or some-such). Not unsolvable, certainly, but it would break my "system"

--

Bruce Dawson

[Mike Frysinger]

you can control the set of saved searches under the YOUR dropdown to have it pick up whatever you want.  like:

https://chromium-review.googlesource.com/q/is:starred

-mike

[anatoly techtonik]

On Fri, Dec 18, 2020 at 12:02 PM Mike Frysinger <vap...@chromium.org> wrote:
>
> as part of the master->main git migration

But.. why?

If people spent time discussing them, and there was no consensus, then
probably there is a chance that the story will repeat itself. The
better strategy could be to estimate the cost of the bankruptcy in
human hours needed to review and reticket those CLs.

[Mike Frysinger]

On Fri, Dec 25, 2020 at 11:48 AM anatoly techtonik <tech...@gmail.com> wrote:
> On Fri, Dec 18, 2020 at 12:02 PM Mike Frysinger <vap...@chromium.org> wrote:
> > as part of the master->main git migration
>
> But.. why?

you can read about it here:
https://groups.google.com/a/chromium.org/g/chromium-dev/c/mQ1u-I5U500/m/rG6G3rDWAAAJ

but that's not the point of this thread.

> >, i've come across some repos that have a lot of stale CLs. how would people feel about a tool that automatically abandoned CLs that have had no activity for more than some time frame ? we could start with 5 years as a "no one will disagree with that" policy and see how devs react.
> >
> > if the CL owner wanted to keep the CL, they can always hit the Restore button.
> >
> > we do this with bugs already as sheriffbot automatically closes stale bugs after a year or two of no activity.
> >
> > some random open CL stats to fuel discussion. these are cumulative: <2013 == 72 CLs from 2011 & 200 CLs from 2012. these numbers are also after i manually abandoned 100s of really old ones from some CrOS repos.
> > <2012 72
> > <2013 272
> > <2014 448
> > <2015 956
> > <2016 1694
> > <2017 3022
> > <2018 10k+
> >
> > so if we nerfed all CLs older than 5 years, it'd affect ~1.7k right now.
>
> If people spent time discussing them, and there was no consensus, then
> probably there is a chance that the story will repeat itself. The
> better strategy could be to estimate the cost of the bankruptcy in
> human hours needed to review and reticket those CLs.

based on the 100s i've already abandoned, >99% go quietly without
comment. so this doesn't seem like a problem, and your "hours"
estimate vastly overestimated.
-mike

[anatoly techtonik]

On Fri, Dec 25, 2020 at 10:26 PM Mike Frysinger <vap...@chromium.org> wrote:
> On Fri, Dec 25, 2020 at 11:48 AM anatoly techtonik <tech...@gmail.com> wrote:
> > On Fri, Dec 18, 2020 at 12:02 PM Mike Frysinger <vap...@chromium.org> wrote:
> > > as part of the master->main git migration
> >
> > But.. why?
>
> you can read about it here:
> https://groups.google.com/a/chromium.org/g/chromium-dev/c/mQ1u-I5U500/m/rG6G3rDWAAAJ
>
> but that's not the point of this thread.

Inclusive Chromium code? I don't get it.

> > >, i've come across some repos that have a lot of stale CLs. how would people feel about a tool that automatically abandoned CLs that have had no activity for more than some time frame ? we could start with 5 years as a "no one will disagree with that" policy and see how devs react.
> > >
> > > if the CL owner wanted to keep the CL, they can always hit the Restore button.
> > >
> > > we do this with bugs already as sheriffbot automatically closes stale bugs after a year or two of no activity.
> > >
> > > some random open CL stats to fuel discussion. these are cumulative: <2013 == 72 CLs from 2011 & 200 CLs from 2012. these numbers are also after i manually abandoned 100s of really old ones from some CrOS repos.
> > > <2012 72
> > > <2013 272
> > > <2014 448
> > > <2015 956
> > > <2016 1694
> > > <2017 3022
> > > <2018 10k+
> > >
> > > so if we nerfed all CLs older than 5 years, it'd affect ~1.7k right now.
> >
> > If people spent time discussing them, and there was no consensus, then
> > probably there is a chance that the story will repeat itself. The
> > better strategy could be to estimate the cost of the bankruptcy in
> > human hours needed to review and reticket those CLs.
>
> based on the 100s i've already abandoned, >99% go quietly without
> comment. so this doesn't seem like a problem, and your "hours"
> estimate vastly overestimated.
> -mike

But I didn't do any estimation, so how do you know that I
overestimated? Usually for me the process to commit to an unknown
repository takes 3 days. It is not 72 hours straight and even 24, but
12 can come easily. The total cost of bankruptcy could include those
in addition to hours that maintainers are needed to spend to review
them for merging. If people "go quietly" about their changes, then
they might as well quit quietly, because the motivation to repeat the
process for me personally would be extremely low.

--
anatoly t.

[Mike Frysinger]

On Fri, Dec 25, 2020 at 5:36 PM anatoly techtonik <tech...@gmail.com> wrote:
> On Fri, Dec 25, 2020 at 10:26 PM Mike Frysinger <vap...@chromium.org> wrote:
> > On Fri, Dec 25, 2020 at 11:48 AM anatoly techtonik <tech...@gmail.com> wrote:
> > > On Fri, Dec 18, 2020 at 12:02 PM Mike Frysinger <vap...@chromium.org> wrote:
> > > > as part of the master->main git migration
> > >
> > > But.. why?
> >
> > you can read about it here:
> > https://groups.google.com/a/chromium.org/g/chromium-dev/c/mQ1u-I5U500/m/rG6G3rDWAAAJ
> >
> > but that's not the point of this thread.
>
> Inclusive Chromium code? I don't get it.

if you have questions, please see that thread and contact the group
mentioned there (chops-so...@google.com). for the purposes of
this discussion, the matter is closed.

> > > >, i've come across some repos that have a lot of stale CLs. how would people feel about a tool that automatically abandoned CLs that have had no activity for more than some time frame ? we could start with 5 years as a "no one will disagree with that" policy and see how devs react.
> > > >
> > > > if the CL owner wanted to keep the CL, they can always hit the Restore button.
> > > >
> > > > we do this with bugs already as sheriffbot automatically closes stale bugs after a year or two of no activity.
> > > >
> > > > some random open CL stats to fuel discussion. these are cumulative: <2013 == 72 CLs from 2011 & 200 CLs from 2012. these numbers are also after i manually abandoned 100s of really old ones from some CrOS repos.
> > > > <2012 72
> > > > <2013 272
> > > > <2014 448
> > > > <2015 956
> > > > <2016 1694
> > > > <2017 3022
> > > > <2018 10k+
> > > >
> > > > so if we nerfed all CLs older than 5 years, it'd affect ~1.7k right now.
> > >
> > > If people spent time discussing them, and there was no consensus, then
> > > probably there is a chance that the story will repeat itself. The
> > > better strategy could be to estimate the cost of the bankruptcy in
> > > human hours needed to review and reticket those CLs.
> >
> > based on the 100s i've already abandoned, >99% go quietly without
> > comment. so this doesn't seem like a problem, and your "hours"
> > estimate vastly overestimated.
>

> But I didn't do any estimation, so how do you know that I
> overestimated?

you said "hours" which i took to mean each CL would cost at least 1
hour and i think that is a vast overestimate. if you meant it more
generically as "estimating some amount of time", then sorry i put
words in your mouth.

either way, imo, it appears to be "negligible".

> Usually for me the process to commit to an unknown
> repository takes 3 days. It is not 72 hours straight and even 24, but
> 12 can come easily. The total cost of bankruptcy could include those
> in addition to hours that maintainers are needed to spend to review
> them for merging. If people "go quietly" about their changes, then
> they might as well quit quietly, because the motivation to repeat the
> process for me personally would be extremely low.

we're talking about changes that haven't been touched in years. as in
no one has commented on or rebased or done anything with it. the
likelihood of them still being relevant, let alone directly mergeable
w/out conflicts, is extremely low. if you haven't touched the project
in years, then you've already "quit quietly".

this isn't about pushing people out. if a change is actively being
worked on (where "active" is defined as "within some number of
*years*"), then it isn't applicable to this discussion.

i'll point out again that we already have this policy in place for bug
reports on a shorter time scale as i linked to originally:
https://www.chromium.org/issue-tracking/autotriage
-mike

[anatoly techtonik]

On Sat, Dec 26, 2020 at 4:48 AM Mike Frysinger <vap...@chromium.org> wrote:
> On Fri, Dec 25, 2020 at 5:36 PM anatoly techtonik <tech...@gmail.com> wrote:
> > On Fri, Dec 25, 2020 at 10:26 PM Mike Frysinger <vap...@chromium.org> wrote:
> > > On Fri, Dec 25, 2020 at 11:48 AM anatoly techtonik <tech...@gmail.com> wrote:
> > > > On Fri, Dec 18, 2020 at 12:02 PM Mike Frysinger <vap...@chromium.org> wrote:
> > > > > as part of the master->main git migration
> > > >
> > > > But.. why?
> > >
> > > you can read about it here:
> > > https://groups.google.com/a/chromium.org/g/chromium-dev/c/mQ1u-I5U500/m/rG6G3rDWAAAJ
> > >
> > > but that's not the point of this thread.
> >
> > Inclusive Chromium code? I don't get it.
>
> if you have questions, please see that thread and contact the group
> mentioned there (chops-so...@google.com). for the purposes of
> this discussion, the matter is closed.

It is the first time I see such harsh censorship in a public mailing
list. From the absence of public consensus this looks like an SJW
attack on Chromium. Whatever. There is nothing you can do against
these attacks.

No one commented means maintainers are out of their time budget
already, and that is the project bankruptcy to me. If people don't
have time to review and merge outside contributions, then the project
from open source becomes "open core".

> this isn't about pushing people out. if a change is actively being
> worked on (where "active" is defined as "within some number of
> *years*"), then it isn't applicable to this discussion.
>
> i'll point out again that we already have this policy in place for bug
> reports on a shorter time scale as i linked to originally:
> https://www.chromium.org/issue-tracking/autotriage
> -mike

--
anatoly t.

[Mike Frysinger]

On Sat, Dec 26, 2020 at 3:35 AM anatoly techtonik <tech...@gmail.com> wrote:
> <snip>

> It is the first time I see such harsh censorship in a public mailing
> list. From the absence of public consensus this looks like an SJW
> attack on Chromium. Whatever. There is nothing you can do against
> these attacks.

you're welcome to your opinion, but as i said, the matter is offtopic
here. please use the forums i pointed out already and stop derailing
this thread.

maintainers not having time to respond is only one possibility, it is
not the only one.
if contributors are having a hard time getting a review, and their
attempts to ping the change haven't helped, they should escalate via
other channels (mailing lists/other contacts/community
liaisons/etc...).

what you describe is a problem when/if it happens, but my proposal is
orthogonal to it. if no one has commented on it in years, then
abandoning it isn't going to make a difference to it.

-mike

[anatoly techtonik]

On Sat, Dec 26, 2020 at 12:22 PM Mike Frysinger <vap...@chromium.org> wrote:
> On Sat, Dec 26, 2020 at 3:35 AM anatoly techtonik <tech...@gmail.com> wrote:
> > <snip>
> > It is the first time I see such harsh censorship in a public mailing
> > list. From the absence of public consensus this looks like an SJW
> > attack on Chromium. Whatever. There is nothing you can do against
> > these attacks.
>
> you're welcome to your opinion, but as i said, the matter is offtopic
> here. please use the forums i pointed out already and stop derailing
> this thread.

I am against censorship on the internet, so if you don't want to state
the reason for renaming `master`, I can dig it up and post here.
Nobody will die if you can just post the answer instead of sending
people three links deep just to find out that they need to write to
email that is unreachable, because you need to have a Google account
to reveal the dots. Just how it looks to me. Feel free not to reply to
this if you don't want. As a open source developer who also wants some
social justice for the non-paid time he/she/it spent, I just feel
offended.

My point is not about deciding for people what they should do, it only is
about getting metrics for analysis.

> what you describe is a problem when/if it happens, but my proposal is
> orthogonal to it. if no one has commented on it in years, then
> abandoning it isn't going to make a difference to it.

But isn't it the role of maintainers to give a first comment? If a person who
submitted a CL didn't get any replies, it doesn't mean the contribution is
wrong or invalid. It may have to be rebased, because there was no review
in time. And this is the metrics that should be important for companies
sponsoring Chrome development (and the toolchain on top it including
Electron etc.). This may help to increase financing to bring more people on
board. I would personally help with porting build to Python 3, because with
my current earnings of about $300 a month it feels both miserable and
unfair to see that.
--
anatoly t.

[Mike Frysinger]

On Sat, Dec 26, 2020 at 6:45 AM anatoly techtonik <tech...@gmail.com> wrote:
> <snip>

> I am against censorship on the internet, so if you don't want to state
> the reason for renaming `master`, I can dig it up and post here.

i'm not going to copy & paste the clear documentation that i already
linked you to that explains everything in detail.
stop trying to derail the thread on unrelated issues.

what metrics are you looking for ? whether anyone responds to
abandoning of changes that haven't been touched in years ? i
mentioned upthread that i've already abandoned 100s of CLs with only
one or two of them seeing a comment afterwards. seems clear to me
that this is viable.

> > what you describe is a problem when/if it happens, but my proposal is
> > orthogonal to it. if no one has commented on it in years, then
> > abandoning it isn't going to make a difference to it.
>
> But isn't it the role of maintainers to give a first comment? If a person who
> submitted a CL didn't get any replies, it doesn't mean the contribution is
> wrong or invalid. It may have to be rebased, because there was no review
> in time. And this is the metrics that should be important for companies
> sponsoring Chrome development (and the toolchain on top it including
> Electron etc.). This may help to increase financing to bring more people on
> board. I would personally help with porting build to Python 3, because with
> my current earnings of about $300 a month it feels both miserable and
> unfair to see that.

i don't necessarily disagree with the points you're making. however,
they're largely irrelevant to my proposal in this thread.

if you feel CLs are being posted but not being responded to, please
raise it on a more appropriate forum like chromium-dev@ where the
wider community can comment on it.
-mike

[anatoly techtonik]

On Sat, Dec 26, 2020 at 11:48 PM Mike Frysinger <vap...@chromium.org> wrote:
>
> On Sat, Dec 26, 2020 at 6:45 AM anatoly techtonik <tech...@gmail.com> wrote:
> > <snip>
> > I am against censorship on the internet, so if you don't want to state
> > the reason for renaming `master`, I can dig it up and post here.
>
> i'm not going to copy & paste the clear documentation that i already
> linked you to that explains everything in detail.
> stop trying to derail the thread on unrelated issues.

If you read "the clear documentation" that you **didn't link to**
yourself, then you will find out that it doesn't explain the reason
for renaming. The mailing list message you linked to says only that is
it done to comply to Inclusive Chromium Code:

"In order to align with Inclusive Chromium Code, we are changing
default branch name from master to main for all non-forked
non-mirrored repositories in chromium.googlesource.com."

If that Inclusive Chromium Code is that "clear documentation" you're
value referenced above, then it doesn't explain the rename either.
https://chromium.googlesource.com/chromium/src/+/master/styleguide/inclusive_code.md

So, can anybody just say loud and clear the reason for rename? I live
in Belarus where a dictatorship just right now packs people in buses
somewhere in the city, because they disagree with governmental terror
and violence, and I am tired of this censorship.

The metric is the calculated capacity of Chrome maintainers to respond and
review CLs.

> > > what you describe is a problem when/if it happens, but my proposal is
> > > orthogonal to it. if no one has commented on it in years, then
> > > abandoning it isn't going to make a difference to it.
> >
> > But isn't it the role of maintainers to give a first comment? If a person who
> > submitted a CL didn't get any replies, it doesn't mean the contribution is
> > wrong or invalid. It may have to be rebased, because there was no review
> > in time. And this is the metrics that should be important for companies
> > sponsoring Chrome development (and the toolchain on top it including
> > Electron etc.). This may help to increase financing to bring more people on
> > board. I would personally help with porting build to Python 3, because with
> > my current earnings of about $300 a month it feels both miserable and
> > unfair to see that.
>
> i don't necessarily disagree with the points you're making. however,
> they're largely irrelevant to my proposal in this thread.
>
> if you feel CLs are being posted but not being responded to, please
> raise it on a more appropriate forum like chromium-dev@ where the
> wider community can comment on it.
> -mike

Ok.
--
anatoly t.

[Andreas Papacharalampous]

(i apologize for commenting on unrelated topic)

> --scrubbed--

> The mailing list message you linked to says only that is
> it done to comply to Inclusive Chromium Code:   

The quote at the top of mentioned document can be applied to anywhere inside Chromium, not only to its code. Like the `master->main` migration.

Here's another thread with more clear reasoning as to why said migration is happening. I hope that answers your question(s).

If you have any more questions, please ask them at the thread Mike linked. 

[Mike Frysinger]

i haven't heard any negative feedback here, so i've started automating this a bit for CrOS repos to help test the waters.  the master->main migration reset the clock on a lot of them, but i still cleaned up a few 100s more that hadn't been touched in 5 years.

-mike