| Message ID | 1398343763-10704-2-git-send-email-afaerber@suse.de |
|---|---|
| State | New |
| Headers | show |
Il 24/04/2014 14:49, Andreas Färber ha scritto: > Invented by Anthony. Maintenance has been handled by me lately. > > Note that the tests themselves are intentionally not part of this entry; > they are considered part of the device or subsystem they are covering. > > Cc: Anthony Liguori <aliguori@amazon.com> > Cc: Stefan Hajnoczi <stefanha@redhat.com> > Signed-off-by: Andreas Färber <afaerber@suse.de> Actually, I see a mix of Stefan, mst, and you. I respectfully think that qtest is still better served by "community-style" maintainership. Paolo > --- > MAINTAINERS | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index c66946f..f746017 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -886,6 +886,16 @@ S: Maintained > F: tcg/tci/ > F: tci.c > > +Testing infrastructure > +---------------------- > +QTest > +M: Anthony Liguori <aliguori@amazon.com> > +M: Andreas Färber <afaerber@suse.de> > +S: Maintained > +F: include/sysemu/qtest.h > +F: qtest.c > +F: tests/libqtest.[hc] > + > Stable branches > --------------- > Stable 1.0 >
Il 24/04/2014 14:49, Andreas Färber ha scritto: > Invented by Anthony. Maintenance has been handled by me lately. > > Note that the tests themselves are intentionally not part of this entry; > they are considered part of the device or subsystem they are covering. > > Cc: Anthony Liguori <aliguori@amazon.com> > Cc: Stefan Hajnoczi <stefanha@redhat.com> > Signed-off-by: Andreas Färber <afaerber@suse.de> Actually, I see a mix of Stefan, mst, and you. I respectfully think that qtest is still better served by "community-style" maintainership. Paolo > --- > MAINTAINERS | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index c66946f..f746017 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -886,6 +886,16 @@ S: Maintained > F: tcg/tci/ > F: tci.c > > +Testing infrastructure > +---------------------- > +QTest > +M: Anthony Liguori <aliguori@amazon.com> > +M: Andreas Färber <afaerber@suse.de> > +S: Maintained > +F: include/sysemu/qtest.h > +F: qtest.c > +F: tests/libqtest.[hc] > + > Stable branches > --------------- > Stable 1.0 >
Am 28.04.2014 11:02, schrieb Paolo Bonzini: > Il 24/04/2014 14:49, Andreas Färber ha scritto: >> Invented by Anthony. Maintenance has been handled by me lately. >> >> Note that the tests themselves are intentionally not part of this entry; >> they are considered part of the device or subsystem they are covering. >> >> Cc: Anthony Liguori <aliguori@amazon.com> >> Cc: Stefan Hajnoczi <stefanha@redhat.com> >> Signed-off-by: Andreas Färber <afaerber@suse.de> > > Actually, I see a mix of Stefan, mst, and you. Maybe I should have better formulated "through my tree lately"? Because I did handle Stefan's recent patches. > I respectfully think > that qtest is still better served by "community-style" maintainership. That is exactly where we have been disagreeing over the last few months: Community-style maintenance does not work. In particular, Anthony used to handle such patches himself but does not any more. Peter is asking for pulls, we as community need someone to take decision on how to go about things (e.g., Stefan vs. Marcel), and you are - with all due respect - the only longtime contributor sending or asking about sending pulls for random series of yours one week after patches have been posted, for code that you refuse to step up as maintainer for (memory, Makefile infrastructure, tmp105, ...). Stefan has specifically called for someone to step up [1, 2], and if that is you or mst or PMM (CC'ed), less work for me! As long as patches and infrastructure don't bitrot and my test cases keep making progress (which I am rebasing any QOM changes on, so sending them prepended to qom-next seems natural) I am fine. None of you volunteered at the time. Stefan would've been my proposal as the most active, but he declined. So the issues here are twofold, a) who sends pulls? Stefan's patches went through me, and no one bothered to review libqtest.[hc] API changes of mine. Note that this patch does not fix any tree via T:, so it or a variation thereof could be applied independently. b) who gets CC'ed on and reviews patches? Currently neither me nor Stefan nor mst are CC'ed by get_maintainer.pl. This patch adds me. Review currently mostly relies on contributors CC'ing undocumented people who care to review - extending this patch to a bigger pool of M:s is certainly an option. Generally, our MAINTAINERS file is mixing the concepts of who gets CC'ed for review and who actually applies patches; the block layer makes that most evident. For qtest we are in need of both aspects. Regards, Andreas [1] http://patchwork.ozlabs.org/patch/318408/ [2] http://patchwork.ozlabs.org/patch/329092/
Il 28/04/2014 14:12, Andreas Färber ha scritto: > code that you refuse to step up as maintainer for (memory, > Makefile infrastructure, tmp105, ...). I can step up as maintainer for memory. At the time I did most of the memory work last year, Anthony was still the committer and he was okay with community-style maintainership and random pull requests that. Same for Makefiles, but on the other hand other people such as Peter and Michael have done configury work and I don't want to step on their toes. It looks like we approach the issue from opposite directions. You want as many files as possible covered by formal maintainers. I don't care about that, and prefer more flexibility for long-time contributors. I know Anthony didn't care, and I enjoyed the flexibility. I learnt that *you* care (the tmp105 story). I don't know how much Peter cares about having stuff covered by MAINTAINERS. The more he does, the more we need to think about how to define the status quo in MAINTAINERS. This means I'd effectively have to add myself there in more places. > So the issues here are twofold, > a) who sends pulls? Stefan's patches went through me, and no one > bothered to review libqtest.[hc] API changes of mine. Note that this > patch does not fix any tree via T:, so it or a variation thereof could > be applied independently. > b) who gets CC'ed on and reviews patches? Currently neither me nor > Stefan nor mst are CC'ed by get_maintainer.pl. This patch adds me. > Review currently mostly relies on contributors CC'ing undocumented > people who care to review - extending this patch to a bigger pool of M:s > is certainly an option. > > Generally, our MAINTAINERS file is mixing the concepts of who gets CC'ed > for review and who actually applies patches; the block layer makes that > most evident. For qtest we are in need of both aspects. Ok, this I fully agree with. Though we need (b) much more than (a). Do you agree? The problem is that if everything gets a formal maintainer people get overloaded. And I do think that this patch would overload you even more, and this is why I don't like it (both for your well-being, and egoistically because overloaded maintainers affect contributors negatively as well). What is the meaning of maintainer entries without "T:"? If it is basically "people listed are trusted by Anthony/Peter to send pull requests and will shepherd patches into the tree", then Stefan would agree to be included for qtest. It would also a definition that would fit what I do for memory, and for Makefiles we could include me+Peter+mst. Perhaps Paolo
On 29 April 2014 13:11, Paolo Bonzini <pbonzini@redhat.com> wrote: > It looks like we approach the issue from opposite directions. You want as > many files as possible covered by formal maintainers. I don't care about > that, and prefer more flexibility for long-time contributors. I know > Anthony didn't care, and I enjoyed the flexibility. I learnt that *you* > care (the tmp105 story). > > I don't know how much Peter cares about having stuff covered by MAINTAINERS. > The more he does, the more we need to think about how to define the status > quo in MAINTAINERS. This means I'd effectively have to add myself there in > more places. I don't care that we should have full coverage of every file in the tree in a MAINTAINERS entry. IMHO MAINTAINERS entries are for "I care about this code and you should send changes via me specifically". Where I differ from Anthony is that I really don't have the time to do review-and-commit of individual patches which fall through the cracks between maintained areas. What I think would be preferable would be if we could set up a process where one or more people could agree to take on that aspect of what Anthony used to do, and collate those "fall between the cracks" patches into a tree, which I would then apply pull requests from in the same way I do for the trivial queue. thanks -- PMM
diff --git a/MAINTAINERS b/MAINTAINERS index c66946f..f746017 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -886,6 +886,16 @@ S: Maintained F: tcg/tci/ F: tci.c +Testing infrastructure +---------------------- +QTest +M: Anthony Liguori <aliguori@amazon.com> +M: Andreas Färber <afaerber@suse.de> +S: Maintained +F: include/sysemu/qtest.h +F: qtest.c +F: tests/libqtest.[hc] + Stable branches --------------- Stable 1.0
Invented by Anthony. Maintenance has been handled by me lately. Note that the tests themselves are intentionally not part of this entry; they are considered part of the device or subsystem they are covering. Cc: Anthony Liguori <aliguori@amazon.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Andreas Färber <afaerber@suse.de> --- MAINTAINERS | 10 ++++++++++ 1 file changed, 10 insertions(+)