On Fri, Jun 5, 2015 at 11:30 AM, Michael Stefaniuc mstefani@redhat.de wrote:
patches/expire | 1 + patches/patches.css | 1 + patches/update | 2 ++ 3 files changed, 4 insertions(+)
diff --git a/patches/expire b/patches/expire index f143ab1..3cf75e6 100755 --- a/patches/expire +++ b/patches/expire @@ -37,6 +37,7 @@ my %status_expiry = "split" => 7, "depend" => 7, "sequence" => 7,
- "staging" => 30, "superseded" => 1, "testcase" => 7, "testfail" => 7,
diff --git a/patches/patches.css b/patches/patches.css index 745ec75..5746057 100644 --- a/patches/patches.css +++ b/patches/patches.css @@ -154,6 +154,7 @@ tr.odd { background-color: #f8e8e8; } .sequence, .sequence :link, .sequence :visited { color: #e08000; } .deferred, .deferred :link, .deferred :visited { color: #e08000; } .testcase, .testcase :link, .testcase :visited { color: #e08000; } +.staging, .staging :link, .staging :visited { color: #e08000; } .other, .other :link, .other :visited { color: #e08000; } .applyfail, .applyfail :link, .applyfail :visited { color: red; } .buildfail, .buildfail :link, .buildfail :visited { color: red; } diff --git a/patches/update b/patches/update index 4ccc910..335af0b 100755 --- a/patches/update +++ b/patches/update @@ -40,6 +40,7 @@ my %status_descr = "depend" => "Dependency", "superseded" => "Superseded", "sequence" => "Bad sequence",
- "staging" => "Staging", "testcase" => "Needs tests", "testfail" => "Test failure",
); @@ -57,6 +58,7 @@ my @legend = "<li>Someone else fixed the problem already.</li></ul>" ], [ "testcase", "<ul><li>You need to write some test cases demonstrating that the patch is correct.</li></ul>" ], [ "deferred", "<ul><li>The patch is deferred because of code freeze for an upcoming release. Either resend after the release, make the patch less intrusive, or make a convincing argument that it needs to be included in the release.</li></ul>" ],
- [ "staging", "<ul><li>The patch needs more work or wider testing. Please get it in over Wine Staging.</li></ul>" ], [ "other", "<ul><li>The patch belongs to another WineHQ project (website, appdb, etc.) and will be applied by the respective maintainer.</li></ul>" ], [ "applyfail", "<ul><li>The patch got mangled in transit.</li>" . "<li>It's not relative to the latest git.</li>" .
-- 2.4.2
I'm not sure we want to encourage wine-stating from Upstream (I'm not convinced either way), but in any case, the grammar seems wrong to me as a native speaker, how about: "The patch needs more work or wider testing. Please try to get into Wine-Staging."
or something similar?
On Fri, Jun 5, 2015 at 10:35 AM, Austin English austinenglish@gmail.com wrote:
... I'm not sure we want to encourage wine-stating from Upstream (I'm not convinced either way), but in any case, the grammar seems wrong to me as a native speaker, how about: "The patch needs more work or wider testing. Please try to get into Wine-Staging."
or something similar?
I would say "The patch needs more work or wider testing. Please try submitting the patch to Wine-Staging." A link to "https://github.com/wine-compholio/wine-staging/wiki/Development" might be good too.
Best, Erich
Austin English austinenglish@gmail.com writes:
I'm not sure we want to encourage wine-stating from Upstream (I'm not convinced either way), but in any case, the grammar seems wrong to me as a native speaker, how about: "The patch needs more work or wider testing. Please try to get into Wine-Staging."
I'm not going to use such a status, because I don't think getting patches into staging is going to make them more likely to be accepted.
On the contrary, if the iterations of the patch take place somewhere that I don't see, it will make it harder for me to assess the developer's ability (aka AJ rank), which is an essential part of the process. Particularly if you want to move on to more complicated things where I can't check every detail, it's essential to first earn my trust, or the trust of other veteran devs, and this has to happen right here.
I see the value of wine-staging in making patches more readily available to users, and I understand that the process of getting patches committed can be frustrating. But I don't think splitting the developers community is the answer.
Alexandre Julliard julliard@winehq.org wrote:
I see the value of wine-staging in making patches more readily available to users, and I understand that the process of getting patches committed can be frustrating. But I don't think splitting the developers community is the answer.
Main difference between wine-staging and winehq is that staging maintainers are actually interested to get the patches in to fix the bugs, and they do a lot not only to improve the patches created by somebody else, but also actively communicate with the patch authors. winehq behaviour on that regard is plain simple: silently reject or mark the patch as pending without any communication effort. If you take onto account number of staging patches and that staging maintainers do their job in their free time without getting paid that tells quite a bit about motivation in improving wine on both sides.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/08/2015 08:22 AM, Alexandre Julliard wrote:
Austin English austinenglish@gmail.com writes:
I'm not sure we want to encourage wine-stating from Upstream (I'm not convinced either way), but in any case, the grammar seems wrong to me as a native speaker, how about: "The patch needs more work or wider testing. Please try to get into Wine-Staging."
I'm not going to use such a status, because I don't think getting patches into staging is going to make them more likely to be accepted.
The UTF-7 and JobObject patches are prime examples of patches that successfully took the staging route. Before those had status "New - Patch not even looked at yet, there's *no* hope..."
On the contrary, if the iterations of the patch take place somewhere that I don't see, it will make it harder for me to assess the developer's ability (aka AJ rank), which is an essential part of the process. Particularly if you want to move on to more complicated things where I can't check every detail, it's essential to first earn my trust, or the trust of other veteran devs, and this has to happen right here.
I should have been less terse hoping that the intend of the Staging status is obvious...
I meant Staging for those patches where the AJ rank is known to be sub-par for the task at hand. When the patches rot in New status and the usual reviewers just shrug their shoulders with an "I see nothing obviously wrong". And Staging picks those patches up. Basically I was just trying to formalize the de facto process.
I see the value of wine-staging in making patches more readily available to users, and I understand that the process of getting patches committed
I see it also as an useful development tool similar to the Regression page but just for patches in bugzilla.
can be frustrating. But I don't think splitting the developers community is the answer.
bye michael
-
Alexandre Julliard -
Austin English -
Dmitry Timoshkov -
Erich E. Hoover -
Michael Stefaniuc