This script will automatically create a new stable merge request bug in
bugzilla for the given svn revision and release number.
Details
- Reviewers
hans - Commits
- rGd70b75e83650: Merging r298705: --------------------------------------------------------------…
rGd912243880f8: stable-merge-request.sh: Add a script for submitting merge requests via bugzilla
rL299455: Merging r298705:
rL298705: stable-merge-request.sh: Add a script for submitting merge requests via bugzilla
Diff Detail
- Build Status
Buildable 5059 Build 5059: arc lint + arc unit
Event Timeline
utils/release/stable-merge-request.sh | ||
---|---|---|
1 ↗ | (On Diff #91597) | I might have gone for bash just to avoid the worry of whether this works in other shells. |
245 ↗ | (On Diff #91597) | I'm a bit torn on using the Bugzilla for merge requests. On the one hand I can see the benefit of having an issue opened for each merge request to keep track of which ones are open and which ones are done. On the other hand, I don't like the lack of context and visibility. For a bug like "Please merge rXXX", I'll have to search my inbox to see what rXXX is anyway. And the author of rXXX might not be notified about the request. Also, the discussion on that bug does not get sent to any mailing list, so later searches for rXXX will not show the merge discussion. Having said that, I think this script will help though. A few ideas:
And while I've expressed some skepticism, I think one process is better than two, so maybe the script should simple be called merge-request.sh and be used for the major releases too. |
utils/release/stable-merge-request.sh | ||
---|---|---|
245 ↗ | (On Diff #91597) | For me, it's much easier to stay organized when the merge requests are in bugzilla, because there is a clear record of what has been done and what needs to be done. It also allows for other people to check in and easily see which requests are outstanding, without having to look through the mailing list archives. All the bugs have a link to the commit on phabricator, so that should make it easier to track down.
|
One thing I just realized: the bugzilla-cli package, at least for Ubuntu, seems only available in the most recent versions: http://packages.ubuntu.com/search?keywords=bugzilla-cli (similar for Debian: https://packages.debian.org/search?keywords=bugzilla-cli)
At least for my work and home machines, that makes it more impractical to use, and I'm guessing that might apply to many other developers.
There seems to be a tool called "bugz" which is more widely available: http://packages.ubuntu.com/search?keywords=bugz
Maybe the script should use that instead, or both?
utils/release/merge-request.sh | ||
---|---|---|
3 | nit: drop/change "Test the LLVM release candidates" | |
36 | What does "Revision project" mean? This seems to refer to the bugzilla Product field. Do we really care about that? Maybe to simplify this, both for the script and for the user, we could just file these bugs against the "new-bugs" product. | |
45 | Since "-user" is not spelled "-user-email", I think this could be spelled simply "-assign-to". | |
225 | This could match other bugs too.. maybe the query should be narrower? | |
235 | Don't you need to provide the URL to the repository? This seems to assume it's run inside a checked out repository. | |
237 | I think if we include the svn url above, there is no need for this... it should then work even if the user doesn't have an svn repository checked out or updated past the target revision. It does assume the user has 'svn' installed, but that's required for git-svn too. | |
252 | Personally, I prefer this to point to the viewvc, but it's not important. | |
256 | I assume this is just for your debugging? |
It is available on pypi, so you can install it using pip install. This is recommended anyway, since there is a bug with the older versions.
At least for my work and home machines, that makes it more impractical to use, and I'm guessing that might apply to many other developers.
There seems to be a tool called "bugz" which is more widely available: http://packages.ubuntu.com/search?keywords=bugz
Maybe the script should use that instead, or both?
I can't find the bugz package for fedora or on pypi, so it's going to be pretty hard for me to test / use that one.
utils/release/merge-request.sh | ||
---|---|---|
36 | This is optional, and does map to bugzilla Product field. The default is to use the new-bugs product, I thought having a project option would be useful if people wanted to be able to categorize their bugs, but I don't mind dropping this and the -component option if it helps simplify the script. | |
252 | Is there a way to get viewvc to show you the full diff with all changes on a single page? | |
256 | Yes, but I think it could be useful for users to verify they've entered the correct options. |
utils/release/merge-request.sh | ||
---|---|---|
36 | I think we should just drop it. | |
242 | I think the URL should just be https://llvm.org/svn/llvm-project/ Also, I think the current command will print the *whole* log going back from $revision. I think this is the way to do it: | |
252 | I don't think so, which does make Phabricator seem like a better alternative :-) | |
256 | Oh right, yes that makes sense. |
lgtm
utils/release/merge-request.sh | ||
---|---|---|
39 | Maybe drop this and list_valid_components now since we're just using 'new-bugs'? |
nit: drop/change "Test the LLVM release candidates"