If you look at our trac then is pretty obvious that premature setting to
positive review is about the only problem that we do NOT have.
LOL, stimmt haargenau.
--
You received this message because you are subscribed to the Google Groups
sage-devel group.
To unsubscribe from this group
Of course its possible that the author and the reviewer missed the lack of
testing coverage in a particular branch. But that can just as easily be
added in a followup ticket. The bar for a ticket is still definitely
improves Sage and not ran out of ideas of things to change on the branch
If
On 2015-05-08 11:12, Clemens Heuberger wrote:
Am 2015-05-07 um 10:27 schrieb Jeroen Demeyer:
On 2015-05-07 06:15, Clemens Heuberger wrote:
Am 2015-05-07 um 03:42 schrieb leif:
I might be wrong, but isn't it trivial to check whether the branch of a
ticket changed (after you merged it into some
Am 2015-05-07 um 10:27 schrieb Jeroen Demeyer:
On 2015-05-07 06:15, Clemens Heuberger wrote:
Am 2015-05-07 um 03:42 schrieb leif:
I might be wrong, but isn't it trivial to check whether the branch of a
ticket changed (after you merged it into some preliminary release)?
It is easy to check.
Am 2015-05-07 um 10:39 schrieb Jeroen Demeyer:
On 2015-05-06 21:24, Volker Braun wrote:
There is no reason that closed should be final, until the new branch
is published we *can* always back. That doesn't mean that you *should*
dump a pile of extra bookkeeping on me.
Let me make it clear
In my experience, people don't set a ticket to needs_work because of
something trivial at that time. Less read the code anyway, once it is
already in positive_review ;-)
Or else they add a commit immediately.
Or at least are pretty specific about what the issue is. (Sometimes
If all tests pass then any further change is either trivial (pretty much
by definition), or there is something so seriously foobared that the entire
ticket needs to be rethought (e.g. no testing).
grumpyThat's complete garbage and you know it. There are all sorts of
things that a
On Thursday, May 7, 2015 at 10:18:24 AM UTC+2, Nathann Cohen wrote:
In my experience, people don't set a ticket to needs_work because of
something trivial at that time.
If all tests pass then any further change is either trivial (pretty much by
definition), or there is something so
On Friday, May 8, 2015 at 11:26:08 AM UTC+2, Clemens Heuberger wrote:
Proposed Solution 2: Somehow introduce a flag that a positive_review
ticket must
no longer be changed because it is under consideration by the RM (many
variants
proposed, e.g. simply set it to closed or set some kind
On 2015-05-06 21:24, Volker Braun wrote:
There is no reason that closed should be final, until the new branch
is published we *can* always back. That doesn't mean that you *should*
dump a pile of extra bookkeeping on me.
Let me make it clear that I don't want to dump a pile of extra
On 2015-05-07 06:15, Clemens Heuberger wrote:
Am 2015-05-07 um 03:42 schrieb leif:
I might be wrong, but isn't it trivial to check whether the branch of a
ticket changed (after you merged it into some preliminary release)?
It is easy to check. But what if it did change? This might lead to an
Again, this is precisely what you should point out during the review
process.
But the review process has to end at one point if we ever want to merge a
ticket.
On Thursday, May 7, 2015 at 9:44:03 AM UTC+2, Nathann Cohen wrote:
Sure, in exceptional cases a positive_review / closed ticket
On Sat, Apr 18, 2015 at 10:48 AM, Julien Puydt julien.pu...@laposte.net wrote:
May I notice that :
(1) the ticket is in stage needs_review or positive_review ;
(2) what is actually reviewed is a precise commit in a git branch ;
(3) nothing forces the ticket and the branch to be synchronized.
On 2015-05-06 20:16, Clemens Heuberger wrote:
1) When the release manager starts to work on a ticket, he sets it to closed
in order to avoid further modification. This might lead to reopening closed
tickets when a problem arises in the merge.
2) The second part was about the automatic merge.
Sure, in exceptional cases a positive_review / closed ticket needs to be
unmerged. But that should be the exception, and not part of the normal flow.
In particular, just because you aren't finished bikeshedding / rearranging
the comments / fixing documentation typos is not enough of a reason;
In my experience, people don't set a ticket to needs_work because of
something trivial at that time. Less read the code anyway, once it is
already in positive_review ;-)
Or else they add a commit immediately.
(I don't strike myself as being very clear, these days O_o)
Nathann
--
You
Again, this is precisely what you should point out during the review
process.
But the review process has to end at one point if we ever want to merge a
ticket.
Oh, you meant *after* a positive review. I had misread, sorry.
In my experience, people don't set a ticket to needs_work because of
On Thursday, May 7, 2015 at 7:20:58 AM UTC+2, leif wrote:
Well, this simply should not happen
Exactly. You keep proposing complicated processes to make room for
something that should not happen.
The only
difference being that *someone else* came to the conclusion it isn't yet
ready to
On 2015-05-06 20:00, Clemens Heuberger wrote:
I'm happy to switch to closed when I merge it, and not only when it tests ok.
The downside is that you'll get more emails as I'll inevitably have to reopen
tickets, but merging/unmerging is scripted anyways. Eventually the merge will be
done by a
On Wednesday, May 6, 2015 at 8:07:08 PM UTC+2, Jeroen Demeyer wrote:
And it just feels like an unneeded restriction that tickets shouldn't be
changed after positive_review: there is no fundamental reason why
positive_review should be final.
There is no reason that closed should be final,
Am 2015-05-06 um 20:07 schrieb Jeroen Demeyer:
On 2015-05-06 20:00, Clemens Heuberger wrote:
I'm happy to switch to closed when I merge it, and not only when it tests
ok.
The downside is that you'll get more emails as I'll inevitably have to
reopen
tickets, but merging/unmerging is
Am 2015-04-19 um 01:10 schrieb Volker Braun:
On Saturday, April 18, 2015 at 4:47:05 AM UTC-4, Clemens Heuberger wrote:
Freezing tickets once release manager starts merging them
- change status to closed
- some new status)
I'm happy to switch to closed when
Am 2015-05-07 um 03:42 schrieb leif:
I might be wrong, but isn't it trivial to check whether the branch of a
ticket changed (after you merged it into some preliminary release)?
It is easy to check. But what if it did change? This might lead to an infinite
cycle, as outlined before.
Regards, CH
Volker Braun wrote:
On Wednesday, May 6, 2015 at 8:07:08 PM UTC+2, Jeroen Demeyer wrote:
And it just feels like an unneeded restriction that tickets
shouldn't be
changed after positive_review: there is no fundamental reason why
positive_review should be final.
+1
Clemens Heuberger wrote:
Am 2015-05-07 um 03:42 schrieb leif:
I might be wrong, but isn't it trivial to check whether the branch of a
ticket changed (after you merged it into some preliminary release)?
It is easy to check. But what if it did change? This might lead to an infinite
cycle, as
On 04/20/2015 09:31 PM, Jeroen Demeyer wrote:
For the record, this is what I did as release manager:
1. take a bunch of tickets with positive_review, make a private Sage
release with them, test them on the buildbot.
2a. if there are buildbot failures and it's clear which ticket caused
On Sunday, April 19, 2015 at 12:32:20 PM UTC-4, leif wrote:
On 04/19/2015 05:41 PM, Nathann Cohen wrote:
I often have a look at positively reviewed tickets and sometimes ask
questions about the review. Positive review just mean that one person
agreed
that the changes were good to be
For the record, this is what I did as release manager:
1. take a bunch of tickets with positive_review, make a private Sage
release with them, test them on the buildbot.
2a. if there are buildbot failures and it's clear which ticket caused
them: set the ticket to needs_work and GOTO 1.
2b.
Hello Volker,
I'm happy to switch to closed when I merge it, and not only when it tests
ok.
Works for me. This way we will know the last commit that you consider
in your script, and we run no danger of adding a new one after that.
Eventually the
merge will be done by a script, so ideally
Am 2015-04-19 um 01:10 schrieb Volker Braun:
Freezing tickets once release manager starts merging them
- change status to closed
- some new status)
I'm happy to switch to closed when I merge it, and not only when it tests ok.
+1
The downside is that you'll
Hello,
I agree with the fact that it would be better to move ticket to 'closed'
as soon as the release manager is working on it. But I do not agree that
this should be automatic after one second!
I often have a look at positively reviewed tickets and sometimes ask
questions about the
Hellooo,
I often have a look at positively reviewed tickets and sometimes ask
questions about the review. Positive review just mean that one person agreed
that the changes were good to be integrated. But it might still interest
other to have a look (or even the reviewer might
On 04/19/2015 05:41 PM, Nathann Cohen wrote:
I often have a look at positively reviewed tickets and sometimes ask
questions about the review. Positive review just mean that one person agreed
that the changes were good to be integrated. But it might still interest
other to have a look (or even
Le Sat, 18 Apr 2015 11:20:59 +0200,
Nathann Cohen nathann.co...@gmail.com a écrit :
Hello,
We somehow have to come to a conclusion.
+1
Never change positive_review_tickets (and adapt developer guide,
see #18228)
-1
Cool-off period
+0.5
Freezing tickets once release manager
On Saturday, April 18, 2015 at 4:47:05 AM UTC-4, Clemens Heuberger wrote:
Freezing tickets once release manager starts merging them
- change status to closed
- some new status)
I'm happy to switch to closed when I merge it, and not only when it tests
ok. The downside is
Am 2015-04-17 um 13:43 schrieb Volker Braun:
I already proposed a cool-off period, possible but somewhat annoying.
What about blockers? Would they also have to wait two weeks? Even after .rc3 is
out with one trivial bug?
Ideally,
continuous integration would start merging your ticket the
Hello,
We somehow have to come to a conclusion.
+1
Never change positive_review_tickets (and adapt developer guide, see #18228)
-1
Cool-off period
+0.5
Freezing tickets once release manager starts merging them
(various variants proposed:
- post a comment
+1
-
Hell,
I also believe that something should be done about that, and that it can be
solved in much more satisfying ways. Some propositions:
- A one-week delay (*) between latest commit and merge. We make sure that every
last-minute change has been made. It also gives more time for
Am 2015-04-17 um 12:03 schrieb Nathann Cohen:
- A one-week delay (*) between latest commit and merge. We make sure that
every
last-minute change has been made. It also gives more time for everybody to
look at the branch.
Reduces the risk of loosing commits, but does not exclude it.
As an
I already proposed a cool-off period, possible but somewhat annoying.
Ideally, continuous integration would start merging your ticket the second
you set it to positive review. We are not there yet, but we'll do it
eventually.
We don't need extra ticket states, we just need to agree to stop
40 matches
Mail list logo
