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,
- 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 gives a quick,
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 ready
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
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 just
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
- 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 explanation of your
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
On Thu, Mar 14, 2013 at 2:43 AM, Jaroslav Reznik jrez...@redhat.com 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
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 keep
On Wed, 2013-03-13 at 14:26 -0600, Kevin Fenzi wrote:
On Wed, 13 Mar 2013 20:20:01 +
Debarshi Ray rishi...@lostca.se 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
On Thu, Mar 14, 2013 at 11:53 AM, Debarshi Ray rishi...@lostca.se 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
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
you
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
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: This
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
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
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
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
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 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
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 test a
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 fix.
From: Rahul Sundaram methe...@gmail.com
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.
I see both
- 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 description.
I
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 description
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
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 policy should
On Wed, 13 Mar 2013 20:20:01 +
Debarshi Ray rishi...@lostca.se 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
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.
Yes, I
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
On Mon, Mar 11, 2013 at 10:37 PM, Rahul Sundaram methe...@gmail.com wrote:
On 03/12/2013 01:30 AM, Dan Mashal wrote:
Semantics.
Providing a link is helpful to users isn't semantics. You as a package
maintainer would be aware of where to look for reviewing the changes before
pushing an
1 - 100 of 145 matches
Mail list logo
