| 1 |
Hi |
| 2 |
|
| 3 |
On 18:44 Sat 21 May , "Paweł Hajdan, Jr." wrote: |
| 4 |
> Recently there was a discussion about better tools for arch teams, to |
| 5 |
> speed up stabilizations and make them less error-prone. |
| 6 |
> |
| 7 |
> Here's my answer to that, still in very early development: |
| 8 |
> <http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=summary> |
| 9 |
> |
| 10 |
> You can just launch it like this: |
| 11 |
> |
| 12 |
> ./bugzilla-viewer.py --arch x86 |
| 13 |
|
| 14 |
I like it. Funnily It digged up some stable bugs from the stone-age |
| 15 |
that have been processed, but x86 was still on the CC-list. |
| 16 |
|
| 17 |
> It has more options, and can even try to do the stabilization in cvs |
| 18 |
> tree and capture repoman output (it has to be enabled from the |
| 19 |
> command-line, see --help). |
| 20 |
|
| 21 |
Have you seen app-portage/tatt ? I think there is a huge overlap between |
| 22 |
your project and tatt. tatt can already fetch bugs from bugzilla, |
| 23 |
create USE-flags and reverse dependency, as well as cvs commit scripts. |
| 24 |
You can use your own templates for the scripts, but tatt also provides |
| 25 |
some. The next thing would be to clean up a few bugs and do a release, |
| 26 |
unfortunately I have not yet found the time for this. I'd be happy to |
| 27 |
give you access to the git-tree your you can just clone it on github. |
| 28 |
|
| 29 |
https://github.com/tom111/tatt |
| 30 |
|
| 31 |
I also use aliases like |
| 32 |
x86bugs='bugz search --cc x86@g.o -a x86@g.o' |
| 33 |
secbugs='x86bugs | grep security' |
| 34 |
|
| 35 |
> I think the key thing for arch teams is batching. Compilation takes |
| 36 |
> time, viewing web pages has latency, so we should maximize the work that |
| 37 |
> a developer can do within his limited time. To do that, we should |
| 38 |
> prepare as much information as possible up-front (this is the goal of |
| 39 |
> bugzilla-viewer.py). |
| 40 |
|
| 41 |
Regarding the work-order I intentionally try to be agnostic. I do |
| 42 |
security bugs first, and then work on the oldest bug. |
| 43 |
|
| 44 |
> Then the developer can quickly process the list of bugs, and decide what |
| 45 |
> he's going to test. And then we can have tools for batch-testing, |
| 46 |
> batch-committing, and so on. Some of them already exist. |
| 47 |
> |
| 48 |
> Patches welcome, and please let me know what you think! |
| 49 |
|
| 50 |
|
| 51 |
|
| 52 |
-- |
| 53 |
Thomas Kahle |
| 54 |
http://dev.gentoo.org/~tomka/ |
Archives