8:56 a.m.
Back from holidays, I have five feature branches. This is somewhat
insane, and I need to come to conclusions to trash, merge or update
these. Here we go:
koji: Use koji scratch builds. This is just a manpage update, and a
separate script to download koji scratch builds. I could commit this
myself, but since the corresponding issue #17 is assigned to sochotni I
hesitate for that very reason. As long as noone says otherwise, I intend
to commit this one.
no-must: Remove most MUST/SHOULD from output. This is dicussed in the
related bug #68. We need to finish this discussion, preferably in the
bug. In particular, I need sochotni to reply to my last attempt to find
common ground.
rm-bugz: This was discussed in the list, see e. g.
https://lists.fedorahosted.org/pipermail/fedorareview/2012-July/000006.html.
My conclusion is that removing the bugzilla options is acceptable if
(and only if) a separate tool is provided with these options. Unless
there are other opinions, I might merge such a solution. I said 'might',
didn't I?
vers-info: Keep devel branch ready to produce post-release rpm:s (which
means some fixes in release branches). I think sochotni and I agreed on
this, but it's long time since. Once again, as long as there is no other
opinions, I plan to merge this.
So, you have been warned. I guess this is the only way to get attention
--alec
9:42 a.m.
Quoting Alec Leamas (2012-08-07 15:56:58)
Back from holidays, I have five feature branches. This is somewhat
insane, and I need to come to conclusions to trash, merge or update
these. Here we go:
koji: Use koji scratch builds. This is just a manpage update, and a
separate script to download koji scratch builds. I could commit this
myself, but since the corresponding issue #17 is assigned to sochotni I
hesitate for that very reason. As long as noone says otherwise, I intend
to commit this one.
Feel free to commit that one. I assigned it to myself long time ago when
pingou and we were the only active devs. Automating work with koji
scratch-builds would nice(r), but also harder with regards to various
tests. Feel free to push this to release-0.2.1, since the changes are
more-less trivial
no-must: Remove most MUST/SHOULD from output. This is dicussed in
the
related bug #68. We need to finish this discussion, preferably in the
bug. In particular, I need sochotni to reply to my last attempt to find
common ground.
Commented in trac
rm-bugz: This was discussed in the list, see e. g.
https://lists.fedorahosted.org/pipermail/fedorareview/2012-July/000006.html.
My conclusion is that removing the bugzilla options is acceptable if
(and only if) a separate tool is provided with these options. Unless
there are other opinions, I might merge such a solution. I said 'might',
didn't I?
Indeed, if we have a separate tool to do this easily...I am all for
removing this from f-r (we can still package it similar as
fedora-create-review)
vers-info: Keep devel branch ready to produce post-release rpm:s
(which
means some fixes in release branches). I think sochotni and I agreed on
this, but it's long time since. Once again, as long as there is no other
opinions, I plan to merge this.
Actually I don't like this very much. I'd rather people use either git
version directly (try-fedora-review exists exactly for that) or really
run released versions. I'll give this another look though so don't throw
the branch away just yet :-)
So, you have been warned. I guess this is the only way to get
attention
WARNING! WARNING! would work as well :-)
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
2:14 a.m.
On Tue, 2012-08-07 at 15:56 +0200, Alec Leamas wrote:
koji: Use koji scratch builds. This is just a manpage update, and a
separate script to download koji scratch builds. I could commit this
myself, but since the corresponding issue #17 is assigned to sochotni I
hesitate for that very reason. As long as noone says otherwise, I intend
to commit this one.
I just want that the default remains mock but you told me it is, so fine
for me :)
no-must: Remove most MUST/SHOULD from output. This is dicussed in
the
related bug #68. We need to finish this discussion, preferably in the
bug. In particular, I need sochotni to reply to my last attempt to find
common ground.
Maybe we can remove it from the beginning of the line and just put it
capital within the sentence as well.
MUST:
[] License MUST be valid
[] Package MUST NOT contain kernel module
....
But having them at the beginning of the line seems indeed to confuse
quite some people, so +1 to change this.
rm-bugz: This was discussed in the list, see e. g.
https://lists.fedorahosted.org/pipermail/fedorareview/2012-July/000006.html.
My conclusion is that removing the bugzilla options is acceptable if
(and only if) a separate tool is provided with these options. Unless
there are other opinions, I might merge such a solution. I said 'might',
didn't I?
To be honest, I do wonder how many people use this. I do think most
people run f-r, edit the report and copy/paste its output to the ticket.
vers-info: Keep devel branch ready to produce post-release rpm:s
(which
means some fixes in release branches). I think sochotni and I agreed on
this, but it's long time since. Once again, as long as there is no other
opinions, I plan to merge this.
My understanding is:
- Master -> the last release
- Devel -> all new changes (besides the one too big which have their own
branch)
- ReleaseX -> changes from devel planned for the next release (that
branch disappears when merge into devel at release)
So I think either people use the RPM from the release or they test Devel
or ReleaseX, I think we should be allowed to have a broken devel branch
once in a while.
Cheers,
Pierre
2:53 a.m.
On 08/09/2012 09:14 AM, Pierre-Yves Chibon wrote:
On Tue, 2012-08-07 at 15:56 +0200, Alec Leamas wrote:
[cut]
> no-must: Remove most MUST/SHOULD from output. This is dicussed in the
> related bug #68. We need to finish this discussion, preferably in the
> bug. In particular, I need sochotni to reply to my last attempt to find
> common ground.
Maybe we can remove it from the beginning of the line and just put it
capital within the sentence as well.
MUST:
[] License MUST be valid
[] Package MUST NOT contain kernel module
....
But having them at the beginning of the line seems indeed to confuse
quite some people, so +1 to change this.
I have updated the branch to fit my last
proposal in the bug #68, and
intent to merge it after the release branch is merged into devel.
> rm-bugz: This was discussed in the list, see e. g.
> https://lists.fedorahosted.org/pipermail/fedorareview/2012-July/000006.html.
> My conclusion is that removing the bugzilla options is acceptable if
> (and only if) a separate tool is provided with these options. Unless
> there are other opinions, I might merge such a solution. I said 'might',
> didn't I?
To be honest, I do wonder how many people use this. I do think most
people run f-r, edit the report and copy/paste its output to the ticket.
Agreed.
However, some people seemed unhappy to remove it without
alternatives. Se be it a separate script.
> vers-info: Keep devel branch ready to produce post-release rpm:s (which
> means some fixes in release branches). I think sochotni and I agreed on
> this, but it's long time since. Once again, as long as there is no other
> opinions, I plan to merge this.
My understanding is:
- Master -> the last release
- Devel -> all new changes (besides the one too big which have their own
branch)
- ReleaseX -> changes from devel planned for the next release (that
branch disappears when merge into devel at release)
So I think either people use the RPM from the release or they test Devel
or ReleaseX, I think we should be allowed to have a broken devel branch
once in a while.
Absolutely, agreed. The idea with this is just you should be able
to
create complete packages also from devel. It makes sense e. g. when you
want to test running the no-network limited testsuite as %check in the
specfile. Overall, if it's possible to generate RPM:s from the devel
branch It might be easier to keep the spec file in shape IMHO.
So, this is more a question of exercising the complete build procedure
than actually distributing post/pre-release packages. As Stan says,
let's asume users run either released RPM:s or directly from git. After
all, f-r is not the kind of sw which delivers nighty builds :)
--alec
9:11 a.m.
>> rm-bugz: This was discussed in the list, see e. g.
>> https://lists.fedorahosted.org/pipermail/fedorareview/2012-July/000006.html.
>> My conclusion is that removing the bugzilla options is acceptable if
>> (and only if) a separate tool is provided with these options. Unless
>> there are other opinions, I might merge such a solution. I said
'might',
>> didn't I?
> To be honest, I do wonder how many people use this. I do think most
> people run f-r, edit the report and copy/paste its output to the ticket.
Agreed. However, some people seemed unhappy to remove it without
alternatives. Se be it a separate script.
Well providing a simple script which can be fed with a review bug
number and review text and it will automatically set all appropriate
flags/assignments etc would indeed be very nice. But as long as those
commandline options remain there and print a sensible message feel free
to remove bz support right away IMO
>> vers-info: Keep devel branch ready to produce post-release
rpm:s (which
>> means some fixes in release branches). I think sochotni and I agreed on
>> this, but it's long time since. Once again, as long as there is no other
>> opinions, I plan to merge this.
> My understanding is:
> - Master -> the last release
True
> - Devel -> all new changes (besides the one too big which
have their own
> branch)
True
> - ReleaseX -> changes from devel planned for the next release
(that
> branch disappears when merge into devel at release)
Not really...If there is a release pending (such as it was past few
weeks) simple fixes (wording of checks, moving checks between
must/should and the like) should be done in the release-X branch instead
of devel branch. If you need that fix in devel immediately, just merge
(non-ff) release branch to devel. If they are done in devel branch I
have to cherry-pick them and after release they get merged back to devel
which duplicates the messages. Gets quite ugly.
> So I think either people use the RPM from the release or they
test Devel
> or ReleaseX, I think we should be allowed to have a broken devel branch
> once in a while.
Absolutely, agreed. The idea with this is just you should be able to
create complete packages also from devel. It makes sense e. g. when you
want to test running the no-network limited testsuite as %check in the
specfile. Overall, if it's possible to generate RPM:s from the devel
branch It might be easier to keep the spec file in shape IMHO.
So, this is more a question of exercising the complete build procedure
than actually distributing post/pre-release packages. As Stan says,
let's asume users run either released RPM:s or directly from git. After
all, f-r is not the kind of sw which delivers nighty builds :)
I it true it would make testing a full release cycle much easier.
Especially with those "skip if no network" tests and the like. However I
think it will be easier to just create a special script that will
generate tarball from given git hash and then create srpm with this
special tarball (it can even have weird version like 9999).
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
11:35 a.m.
OK, most things fixed.
-koji branch made it for 0.2.2
- no-must (new layout) is in devel
- rm-bugs (remove assign/login support) is in devel
- vers-info is in limbo, with ongoing discussion.
Thanks for input!
--alec
4275
days inactive
4277
days old
fedorareview@lists.fedorahosted.org
5 comments
3 participants
participants (3)
-
Alec Leamas -
Pierre-Yves Chibon -
Stanislav Ochotnicky