On 6/29/13, T.C. Hollingsworth tchollingswo...@gmail.com Perhaps
the real fix here would be to just remove that placeholder
text (and double-check that the bodhi CLI rejects updates with blank
descriptions)? Personally I just find it really annoying to have to
backspace that out and fill in
On 07/10/2013 07:53 PM, Ben Boeckel wrote:
On Wed, 03 Jul, 2013 at 04:35:58 GMT, Alex G. wrote:
We shouldn't be surprised that update descriptions are crap. They are
just an annoyance for a lot of us, especially since we've put all that
information in a bunch of other places.
Where else
On Wed, 03 Jul, 2013 at 04:35:58 GMT, Alex G. wrote:
We shouldn't be surprised that update descriptions are crap. They are
just an annoyance for a lot of us, especially since we've put all that
information in a bunch of other places.
Where else would information like the information in this
On Tue, Jul 02, 2013 at 09:39:47PM -0700, Adam Williamson wrote:
most updates get submitted with the default +3 auto-push, even
though it's perhaps not appropriate for all updates.
So can we please get a sane default value then that is good for most
updates and can be adjusted for special
On 2013-07-04 2:56, Till Maas wrote:
On Tue, Jul 02, 2013 at 09:39:47PM -0700, Adam Williamson wrote:
most updates get submitted with the default +3 auto-push, even
though it's perhaps not appropriate for all updates.
So can we please get a sane default value then that is good for most
On Thu, Jul 04, 2013 at 02:51:46PM -0700, Adam Williamson wrote:
It would be interesting to make the default 1 or 2 for non-critpath
and 3 for critpath...
+1 Let's do it!
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org
--
devel mailing list
On Thu, 2013-07-04 at 18:55 -0400, Matthew Miller wrote:
On Thu, Jul 04, 2013 at 02:51:46PM -0700, Adam Williamson wrote:
It would be interesting to make the default 1 or 2 for non-critpath
and 3 for critpath...
+1 Let's do it!
Untested, but this should work:
On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal dan.mas...@gmail.com wrote:
On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote:
Not sure if it makes any sense but maybe could we have something like
freeze tag changes until desc is better.
I propose this because testers will
On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote:
On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal dan.mas...@gmail.com wrote:
On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote:
Not sure if it makes any sense but maybe could we have something like
freeze tag
Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit :
On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote:
On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
dan.mas...@gmail.com wrote:
On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten
On Wed, Jul 3, 2013 at 9:47 AM, Michael Scherer m...@zarb.org wrote:
Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit :
On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote:
On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
dan.mas...@gmail.com
Le mercredi 03 juillet 2013 à 09:54 +0200, Johannes Lips a écrit :
On Wed, Jul 3, 2013 at 9:47 AM, Michael Scherer m...@zarb.org wrote:
Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a
écrit :
On Wed, Jul 3, 2013 at 9:32
On 3 July 2013 08:47, Michael Scherer m...@zarb.org wrote:
Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit :
On Wed, Jul 3, 2013 at 9:32 AM, drago01 drag...@gmail.com wrote:
On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
dan.mas...@gmail.com wrote:
On
On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote:
Richard W.M. Jones wrote:
%changelog -f changelog_file
%changelog -g git_repo
And, I suppose:
%changelog -s Subversion_repo
%changelog -c CVS_repo
%changelog -m Monotone_repo
%changelog -h Mercurial_repo
%changelog -a
On Wed, 2013-07-03 at 09:32 +0200, drago01 wrote:
This is also a perfect example of useless does not fix bug x karma.
If it is not *worse* then the previous package there is no reason to
give it negative karma.
Yes, that is a problem too. Particularly so with selinux updates.
But getting back
On 07/03/2013 03:12 PM, Richard W.M. Jones wrote:
On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote:
Richard W.M. Jones wrote:
%changelog -f changelog_file
%changelog -g git_repo
And, I suppose:
%changelog -s Subversion_repo
%changelog -c CVS_repo
%changelog -m Monotone_repo
On Wed, Jul 03, 2013 at 06:21:51PM +0300, Panu Matilainen wrote:
On 07/03/2013 03:12 PM, Richard W.M. Jones wrote:
On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote:
Richard W.M. Jones wrote:
%changelog -f changelog_file
%changelog -g git_repo
And, I suppose:
%changelog -s
Am 03.07.2013 09:54, schrieb Johannes Lips:
Could be, but if the still broken bugs are going to be closed, when the
update becomes stable
since when do bugs get magically closed?
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote:
Could be, but if the still broken bugs are going to be closed, when the
update becomes stable
since when do bugs get magically closed?
Since 2007 or so?
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁
Am 03.07.2013 18:21, schrieb Matthew Miller:
On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote:
Could be, but if the still broken bugs are going to be closed, when the
update becomes stable
since when do bugs get magically closed?
Since 2007 or so?
what sense makes this?
a
On Wed, 03 Jul 2013 19:38:00 +0200
Reindl Harald h.rei...@thelounge.net wrote:
Am 03.07.2013 18:21, schrieb Matthew Miller:
On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote:
Could be, but if the still broken bugs are going to be closed,
when the update becomes stable
Am 03.07.2013 19:54, schrieb Kevin Fenzi:
On Wed, 03 Jul 2013 19:38:00 +0200
Reindl Harald h.rei...@thelounge.net wrote:
a new upstream-release does not implicitly close any bug
on the other hand it makes hardly sense to hold back a update
not fixing all bugreports - this all makes no
On Wed, Jul 3, 2013 at 7:54 PM, Kevin Fenzi ke...@scrye.com wrote:
On Wed, 03 Jul 2013 19:38:00 +0200
Reindl Harald h.rei...@thelounge.net wrote:
Am 03.07.2013 18:21, schrieb Matthew Miller:
On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote:
Could be, but if the still broken
On 2013-07-03 0:54, Johannes Lips wrote:
If it doesn't fix the bugs, the update should fix, it is
appropriate
to give negative karma. Otherwise the bugs would be closed, when
it
becomes stable, but won't be fixed.
That's not what the guidelines say :
On 2013-07-03 1:11, Michael Scherer wrote:
Then we could decide on :
- better process, ie if you happen to notice a bug is not fixed by
update, please reopen it
- better tooling, ie a way to say do not close this bug to bodhi.
Either a message in bodhi, or something on bugzilla side.
The
On 2013-07-03 2:28, Ian Malone wrote:
Tooling issues aside (and it is undesireable that bugs should get
marked fixed if they haven't been) I think this rule is wrong under a
strict reading. If an update claims to fix two bugs and fixes neither
then neither is the *only* change (highlighting is
On 2013-07-03 8:21, Panu Matilainen wrote:
On 07/03/2013 03:12 PM, Richard W.M. Jones wrote:
On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote:
Richard W.M. Jones wrote:
%changelog -f changelog_file
%changelog -g git_repo
And, I suppose:
%changelog -s Subversion_repo
%changelog
On 2013-07-03 10:54, Kevin Fenzi wrote:
On Wed, 03 Jul 2013 19:38:00 +0200
Reindl Harald h.rei...@thelounge.net wrote:
Am 03.07.2013 18:21, schrieb Matthew Miller:
On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote:
Could be, but if the still broken bugs are going to be closed,
On Wed, 03 Jul 2013 12:55:11 -0700
Adam Williamson awill...@redhat.com wrote:
As discussed up thread, this is not the current policy and I'd really
prefer people don't do this. -1 is a Serious Thing, not to be used
lightly.
Sorry, you are right.
If an update claims to fix multiple bugs
On 3 July 2013 20:48, Adam Williamson awill...@redhat.com wrote:
On 2013-07-03 2:28, Ian Malone wrote:
Tooling issues aside (and it is undesireable that bugs should get
marked fixed if they haven't been) I think this rule is wrong under a
strict reading. If an update claims to fix two bugs
On Wed, 2013-07-03 at 16:33 +0100, Richard W.M. Jones wrote:
SuSE too ...
Rich.
But they reformat everything by hand. For a representative example,
compare:
https://git.gnome.org/browse/evolution/tree/NEWS
with
On Mon 01 Jul 2013 05:54:37 PM EDT, Dan Mashal wrote:
On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote:
Not sure if it makes any sense but maybe could we have something like
freeze tag changes until desc is better.
I propose this because testers will not _really_ want to
Hi
On Tue, Jul 2, 2013 at 9:42 AM, Ryan Lerch wrote:
is it possible for not the maintainer to be able to edit the update text
of updates? I'm thinking, say, a member of the documentation team?
No but feel free to file a RFE against bodhi
https://fedorahosted.org/bodhi/
Rahul
--
devel
Hi,
What about the following idea autogenerate update descriptions for most
cases:
* If %{release} is 1, it's an upstream version update. By storing the url
to the upstream changelog (possibly appropriately parametrized with a
%{version} placeholder), bodhi would generate a description such as
On Mon, Jul 01, 2013 at 11:41:48PM +0200, Björn Persson wrote:
Richard W.M. Jones wrote:
As I think I said pretty clearly, there are two streams of
documentation: the detailed changelogs and the release notes (which
summarise changes in a human-readable form for a whole release).
These
Richard W.M. Jones wrote:
%changelog -f changelog_file
%changelog -g git_repo
And, I suppose:
%changelog -s Subversion_repo
%changelog -c CVS_repo
%changelog -m Monotone_repo
%changelog -h Mercurial_repo
%changelog -a Arch_repo
%changelog -b Bazaar_repo
... and so on, right? And every time
On Mon, 2013-07-01 at 14:54 -0700, Dan Mashal wrote:
There is already a perfect example of this.
https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
Dan
Thanks for pointing it out. I've filed more negative karma against this
update, but it needs even
On Mon, 2013-07-01 at 14:54 -0700, Dan Mashal wrote:
There is already a perfect example of this.
https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
Dan
I went through updates-testing looking for placeholder text (and will
never be doing that again,
On 07/01/2013 01:25 PM, Adam Williamson wrote:
On 2013-07-01 1:28, Richard W.M. Jones wrote:
Since this topic comes up every few months, and no one's pointed
out the obvious answer yet, I'll say it:
* Instead of making up more rules, make the tooling better so
we don't have to repeat update
On 2013-07-02 21:32, Michael Catanzaro wrote:
On Mon, 2013-07-01 at 14:54 -0700, Dan Mashal wrote:
There is already a perfect example of this.
https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
Dan
I went through updates-testing looking for placeholder
On 07/01/2013 02:43 PM, Johannes Lips wrote:
Richard W.M. Jones wrote:
Since this topic comes up every few months, and no one's pointed
out the obvious answer yet, I'll say it:
* Instead of making up more rules, make the tooling better so
we don't have to repeat update descriptions in
* Richard W.M. Jones [01/07/2013 09:28] :
* Instead of making up more rules, make the tooling better so
we don't have to repeat update descriptions in multiple places. *
Note that you have to describe your update a grand total of once.
Emmanuel
--
devel mailing list
On Mon, Jul 01, 2013 at 10:45:10AM +0200, Emmanuel Seyman wrote:
* Richard W.M. Jones [01/07/2013 09:28] :
* Instead of making up more rules, make the tooling better so
we don't have to repeat update descriptions in multiple places. *
Note that you have to describe your update a grand
On Mon, Jul 1, 2013 at 6:44 AM, Richard W.M. Jones rjo...@redhat.com wrote:
On Mon, Jul 01, 2013 at 10:45:10AM +0200, Emmanuel Seyman wrote:
* Richard W.M. Jones [01/07/2013 09:28] :
* Instead of making up more rules, make the tooling better so
we don't have to repeat update descriptions
On 06/29/2013 05:12 PM, T.C. Hollingsworth wrote:
I do agree that the RPM changelog is completely useless in the case of
most of my packages, and if there is something interesting there it
would benefit from a slightly longer description in the update summary
rather than some magical automatic
On 2013-07-01 1:28, Richard W.M. Jones wrote:
Since this topic comes up every few months, and no one's pointed
out the obvious answer yet, I'll say it:
* Instead of making up more rules, make the tooling better so
we don't have to repeat update descriptions in multiple places. *
You appear to
On Mon, 2013-07-01 at 11:25 -0700, Adam Williamson wrote:
You appear to be missing the contention made by me and others that
the
update description is not and should not be a simple repetition of
any
other content. It is not the RPM changelog. It is not the git commit
log. It is not the
Richard W.M. Jones wrote:
Since this topic comes up every few months, and no one's pointed
out the obvious answer yet, I'll say it:
* Instead of making up more rules, make the tooling better so
we don't have to repeat update descriptions in multiple places. *
Wouldn't it make sense to perhaps
On Mon, Jul 01, 2013 at 11:25:51AM -0700, Adam Williamson wrote:
On 2013-07-01 1:28, Richard W.M. Jones wrote:
Since this topic comes up every few months, and no one's pointed
out the obvious answer yet, I'll say it:
* Instead of making up more rules, make the tooling better so
we don't
Richard W.M. Jones wrote:
As I think I said pretty clearly, there are two streams of
documentation: the detailed changelogs and the release notes (which
summarise changes in a human-readable form for a whole release).
These should already exist, upstream.
No need for them to be
On Mon, Jul 1, 2013 at 2:41 PM, Björn Persson
bj...@xn--rombobjrn-67a.se wrote:
Perhaps you would like to write an RFC specifying the Source Code,
Changelogs and Release Notes Publishing Protocol and submit it to the
IETF, so that there will be a sane way to automatically find and parse
those
Le lundi 01 juillet 2013 à 14:01 -0500, Michael Catanzaro a écrit :
On Mon, 2013-07-01 at 11:25 -0700, Adam Williamson wrote:
You appear to be missing the contention made by me and others that
the
update description is not and should not be a simple repetition of
any
other content.
On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten p...@luyten.fr wrote:
Not sure if it makes any sense but maybe could we have something like
freeze tag changes until desc is better.
I propose this because testers will not _really_ want to -1 karma, and
as a maintainer it might be a bit
On Sat, Jun 29, 2013 at 2:44 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
There still seems to be an issue with the update descriptions that we
present in PackageKit. A lot of people just write update to version
x.y.z which is not great, but a whole lot better than some of the ones
On Fri, Jun 28, 2013 at 17:52:16 -0700,
Adam Williamson awill...@redhat.com wrote:
I've suggested before that Bodhi should reject any update with an
empty description or with the placeholder text as the description.
That would be really helpful.
I think it does now. I forgot to add a note
On Fri, Jun 28, 2013 at 07:44:22PM -0500, Michael Catanzaro wrote:
We need written policy on update descriptions, since despite the last
discussion on this list [1], poor update descriptions continue to
blemish the otherwise-professional image of the distro. A starting point
suggestion: Every
On Sat, 2013-06-29 at 07:34 -0500, Bruno Wolff III wrote:
On Fri, Jun 28, 2013 at 17:52:16 -0700,
Adam Williamson awill...@redhat.com wrote:
I've suggested before that Bodhi should reject any update with an
empty description or with the placeholder text as the description.
That would
On Sat, 2013-06-29 at 16:08 +0200, Till Maas wrote:
If the update fixes a bug which is properly mentioned in the bugs field,
why does this fact need to be mentioned again in the update notes? It
should be obvious that an update fixing a bug is worth pushing out.
Also instead of writing
On Sat, Jun 29, 2013 at 09:39:01 -0500,
Michael Catanzaro mike.catanz...@gmail.com wrote:
On Sat, 2013-06-29 at 07:34 -0500, Bruno Wolff III wrote:
On Fri, Jun 28, 2013 at 17:52:16 -0700,
Adam Williamson awill...@redhat.com wrote:
I've suggested before that Bodhi should reject any update
On Fri, 28 Jun 2013 19:44:22 -0500, Michael Catanzaro wrote:
There still seems to be an issue with the update descriptions that we
present in PackageKit. A lot of people just write update to version
x.y.z which is not great, but a whole lot better than some of the ones
we've been seeing
On 2013-06-29 7:08, Till Maas wrote:
On Fri, Jun 28, 2013 at 07:44:22PM -0500, Michael Catanzaro wrote:
We need written policy on update descriptions, since despite the last
discussion on this list [1], poor update descriptions continue to
blemish the otherwise-professional image of the
On 2013-06-29 10:04, Michael Schwendt wrote:
There are many more. Some are almost funny. I just hope we agree on
how to present Updates to the user community. No further comment.
OK, I propose a new rule: if you want to do a joke update description,
it has to be as funny as Spot's. If you
On Sat, Jun 29, 2013 at 1:07 PM, Adam Williamson awill...@redhat.com wrote:
I can't personally conceive of a case in which it would make sense to simply
have some kind of changelog as the update description. That is not what the
description is for.
Well, this is what I do for nodejs updates.
On Sat, Jun 29, 2013 at 8:10 AM, Bruno Wolff III br...@wolff.to wrote:
On Sat, Jun 29, 2013 at 09:39:01 -0500,
Michael Catanzaro mike.catanz...@gmail.com wrote:
On Sat, 2013-06-29 at 07:34 -0500, Bruno Wolff III wrote:
I think it does now. I forgot to add a note when rushing one of the
On Sat, Jun 29, 2013 at 01:07:29PM -0700, Adam Williamson wrote:
The upstream, RPM or git changelog is never a good update description.
An update description should be a very clear high-level description
of what the update does. The audience is a normal end-user who has
300 updates to apply
On 2013-06-29 14:20, Till Maas wrote:
On Sat, Jun 29, 2013 at 01:07:29PM -0700, Adam Williamson wrote:
The upstream, RPM or git changelog is never a good update description.
An update description should be a very clear high-level description
of what the update does. The audience is a normal
On 30/06/13 03:15, Adam Williamson wrote:
On 2013-06-29 14:20, Till Maas wrote:
On Sat, Jun 29, 2013 at 01:07:29PM -0700, Adam Williamson wrote:
The upstream, RPM or git changelog is never a good update description.
An update description should be a very clear high-level description
of what
There still seems to be an issue with the update descriptions that we
present in PackageKit. A lot of people just write update to version
x.y.z which is not great, but a whole lot better than some of the ones
we've been seeing recently. For example, from two updates I got today:
* Not tested
On 2013-06-28 17:44, Michael Catanzaro wrote:
There still seems to be an issue with the update descriptions that we
present in PackageKit. A lot of people just write update to version
x.y.z which is not great, but a whole lot better than some of the ones
we've been seeing recently. For example,
69 matches
Mail list logo
