Ciro and Andrea, I appreciate both of your concerns. My reason for wanting to have a procedure for abandoning changes is, right now, we have close to 250 open changes on Gerrit, about 50 of which have not been updated in the last year. This feels, to me, to be a little bit unmanageable and will only get worse without guidelines for managing it. I doubt anything past the most recent top 50 changes gets much attention by most reviewers/maintainers, which is a real shame because some stuff outside this is still of use to the project --- it's just lost in a set of changes no one knows how to properly handle right now. I'd like to get towards a state where the set of open changes is firmly road to being merged. At the end of the day, if we don't have a policy of dealing with changes that are no longer being worked on (and no one wishes to take ownership of), what are we to do when we have 500 open changes, or even 1000? How is a reviewer to know where best to invest their time?
Abandoning a change should always be the last step, but I think after a month of inactivity, "pinging" the original contributor is acceptable and giving them two weeks to respond is fair. Even if the contributor messages back to say "I'll get back to this at a later date"; that's an acceptable acknowledgement of interest for us to keep the change and it should thereby remain open. It should be stated, this won't be an automated process. Reviewers are free to leave things open for longer if they wish. Reviewers are free to block an abandonment if the change is something they are personally interested in (I'll update the guidelines to state this is possible). The main question we're trying to ask is "Does anyone care about this change anymore?" if the answer is no, then why keep it open? Also, abandoning a change is not the same as deletion. You can still view abandoned changes if you wish. It's not "gone", it's just no longer in the set of changes the project is actively working on. It would not be too much hassle for someone to resurrect an abandoned change if they wish. Kind regards, Bobby PS: More active discussion on these guidelines is occurring on Gerrit: https://gem5-review.googlesource.com/c/public/gem5/+/21419 -- Dr. Bobby R. Bruce Room 2236, Kemper Hall, UC Davis Davis, CA, 95616 ________________________________ From: gem5-dev <gem5-dev-boun...@gem5.org> on behalf of Andrea Mondelli <andrea.monde...@ucf.edu> Sent: Saturday, October 5, 2019 9:02 AM To: gem5 Developer List <gem5-dev@gem5.org> Subject: Re: [gem5-dev] Updating Contribution.md review guidelines. Feedback appreciated. Hi An alternative solution could be to flag these commits with "pending adoption." In the past, I've been interested in pending commits, and I've added them to my watchlist, waiting to know the outcome. In other cases, I have personally used a commit waiting to be submitted (for example, all the patches related to the serialization of LFENCE). If a patch is "waiting for the adoption," for example, as with orphan packages in the Debian project, some developers will likely adopt it to fix any conflicts and eventually expand it with their further changes. my two cents Il giorno 5 ott 2019, alle ore 02:21, Ciro Santilli <ciro.santi...@arm.com<mailto:ciro.santi...@arm.com>> ha scritto: 1) What is the advantage of abandoning changes? Could reviewers just remove themselves from the reviewer list if they're not interested in the patch? Maybe mark as WIP instead of abandoning. I generally dislike when websites / communities close my stuff. Bests, A. _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
