On 6/29/13, T.C. Hollingsworth > 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 proper information ever
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
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 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:
http://bochecha.fedorap
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 ☁☁☁
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.
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
update
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 cas
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
https://build.opensuse.org/package/view_file/openSUSE:Factory/evolution?expan
On 3 July 2013 20:48, Adam Williamson 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 and fixes neit
On Wed, 03 Jul 2013 12:55:11 -0700
Adam Williamson 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 and *does* fix so
On 2013-07-03 10:54, Kevin Fenzi wrote:
On Wed, 03 Jul 2013 19:38:00 +0200
Reindl Harald 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
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 -g
And, I suppose:
%changelog -s
%changelog -c
%changelog -m
%changelog -h
%ch
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 o
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 m
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 :
https://fedoraproject.org/wiki/QA:Up
On Wed, Jul 3, 2013 at 7:54 PM, Kevin Fenzi wrote:
> On Wed, 03 Jul 2013 19:38:00 +0200
> Reindl Harald 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
Am 03.07.2013 19:54, schrieb Kevin Fenzi:
> On Wed, 03 Jul 2013 19:38:00 +0200
> Reindl Harald 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 sense for me
>
>
On Wed, 03 Jul 2013 19:38:00 +0200
Reindl Harald 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
> >> since when
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
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 ☁☁☁
--
devel mail
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
ht
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 -g
> >>
> >>And, I suppose:
> >>
> >>%changelog -
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 -g
And, I suppose:
%changelog -s
%changelog -c
%changelog -m
%changelog -h
%changelog -a
%changelog -b
No. Just imple
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 b
On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote:
> Richard W.M. Jones wrote:
> > %changelog -f
> > %changelog -g
>
> And, I suppose:
>
> %changelog -s
> %changelog -c
> %changelog -m
> %changelog -h
> %changelog -a
> %changelog -b
No. Just implementing -f (local file) solv
On 3 July 2013 08:47, Michael Scherer wrote:
> Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit :
>>
>>
>>
>> On Wed, Jul 3, 2013 at 9:32 AM, drago01 wrote:
>> On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
>> wrote:
>> > On Mon, Jul 1, 2013 at 2:52 PM, Pierr
Le mercredi 03 juillet 2013 à 09:54 +0200, Johannes Lips a écrit :
>
>
>
> On Wed, Jul 3, 2013 at 9:47 AM, Michael Scherer wrote:
> Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a
> écrit :
> >
> >
> >
> > On Wed, Jul 3, 2013 at 9:32 AM
On Wed, Jul 3, 2013 at 9:47 AM, Michael Scherer wrote:
> Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit :
> >
> >
> >
> > On Wed, Jul 3, 2013 at 9:32 AM, drago01 wrote:
> > On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
> > wrote:
> > > On Mon, Jul 1, 2013
Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit :
>
>
>
> On Wed, Jul 3, 2013 at 9:32 AM, drago01 wrote:
> On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
> wrote:
> > On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten
> wrote:
> >> Not sur
On Wed, Jul 3, 2013 at 9:32 AM, drago01 wrote:
> On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal wrote:
> > On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten wrote:
> >> Not sure if it makes any sense but maybe could we have something like
> >> "freeze tag changes until desc is better".
> >>
> >>
On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal wrote:
> On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten 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 k
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
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 te
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 repe
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 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 ev
Richard W.M. Jones wrote:
> %changelog -f
> %changelog -g
And, I suppose:
%changelog -s
%changelog -c
%changelog -m
%changelog -h
%changelog -a
%changelog -b
... and so on, right? And every time someone comes up with a new version
control system, RPM would grow support for a new protocol
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).
> >
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
"T
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
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 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, an
On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten 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 hard, but wi
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
> > ot
On Mon, Jul 1, 2013 at 2:41 PM, Björn Persson
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 changelogs and release
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 dupl
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
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 ap
On Mon, Jul 01, 2013 at 02:01:29PM -0500, Michael Catanzaro wrote:
> And as far as the tooling is concerned... this is the matter of writing
> just one extra sentence, so even if we did have awesome technology to
> write the update description for you from the RPM changelog, and even if
> it was c
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 n
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 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 i
On Mon, Jul 1, 2013 at 6:44 AM, Richard W.M. Jones 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 in mult
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
* 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
devel@lists.fedoraproje
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. *
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://
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 descrip
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 en
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 a
On Sat, Jun 29, 2013 at 8:10 AM, Bruno Wolff III wrote:
> On Sat, Jun 29, 2013 at 09:39:01 -0500,
> Michael Catanzaro 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
>>> spin-kickstarts updates and bodhi
On Sat, Jun 29, 2013 at 1:07 PM, Adam Williamson 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. I figure since th
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 can
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 distro.
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 Sat, Jun 29, 2013 at 09:39:01 -0500,
Michael Catanzaro 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 wrote:
>
>I've suggested before that Bodhi should reject any update with an
>empty description or with the pla
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 p
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 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 h
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: "E
On Fri, Jun 28, 2013 at 17:52:16 -0700,
Adam Williamson 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 when rushing one of
On Sat, Jun 29, 2013 at 2:44 AM, 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 rec
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,
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 lo
71 matches
Mail list logo
