- 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
On 03/12/2013 02:39 AM, Dan Mashal wrote:
Right because you do that for every single update you push?
For new upstream releases, I certainly try to.
Honestly, I'm done arguing my point. Other people in this thread have
made arguments for it, other people including yourself have made
On Mon, Mar 11, 2013 at 11:49 PM, Rahul Sundaram methe...@gmail.com wrote:
On 03/12/2013 02:39 AM, Dan Mashal wrote:
Right because you do that for every single update you push?
For new upstream releases, I certainly try to.
Honestly, I'm done arguing my point. Other people in this thread
On Mon, Mar 11, 2013 at 11:57:00PM -0700, Dan Mashal wrote:
I'm not doubting your technical skills. I'm making a few points.
b) sometimes you have a LOT of packages to push out.
c) sometimes even you yourself don't know what to put in the notes.
d) sometimes there's really not much else to
在 2013-3-12 PM3:03，Tomasz Torcz to...@pipebreaker.pl写道：
This sounds like updates that SHOULDN'T be pushed. If update has no
changes worth mentioning, it is trivial - trivial updates should not be
pushed.
If upstream release a minor bug fix version, what should we do?
--
devel mailing list
On Tue, 2013-03-12 at 15:14 +0800, Christopher Meng wrote:
在 2013-3-12 PM3:03，Tomasz Torcz to...@pipebreaker.pl写道：
This sounds like updates that SHOULDN'T be pushed. If update has no
changes worth mentioning, it is trivial - trivial updates should not be
pushed.
If upstream release a
On 03/12/2013 03:14 AM, Christopher Meng wrote:
在 2013-3-12 PM3:03，Tomasz Torcz 写道：
This sounds like updates that SHOULDN'T be pushed. If update has no
changes worth mentioning, it is trivial - trivial updates should not
be pushed.
If upstream release a minor bug fix version, what
On Tue, Mar 12, 2013 at 12:28 AM, Mathieu Bridon
boche...@fedoraproject.org wrote:
On Tue, 2013-03-12 at 15:14 +0800, Christopher Meng wrote:
在 2013-3-12 PM3:03，Tomasz Torcz to...@pipebreaker.pl写道：
This sounds like updates that SHOULDN'T be pushed. If update has no
changes worth
- Original Message -
Adam Williamson awill...@redhat.com writes:
On 11/03/13 06:28 PM, Toshio Kuratomi wrote:
That's not readily apparent in the Updates Policy ...
Ah, you're right, I really should have checked it before posting
(yet
again). I was thinking that it discouraged
- Original Message -
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 update. Users don't since it is different for
- Original Message -
On Mon, Mar 11, 2013 at 11:57:00PM -0700, Dan Mashal wrote:
I'm not doubting your technical skills. I'm making a few points.
b) sometimes you have a LOT of packages to push out.
c) sometimes even you yourself don't know what to put in the notes.
d)
On Tue, Mar 12, 2013 at 2:39 AM, Jaroslav Reznik jrez...@redhat.com wrote:
- Original Message -
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
On Tue, Mar 12, 2013 at 7:15 AM, Dan Mashal dan.mas...@gmail.com wrote:
On Tue, Mar 12, 2013 at 2:39 AM, Jaroslav Reznik jrez...@redhat.com wrote:
- Original Message -
On 03/12/2013 01:30 AM, Dan Mashal wrote:
Semantics.
Providing a link is helpful to users isn't semantics. You as
On Tue, 12 Mar 2013 07:29:03 -0700
Dan Mashal dan.mas...@gmail.com wrote:
On Tue, Mar 12, 2013 at 7:15 AM, Dan Mashal dan.mas...@gmail.com
wrote:
On Tue, Mar 12, 2013 at 2:39 AM, Jaroslav Reznik
jrez...@redhat.com wrote:
...snip...
Yep, I think the link, when available, is very
On Tue, Mar 12, 2013 at 7:58 AM, Kevin Fenzi ke...@scrye.com wrote:
On Tue, 12 Mar 2013 07:29:03 -0700
Dan Mashal dan.mas...@gmail.com wrote:
On Tue, Mar 12, 2013 at 7:15 AM, Dan Mashal dan.mas...@gmail.com
wrote:
On Tue, Mar 12, 2013 at 2:39 AM, Jaroslav Reznik
jrez...@redhat.com wrote:
On Tue, 12 Mar 2013 08:04:47 -0700
Dan Mashal dan.mas...@gmail.com wrote:
Agree to disagree. I care about compilation logs! :P
Sure, and they are there for you.
I doubt many people will say:
Hey, foobar-1.0 is updating to foobar-1.0.1, I should read the compile
logs to see whats changed.
Dan Mashal wrote:
On Mon, Mar 11, 2013 at 10:37 PM, Rahul Sundaram methe...@gmail.com
wrote:
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 update. Users don't since it is
Dan Mashal wrote:
Forget it. There is such a double standard here and exceptions to many
rules. This is a worthless conversation.
There are no exceptions. It's only because of lazy maintainers like you that
there's a double standard. Update notes are essential and MUST be filled in
in a way
On Tue, Mar 12, 2013 at 3:46 PM, Kevin Kofler kevin.kof...@chello.at wrote:
Dan Mashal wrote:
Forget it. There is such a double standard here and exceptions to many
rules. This is a worthless conversation.
There are no exceptions. It's only because of lazy maintainers like you that
there's a
On Tue, 2013-03-12 at 07:29 -0700, Dan Mashal wrote:
Bodhi never seemed like a tool to be informative. Just push out updates.
When I push an update I write a detailed, end-user friendly, verbose
explanation of why I'm doing it in the 'update description' field. I
think this is something people
Dan Mashal wrote:
Have bodhi grab it from the RPM change log spec file. Don't make
packager do more work than they already have to.
The RPM changelog is not the place to describe what upstream changed, the
Bodhi notes are.
Kevin Kofler
--
devel mailing list
What is the point of the RPM changelog then?
The last time I wanted to send a bodhi update, it gave me a transient file
that I filled in, and then my ssh key was rejected for some reason, and I
didn't have really want to deal with remembering what I wrote last time, so
I wrote new upstream
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.
The last time I wanted to send a bodhi update, it gave
On Tue, 2013-03-12 at 23:43 +0100, Kevin Kofler wrote:
No, it's a MUST. There's a reason Bodhi introduced that placeholder text, to
make it clear that empty update notes are NOT acceptable. Some maintainers
still don't get it. Just because you're too lazy to do it doesn't mean you
aren't
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 have filed a request on your behalf
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Perhaps the update policy should have a guideline on the minimum amount
of information required in this description. E.g. update to latest
upstream version might be a perfectly acceptable description for Fedora
On 11.03.2013 17:06, Jared K. Smith wrote:
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Perhaps the update policy should have a guideline on the minimum amount
of information required in this description. E.g. update to latest
upstream version might be a
Jared K. Smith jsm...@fedoraproject.org writes:
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Perhaps the update policy should have a guideline on the minimum amount
of information required in this description. E.g. update to latest
upstream version might
- Original Message -
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Perhaps the update policy should have a guideline on the minimum
amount
of information required in this description. E.g. update to latest
upstream version might be a
On Mon, 2013-03-11 at 12:06 -0400, Jared K. Smith wrote:
I tend to agree here. That being said, most of my package updates are
something along the lines of Update to upstream 2.5 release -- would
you find that descriptive enough, or still lacking in detail?
Personally I'd prefer some level
From: Jaroslav Reznik jrez...@redhat.com
- Original Message -
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Perhaps the update policy should have a guideline on the minimum
amount
of information required in this description. E.g. update
Hi
On Mon, Mar 11, 2013 at 1:49 PM, wrote:
It does seem that there's been a trend forming lately where the rpm's
changelog is covering only what's happened as far as the packaging itself
goes and less about the software being packaged. Maybe that's all the rpm
changelog should ever be?
On Mon, Mar 11, 2013 at 12:43:28PM -0400, Tom Lane wrote:
Jared K. Smith jsm...@fedoraproject.org writes:
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Perhaps the update policy should have a guideline on the minimum amount
of information required in
On 11/03/13 09:45 AM, Jaroslav Reznik wrote:
- Original Message -
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Perhaps the update policy should have a guideline on the minimum
amount
of information required in this description. E.g. update to
On 11/03/13 08:41 AM, Michael Catanzaro wrote:
Since switching to Fedora I've been noticing most Fedora stable updates
are released with a short, helpful description of the update, possibly
including a list of bugs fixed, just like in other major distros. But
unlike other major distros, other
On Mon, Mar 11, 2013 at 06:15:49PM -0700, Adam Williamson wrote:
At the very least, if you're doing an update for a stable release (so
okay, Branched is an exception here), you should have a clear reason
for doing it. You're not supposed to bump to the latest upstream
release just Because
On 11/03/13 06:28 PM, Toshio Kuratomi wrote:
On Mon, Mar 11, 2013 at 06:15:49PM -0700, Adam Williamson wrote:
At the very least, if you're doing an update for a stable release (so
okay, Branched is an exception here), you should have a clear reason
for doing it. You're not supposed to bump to
On Mon, Mar 11, 2013 at 4:12 PM, Richard W.M. Jones rjo...@redhat.com wrote:
On Mon, Mar 11, 2013 at 12:43:28PM -0400, Tom Lane wrote:
Jared K. Smith jsm...@fedoraproject.org writes:
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Perhaps the update
Adam Williamson awill...@redhat.com writes:
On 11/03/13 06:28 PM, Toshio Kuratomi wrote:
That's not readily apparent in the Updates Policy ...
Ah, you're right, I really should have checked it before posting (yet
again). I was thinking that it discouraged *all* version updates, not
just
On Mon, 2013-03-11 at 12:06 -0400, Jared K. Smith wrote:
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Perhaps the update policy should have a guideline on the minimum amount
of information required in this description. E.g. update to latest
upstream
On Mon, Mar 11, 2013 at 7:27 PM, Mathieu Bridon
boche...@fedoraproject.org wrote:
On Mon, 2013-03-11 at 12:06 -0400, Jared K. Smith wrote:
On Mon, Mar 11, 2013 at 11:41 AM, Michael Catanzaro
mike.catanz...@gmail.com wrote:
Perhaps the update policy should have a guideline on the minimum
Users who want to know the changelog mostly will go to homepage or github
like Dan said.
If some one even don't know upstream is what, I think changelog is useless
for him.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 03/11/2013 10:29 PM, Dan Mashal wrote:
For what though? You can google it and find it too.
You can google and install the software too but we don't make users do
that. What we provide for them is convenience and a direct link is a
good way to accomplish that.
And on minor release
On Mon, Mar 11, 2013 at 10:29 PM, Rahul Sundaram methe...@gmail.com wrote:
On 03/11/2013 10:29 PM, Dan Mashal wrote:
For what though? You can google it and find it too.
You can google and install the software too but we don't make users do that.
What we provide for them is convenience and a
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 update. Users don't since it is different for
different projects and is not
75 matches
Mail list logo
