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
- Original Message -
> On 03/14/2013 05:02 PM, Rahul Sundaram wrote:
> > On 03/14/2013 04:33 PM, Przemek Klosowski wrote:
> >>
> >> I didn't realize that my method was 'relying on the kindness of
> >> strangers' for including the relevant CVE data in the changelog,
> >> but
> >> it often gi
Jaroslav Reznik wrote:
> Take Fn-1 - it's almost dead, nearly nobody cares about it anymore
> (as bugfixes/backporting are costly), and I'd say with our ability
> to push security updates... It's non sense to have it as supported
> release.
That's a result of the karma system. Most people have jus
Debarshi Ray wrote:
> It is a bit strange that we freeze before the release, and then move
> on to a Rawhide like environment where anything can be pushed by
> anybody at any point in time.
And the answer to that is to find a way to drop or relax the release
freezes. (I'd suggest to have Bodhi di
Debarshi Ray wrote:
> It is interesting how you redefine the meaning of "First". At the DevConf
> you were blaming NetworkManager for breaking KDE when they changed API and
> KDE could not keep up, while GNOME did.
We cannot push new versions of a library when the users of the library are
not rea
On 03/14/2013 05:02 PM, Rahul Sundaram wrote:
On 03/14/2013 04:33 PM, Przemek Klosowski wrote:
I didn't realize that my method was 'relying on the kindness of
strangers' for including the relevant CVE data in the changelog, but
it often gives a quick, direct answer for the specific system you'r
> I see one problem with this approach: we're bound to have some update
> slipping into stable which breaks something that isn't caught in
> testing. If we do something like that, there needs to be a "fast lane"
> for updates fixing such broken updates so people don't have to wait a
> month for the
> "First even if broken" is a pretty extreme interpretation of "First".
>
> "First working" is much better - and it fits with the purpose of a
> distribution, to make sure that the various pieces are integrated
> together (and to help upstream make it happen if necessary).
There is no way you can
On 03/14/2013 04:33 PM, Przemek Klosowski wrote:
I didn't realize that my method was 'relying on the kindness of
strangers' for including the relevant CVE data in the changelog, but
it often gives a quick, direct answer for the specific system you're
on. If this was accidental rather than a p
On 03/14/2013 11:47 AM, Rahul Sundaram wrote:
On 03/14/2013 11:34 AM, Przemek Klosowski wrote:
Aah, wait a minute. I was tickled pink when I discovered that I can
look for vulnerability profile of a package by doing
rpm --changelog -q php | grep CVE
if RPM changelog is for packaging only this
On 14/03/13 08:34 AM, Przemek Klosowski wrote:
On 03/12/2013 09:42 PM, Rahul Sundaram wrote:
On 03/12/2013 08:17 PM, Jasper St. Pierre wrote:
What is the point of the RPM changelog then?
RPM changelog is for packaging changes. Bodhi update notes are for the
user. They are not merely redunda
On 03/14/2013 11:34 AM, Przemek Klosowski wrote:
Aah, wait a minute. I was tickled pink when I discovered that I can
look for vulnerability profile of a package by doing
rpm --changelog -q php | grep CVE
if RPM changelog is for packaging only this info wouldn't be there,
right? If so, what wo
On 03/12/2013 09:42 PM, Rahul Sundaram wrote:
On 03/12/2013 08:17 PM, Jasper St. Pierre wrote:
What is the point of the RPM changelog then?
RPM changelog is for packaging changes. Bodhi update notes are for the
user. They are not merely redundant copies of the same information.
Aah, wait a
On Thursday, March 14, 2013 10:24 PM, Michael Catanzaro wrote:
On Thu, 2013-03-14 at 03:41 -0700, Dan Mashal wrote:
How about we just drop support for 2 fedora releases to 1 and go on an
8 month cycle?
It's not that bad.
Dan
I think you'd find plenty of support for that idea iff GNOME switch
On Thu, 2013-03-14 at 03:41 -0700, Dan Mashal wrote:
>
> How about we just drop support for 2 fedora releases to 1 and go on an
> 8 month cycle?
>
> It's not that bad.
>
> Dan
I think you'd find plenty of support for that idea iff GNOME switched to
8 months as well.
signature.asc
Description:
On Wed, 2013-03-13 at 22:49 +0100, Kevin Kofler wrote:
> So did I, and I think his proposal is an awful idea. (Unfortunately,
> question time at DevConf is always very short, so I didn't get to voice my
> disapproval in the talk.) We are not Window$ (think "patch Tuesday") nor
> RHEL. We're a di
Dne 14.3.2013 10:43, Jaroslav Reznik napsal(a):
- Original Message -
unlike other major distros, other updates have less helpful
descriptions:
* "Update to latest upstream version"
* "No update information available"
* "Here is where you give an explanation of your update. Here is
where
On Thu, Mar 14, 2013 at 11:53 AM, Debarshi Ray wrote:
>> RHEL. We're a distribution with "First" as one of its main objectives. Our
>> users do not want to wait up to a month for updates!
>
> It is interesting how you redefine the meaning of "First". At the DevConf you
> were blaming NetworkManage
On Wed, 2013-03-13 at 14:26 -0600, Kevin Fenzi wrote:
> On Wed, 13 Mar 2013 20:20:01 +
> Debarshi Ray wrote:
>
> ...snip...
>
> > I think it would be a much better use of our time to audit and test
> > updates than writing %changelogs that can be understood by laymen.
>
> Spot had a plan re
> RHEL. We're a distribution with "First" as one of its main objectives. Our
> users do not want to wait up to a month for updates!
It is interesting how you redefine the meaning of "First". At the DevConf you
were blaming NetworkManager for breaking KDE when they changed API and KDE
could not ke
On Thu, Mar 14, 2013 at 2:43 AM, Jaroslav Reznik wrote:
> - Original Message -
>> > unlike other major distros, other updates have less helpful
>> > descriptions:
>> >
>> > * "Update to latest upstream version"
>> > * "No update information available"
>> > * "Here is where you give an expl
On 14/03/13 02:43 AM, Jaroslav Reznik wrote:
That's more problem of how we treat our stable releases.
Take Fn-1 - it's almost dead, nearly nobody cares about it anymore
(as bugfixes/backporting are costly), and I'd say with our ability
to push security updates... It's non sense to have it as su
- Original Message -
> > unlike other major distros, other updates have less helpful
> > descriptions:
> >
> > * "Update to latest upstream version"
> > * "No update information available"
> > * "Here is where you give an explanation of your update. Here is
> > where
> > you give an explan
Debarshi Ray wrote:
> Yes, I attended his talk at devconf.cz where he mentioned this. :-)
So did I, and I think his proposal is an awful idea. (Unfortunately,
question time at DevConf is always very short, so I didn't get to voice my
disapproval in the talk.) We are not Window$ (think "patch Tue
>> I think it would be a much better use of our time to audit and test
>> updates than writing %changelogs that can be understood by laymen.
>
> Spot had a plan related to this. basically bundle up monthly updates to
> all critpath (non security) stuff, QA it, and then push it out as a
> bundle.
On Wed, 13 Mar 2013 20:20:01 +
Debarshi Ray wrote:
...snip...
> I think it would be a much better use of our time to audit and test
> updates than writing %changelogs that can be understood by laymen.
Spot had a plan related to this. basically bundle up monthly updates to
all critpath (non
> unlike other major distros, other updates have less helpful
> descriptions:
>
> * "Update to latest upstream version"
> * "No update information available"
> * "Here is where you give an explanation of your update. Here is where
> you give an explanation of your update."
>
> Perhaps the update
On Tue, 2013-03-12 at 22:29 -0400, Rahul Sundaram wrote:
> On 03/12/2013 10:18 PM, Michael Catanzaro wrote:
>
> > Again, I'm disappointed in seeing that placeholder text in stable
> > updates. Clearly that plan failed---it'd be nice if Bodhi could become
> > smart enough to reject updates with the
On Mon, 2013-03-11 at 18:20 -0700, Adam Williamson wrote:
>
> The discussion seems to have branched out a bit, but going back to
> Michael's original mail, he's clearly onto something. It should not be
> too hard for Bodhi to reject:
>
> * Entirely empty update descriptions
> * An update descri
- Original Message -
>
>
> On 03/12/2013 10:18 PM, Michael Catanzaro wrote:
>
>
> Again, I'm disappointed in seeing that placeholder text in stable
> updates. Clearly that plan failed---it'd be nice if Bodhi could
> become
> smart enough to reject updates with the placeholder descriptio
1 - 100 of 147 matches
Mail list logo
