3:53 p.m.
Dear Fedora developers,
there have been a number of examples where an update in a stable branch
brought in new dependencies and in significant numbers. The most recent
case was discussed on this list even today:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
I opened a ticket with FESCo to clarify the Updates Policy:
https://pagure.io/fesco/issue/1682
In particular, I propose:
* Mandating that all dependency changes in package updates must be
mentioned in the package's %changelog and justified.
* Mandating that all dependency changes in package updates in a stable
release MUST be mentioned in bodhi update release notes and justified.
* Adding this to https://fedoraproject.org/wiki/Updates_Policy#All_other_updates
* Avoid updates that introduce any new dependencies
Thoughts?
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:08 p.m.
On Wed, 2017-02-22 at 22:53 +0100, Dominik 'Rathann' Mierzejewski
wrote:
Dear Fedora developers,
there have been a number of examples where an update in a stable branch
brought in new dependencies and in significant numbers. The most recent
case was discussed on this list even today:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
That discussion was about Rawhide. Not about a stable release.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:23 p.m.
On Thursday, 23 February 2017 at 00:08, Adam Williamson wrote:
On Wed, 2017-02-22 at 22:53 +0100, Dominik 'Rathann'
Mierzejewski
wrote:
> Dear Fedora developers,
> there have been a number of examples where an update in a stable branch
> brought in new dependencies and in significant numbers. The most recent
> case was discussed on this list even today:
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
That discussion was about Rawhide. Not about a stable release.
True, but the issue is the same. New or changed dependencies cause
problems.
The proposed policy change talks about both rawhide and stable branches.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
12:16 a.m.
On 02/23/2017 02:23 AM, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 23 February 2017 at 00:08, Adam Williamson wrote:
> On Wed, 2017-02-22 at 22:53 +0100, Dominik 'Rathann' Mierzejewski
> wrote:
>> Dear Fedora developers,
>> there have been a number of examples where an update in a stable branch
>> brought in new dependencies and in significant numbers. The most recent
>> case was discussed on this list even today:
>>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
> That discussion was about Rawhide. Not about a stable release.
True, but the issue is the same. New or changed dependencies cause
problems.
Not quite. This only applies to "weak deps".
New "strong deps" or "changed deps" are should to solve problems,
otherwise there would not be any need for changes.
The proposed policy change talks about both rawhide and stable
branches.
I consider your proposal to be unnecessary.
Ralf
6:33 a.m.
On Thursday, 23 February 2017 at 07:16, Ralf Corsepius wrote:
On 02/23/2017 02:23 AM, Dominik 'Rathann' Mierzejewski
wrote:
> On Thursday, 23 February 2017 at 00:08, Adam Williamson wrote:
> > On Wed, 2017-02-22 at 22:53 +0100, Dominik 'Rathann' Mierzejewski
> > wrote:
> > > Dear Fedora developers,
> > > there have been a number of examples where an update in a stable branch
> > > brought in new dependencies and in significant numbers. The most recent
> > > case was discussed on this list even today:
> > >
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
> >
> > That discussion was about Rawhide. Not about a stable release.
>
> True, but the issue is the same. New or changed dependencies cause
> problems.
Not quite. This only applies to "weak deps".
How so?
New "strong deps" or "changed deps" are should to
solve problems, otherwise
there would not be any need for changes.
"are should to"? Sorry, I can't understand the above sentence.
> The proposed policy change talks about both rawhide and stable
branches.
I consider your proposal to be unnecessary.
Could you elaborate on why you think it's unnecessary?
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
7:23 a.m.
On Thu, Feb 23, 2017 at 7:33 AM, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
On Thursday, 23 February 2017 at 07:16, Ralf Corsepius wrote:
> On 02/23/2017 02:23 AM, Dominik 'Rathann' Mierzejewski wrote:
> > On Thursday, 23 February 2017 at 00:08, Adam Williamson wrote:
> > > On Wed, 2017-02-22 at 22:53 +0100, Dominik 'Rathann' Mierzejewski
> > > wrote:
> > > > Dear Fedora developers,
> > > > there have been a number of examples where an update in a stable
branch
> > > > brought in new dependencies and in significant numbers. The most
recent
> > > > case was discussed on this list even today:
> > > >
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
> > >
> > > That discussion was about Rawhide. Not about a stable release.
> >
> > True, but the issue is the same. New or changed dependencies cause
> > problems.
>
> Not quite. This only applies to "weak deps".
How so?
> New "strong deps" or "changed deps" are should to solve problems,
otherwise
> there would not be any need for changes.
"are should to"? Sorry, I can't understand the above sentence.
> > The proposed policy change talks about both rawhide and stable branches.
> I consider your proposal to be unnecessary.
Could you elaborate on why you think it's unnecessary?
This proposal is rather burdensome with no particular gain.
Firstly, this proposal assumes we work in a vacuum, which we don't.
Most of the important packages are maintained by teams or SIGs/WGs.
They often are also involved in the upstream development in some
fashion and are already aware of changes anyway and can handle dealing
with the changes.
Secondly, with the exception of a few packages, largely relating to
the installer stack; the security stack; and the system startup
packages, the addition and removal of dependencies generally does not
matter. And in the cases where it does, all the stakeholders are
*already* involved and working on it together.
Thirdly, there's no particular problem you're trying to solve, and
forcing people to do this means that people are going to be more
anxious and less willing to actually update software, which is counter
to our goal to provide the latest and greatest software to our users.
Frankly, the only reason this is even a problem at all is because we
have the split between packager and provenpackager. As far as I am
aware, every team or SIG/WG has at least one or two provenpackagers,
so this is usually not a problem.
--
真実はいつも一つ！/ Always, there's only one truth!
8:06 a.m.
On 02/23/2017 02:23 PM, Neal Gompa wrote:
On Thu, Feb 23, 2017 at 7:33 AM, Dominik 'Rathann'
Mierzejewski
<dominik(a)greysector.net> wrote:
> On Thursday, 23 February 2017 at 07:16, Ralf Corsepius wrote:
>> On 02/23/2017 02:23 AM, Dominik 'Rathann' Mierzejewski wrote:
>>> On Thursday, 23 February 2017 at 00:08, Adam Williamson wrote:
>>>> On Wed, 2017-02-22 at 22:53 +0100, Dominik 'Rathann'
Mierzejewski
>>>> wrote:
>>>>> Dear Fedora developers,
>>>>> there have been a number of examples where an update in a stable
branch
>>>>> brought in new dependencies and in significant numbers. The most
recent
>>>>> case was discussed on this list even today:
>>>>>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>>>>
>>>> That discussion was about Rawhide. Not about a stable release.
>>>
>>> True, but the issue is the same. New or changed dependencies cause
>>> problems.
>>
>> Not quite. This only applies to "weak deps".
>
> How so?
>
>> New "strong deps" or "changed deps" are should to solve
problems, otherwise
>> there would not be any need for changes.
>
> "are should to"? Sorry, I can't understand the above sentence.
This was a typo. This should have been:
"New or changed strong deps are supposed to/should solve problems", ...
I.e. new or changed "strong deps" are bug-fixes.
"Weak deps" are a different story. Adding/removing/changing them are
mostly personal preference of a packager. They can cause harm.
>>> The proposed policy change talks about both rawhide and
stable branches.
>> I consider your proposal to be unnecessary.
>
> Could you elaborate on why you think it's unnecessary?
>
This proposal is rather burdensome with no particular gain.
Exactly. This is a good sentence to summarize what I had wanted to express.
Ralf
11:24 a.m.
On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
On Thu, Feb 23, 2017 at 7:33 AM, Dominik 'Rathann'
Mierzejewski
<dominik(a)greysector.net> wrote:
> On Thursday, 23 February 2017 at 07:16, Ralf Corsepius wrote:
>> On 02/23/2017 02:23 AM, Dominik 'Rathann' Mierzejewski wrote:
>> > On Thursday, 23 February 2017 at 00:08, Adam Williamson wrote:
>> > > On Wed, 2017-02-22 at 22:53 +0100, Dominik 'Rathann'
Mierzejewski
>> > > wrote:
>> > > > Dear Fedora developers,
>> > > > there have been a number of examples where an update in a stable
branch
>> > > > brought in new dependencies and in significant numbers. The most
recent
>> > > > case was discussed on this list even today:
>> > > >
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>> > >
>> > > That discussion was about Rawhide. Not about a stable release.
>> >
>> > True, but the issue is the same. New or changed dependencies cause
>> > problems.
>>
>> Not quite. This only applies to "weak deps".
>
> How so?
>
>> New "strong deps" or "changed deps" are should to solve
problems, otherwise
>> there would not be any need for changes.
>
> "are should to"? Sorry, I can't understand the above sentence.
>
>> > The proposed policy change talks about both rawhide and stable branches.
>> I consider your proposal to be unnecessary.
>
> Could you elaborate on why you think it's unnecessary?
This proposal is rather burdensome with no particular gain.
I disagree. The gain is that packagers will be more mindful of the how
the changes they introduce affect the rest of Fedora and that users
don't have to search far and wide for an explanation of the new/changed
dependencies.
Firstly, this proposal assumes we work in a vacuum, which we
don't.
I have no idea where you draw such conclusion from.
Most of the important packages are maintained by teams or SIGs/WGs.
They often are also involved in the upstream development in some
fashion and are already aware of changes anyway and can handle dealing
with the changes.
How about the users? Shouldn't they be made aware of the changes, too?
Or are you suggesting they don't need to know?
Secondly, with the exception of a few packages, largely relating to
the installer stack; the security stack; and the system startup
packages, the addition and removal of dependencies generally does not
matter.
I agree that removal is of less concern, but I disagree on additions.
Increasing on-disk and in-memory footprint doesn't matter? Adding
potentially vulnerable code doesn't matter?
And in the cases where it does, all the stakeholders are
*already* involved and working on it together.
Again, what about the users? I think they shouldn't be forced to do an
exhaustive search to find out why they suddenly need to install 5, 10
or 50 additional packages along with an update. Such information
should be readily available and in many cases it isn't.
Thirdly, there's no particular problem you're trying to
solve,
Again, that's not true. I listed the reasons both in the ticket
and in this thread. Are you saying they don't matter at all?
and forcing people to do this means that people are going to be more
anxious and less willing to actually update software, which is counter
to our goal to provide the latest and greatest software to our users.
I have nothing against delivering latest and greatest software to our
users and this proposal is not against that goal, either. However,
package maintainers are not supposed to simply take what upstream
releases and pass it on to the users without considering the impact.
I'm not saying most of them do so. However, I encountered enough cases
when this was done without any documented justification that I think
it's necessary to mandate such justifications. Who knows how many cases
I didn't catch. This is doubly important in stable Fedora branches.
If this proposal makes maintainers think before updating something to
the latest and greatest in a stable branch with just a few months of
life left, then I consider that a very good thing.
Frankly, the only reason this is even a problem at all is because we
have the split between packager and provenpackager. As far as I am
aware, every team or SIG/WG has at least one or two provenpackagers,
so this is usually not a problem.
I don't see how the above is relevant to the topic.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
7:48 a.m.
On 23 February 2017 at 12:24, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
I have nothing against delivering latest and greatest software to
our
users and this proposal is not against that goal, either. However,
package maintainers are not supposed to simply take what upstream
releases and pass it on to the users without considering the impact.
I think that may be the differing of opinions in this discussion as I
don't think there is a definitive answer. Some packagers believe that
whatever upstream requires to get the software is what happens, other
packagers believe that it isn't. Many packagers just want the XYZ
package to be there so they can build the thing they really care about
so if the upstream needed ten new dependencies.. we add 10 new
dependencies.
You may want to focus on this contention and see if there can be a
consensus built around which way the project wants to go with it. Then
work out the policies to meet whatever consensus is. Doing it
backwards just leads to quibling because no one agrees with each
other.
I'm not saying most of them do so. However, I encountered enough
cases
when this was done without any documented justification that I think
it's necessary to mandate such justifications. Who knows how many cases
I didn't catch. This is doubly important in stable Fedora branches.
If this proposal makes maintainers think before updating something to
the latest and greatest in a stable branch with just a few months of
life left, then I consider that a very good thing.
--
Stephen J Smoogen.
8:31 a.m.
On Fri, Feb 24, 2017 at 08:48:43AM -0500, Stephen John Smoogen wrote:
On 23 February 2017 at 12:24, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
> On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
> I have nothing against delivering latest and greatest software to our
> users and this proposal is not against that goal, either. However,
> package maintainers are not supposed to simply take what upstream
> releases and pass it on to the users without considering the impact.
I think that may be the differing of opinions in this discussion as I
don't think there is a definitive answer. Some packagers believe that
whatever upstream requires to get the software is what happens, other
packagers believe that it isn't. Many packagers just want the XYZ
package to be there so they can build the thing they really care about
so if the upstream needed ten new dependencies.. we add 10 new
dependencies.
Upstream may not allow packagers to have any viable choices. If upstream
has added a new dependancy, there's no guarantee it is optional. So if the
new version is required in Fedora, then often there's no choice but to
accept the new dependancy. The alternative is to be stuck on the old
(possibly insecure) version forever, or fork the code, neither of which
are really acceptable options. Even if the dependancy is optional, disabling
it may cause Fedora to loose functionality vs the previously packaged
version, so it is in effect mandatory.
Any rules about adding new dependencies in Fedora will quickly come up
against these hard realities, when dealing with new upstream versions.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
9:24 a.m.
On Friday, 24 February 2017 at 15:31, Daniel P. Berrange wrote:
On Fri, Feb 24, 2017 at 08:48:43AM -0500, Stephen John Smoogen
wrote:
> On 23 February 2017 at 12:24, Dominik 'Rathann' Mierzejewski
> <dominik(a)greysector.net> wrote:
> > On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
>
> > I have nothing against delivering latest and greatest software to our
> > users and this proposal is not against that goal, either. However,
> > package maintainers are not supposed to simply take what upstream
> > releases and pass it on to the users without considering the impact.
>
> I think that may be the differing of opinions in this discussion as I
> don't think there is a definitive answer. Some packagers believe that
> whatever upstream requires to get the software is what happens, other
> packagers believe that it isn't. Many packagers just want the XYZ
> package to be there so they can build the thing they really care about
> so if the upstream needed ten new dependencies.. we add 10 new
> dependencies.
And that's fine. Just don't make me jump through hoops to find out why.
One sentence in the changelog or a pointer to upstream release notes is
all I'm asking for. That and a little bit of consideration if such an
update is really necessary in a stable release. Surely that's not much
to ask. Or is it?
Upstream may not allow packagers to have any viable choices. If
upstream
has added a new dependancy, there's no guarantee it is optional. So if the
new version is required in Fedora, then often there's no choice but to
accept the new dependancy. The alternative is to be stuck on the old
(possibly insecure) version forever, or fork the code, neither of which
are really acceptable options. Even if the dependancy is optional, disabling
it may cause Fedora to loose functionality vs the previously packaged
version, so it is in effect mandatory.
Any rules about adding new dependencies in Fedora will quickly come up
against these hard realities, when dealing with new upstream versions.
You both sound as if you're thinking I'm totally against introducing new
dependencies.
I'm not. I'd just like to be informed when they appear. I'm convinced
this information would be useful not only to me, but also to others.
Hence my proposal to include justification (a pointer to upstream release
notes is fine as one) for them.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:19 a.m.
On 24 February 2017 at 10:24, Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
On Friday, 24 February 2017 at 15:31, Daniel P. Berrange wrote:
> On Fri, Feb 24, 2017 at 08:48:43AM -0500, Stephen John Smoogen wrote:
> > On 23 February 2017 at 12:24, Dominik 'Rathann' Mierzejewski
> > <dominik(a)greysector.net> wrote:
> > > On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
> >
> > > I have nothing against delivering latest and greatest software to our
> > > users and this proposal is not against that goal, either. However,
> > > package maintainers are not supposed to simply take what upstream
> > > releases and pass it on to the users without considering the impact.
> >
> > I think that may be the differing of opinions in this discussion as I
> > don't think there is a definitive answer. Some packagers believe that
> > whatever upstream requires to get the software is what happens, other
> > packagers believe that it isn't. Many packagers just want the XYZ
> > package to be there so they can build the thing they really care about
> > so if the upstream needed ten new dependencies.. we add 10 new
> > dependencies.
And that's fine. Just don't make me jump through hoops to find out why.
One sentence in the changelog or a pointer to upstream release notes is
all I'm asking for. That and a little bit of consideration if such an
update is really necessary in a stable release. Surely that's not much
to ask. Or is it?
> Upstream may not allow packagers to have any viable choices. If upstream
> has added a new dependancy, there's no guarantee it is optional. So if the
> new version is required in Fedora, then often there's no choice but to
> accept the new dependancy. The alternative is to be stuck on the old
> (possibly insecure) version forever, or fork the code, neither of which
> are really acceptable options. Even if the dependancy is optional, disabling
> it may cause Fedora to loose functionality vs the previously packaged
> version, so it is in effect mandatory.
>
> Any rules about adding new dependencies in Fedora will quickly come up
> against these hard realities, when dealing with new upstream versions.
You both sound as if you're thinking I'm totally against introducing new
dependencies.
No. I didn't take that to be your view at all. I am going more with
the fact that you ran into a wall, and then you decided to smash your
head into the wall 3 times without asking "why is there this wall?
what am I missing"
I'm not. I'd just like to be informed when they appear. I'm convinced
this information would be useful not only to me, but also to others.
Hence my proposal to include justification (a pointer to upstream release
notes is fine as one) for them.
Mostly to me it is that what you are going to see is:
===
No f'ing clue why, but upstream wants /bin/foo now.
===
Because that fits the spirit of the law at 2am when someone is fixing
some package. At which point you start adding in, packager needs to
give a reasoned explanation of why upstream wants it and we need
someone to audit that those changes are put in place (because they
won't be) and what the consequences of them not being there is to be.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
10:28 a.m.
On 24 February 2017 at 11:19, Stephen John Smoogen <smooge(a)gmail.com> wrote:
> You both sound as if you're thinking I'm totally against
introducing new
> dependencies.
No. I didn't take that to be your view at all. I am going more with
the fact that you ran into a wall, and then you decided to smash your
head into the wall 3 times without asking "why is there this wall?
what am I missing"
And I sent that off without thinking how my words sounded. They were
rude and not helpful in this conversation. I apologize.
--
Stephen J Smoogen.
10:42 a.m.
On Friday, 24 February 2017 at 17:28, Stephen John Smoogen wrote:
On 24 February 2017 at 11:19, Stephen John Smoogen
<smooge(a)gmail.com> wrote:
>> You both sound as if you're thinking I'm totally against introducing
new
>> dependencies.
>
> No. I didn't take that to be your view at all. I am going more with
> the fact that you ran into a wall, and then you decided to smash your
> head into the wall 3 times without asking "why is there this wall?
> what am I missing"
>
And I sent that off without thinking how my words sounded. They were
rude and not helpful in this conversation. I apologize.
No need. What you wrote is a good approximation of how I feel and
it made me smile.
Thank you very much for trying to explain "the wall" to me.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
10:51 a.m.
On Fri, Feb 24, 2017 at 04:24:16PM +0100, Dominik 'Rathann' Mierzejewski wrote:
On Friday, 24 February 2017 at 15:31, Daniel P. Berrange wrote:
> On Fri, Feb 24, 2017 at 08:48:43AM -0500, Stephen John Smoogen wrote:
> > On 23 February 2017 at 12:24, Dominik 'Rathann' Mierzejewski
> > <dominik(a)greysector.net> wrote:
> > > On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
> >
> > > I have nothing against delivering latest and greatest software to our
> > > users and this proposal is not against that goal, either. However,
> > > package maintainers are not supposed to simply take what upstream
> > > releases and pass it on to the users without considering the impact.
> >
> > I think that may be the differing of opinions in this discussion as I
> > don't think there is a definitive answer. Some packagers believe that
> > whatever upstream requires to get the software is what happens, other
> > packagers believe that it isn't. Many packagers just want the XYZ
> > package to be there so they can build the thing they really care about
> > so if the upstream needed ten new dependencies.. we add 10 new
> > dependencies.
And that's fine. Just don't make me jump through hoops to find out why.
One sentence in the changelog or a pointer to upstream release notes is
all I'm asking for. That and a little bit of consideration if such an
update is really necessary in a stable release. Surely that's not much
to ask. Or is it?
I question how useful that is going to be in practice. Realistically the
RPM changelog is going to say little more than
"Added new dependancy libfoo.so"
which isn't really adding any value IMHO. Explaining why a dependancy was
added is useful, but that needs packagers to potentally understand the
upstream app decision in significant detail, and such an explanation is
often not simple enough to explain in a useful level of detail in an
RPM changelog. Unless you want long paragraphs of text in the RPM changelog
which IMHO would not be appropriate.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
9:05 p.m.
On Fri, Feb 24, 2017 at 04:51:42PM +0000, Daniel P. Berrange wrote:
On Fri, Feb 24, 2017 at 04:24:16PM +0100, Dominik 'Rathann'
Mierzejewski wrote:
> On Friday, 24 February 2017 at 15:31, Daniel P. Berrange wrote:
> > On Fri, Feb 24, 2017 at 08:48:43AM -0500, Stephen John Smoogen wrote:
> > > On 23 February 2017 at 12:24, Dominik 'Rathann' Mierzejewski
> > > <dominik(a)greysector.net> wrote:
> > > > On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
> > >
> > > > I have nothing against delivering latest and greatest software to
our
> > > > users and this proposal is not against that goal, either. However,
> > > > package maintainers are not supposed to simply take what upstream
> > > > releases and pass it on to the users without considering the impact.
> > >
> > > I think that may be the differing of opinions in this discussion as I
> > > don't think there is a definitive answer. Some packagers believe that
> > > whatever upstream requires to get the software is what happens, other
> > > packagers believe that it isn't. Many packagers just want the XYZ
> > > package to be there so they can build the thing they really care about
> > > so if the upstream needed ten new dependencies.. we add 10 new
> > > dependencies.
>
> And that's fine. Just don't make me jump through hoops to find out why.
> One sentence in the changelog or a pointer to upstream release notes is
> all I'm asking for. That and a little bit of consideration if such an
> update is really necessary in a stable release. Surely that's not much
> to ask. Or is it?
I question how useful that is going to be in practice. Realistically the
RPM changelog is going to say little more than
"Added new dependancy libfoo.so"
which isn't really adding any value IMHO. Explaining why a dependancy was
added is useful, but that needs packagers to potentally understand the
upstream app decision in significant detail, and such an explanation is
often not simple enough to explain in a useful level of detail in an
RPM changelog. Unless you want long paragraphs of text in the RPM changelog
which IMHO would not be appropriate.
I think the opposite might also be true (I guess it depends on the
package), where it's fairly obvious to anyone concerned, i.e. both
packagers and users, why a dependency is added. E.g. I recently added
enjarify as dependency of diffoscope, with the update message "Add
newly packaged enjarify as diffoscope dep". If you know what difoscope
does, it should be pretty clear that this adds support for one more
archive type. And if tar suddenly grows a dep on liblz4 or libsnappy
or whatever, I wouldn't expend more than a few words.
That said, legible high-level update notes are a thing we should be
striving for in general.
Zbyszek
12:15 p.m.
On Wed, Feb 22, 2017 at 10:53:01PM +0100, Dominik 'Rathann' Mierzejewski wrote:
Dear Fedora developers,
there have been a number of examples where an update in a stable branch
brought in new dependencies and in significant numbers. The most recent
case was discussed on this list even today:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
I opened a ticket with FESCo to clarify the Updates Policy:
https://pagure.io/fesco/issue/1682
In particular, I propose:
* Mandating that all dependency changes in package updates must be
mentioned in the package's %changelog and justified.
* Mandating that all dependency changes in package updates in a stable
release MUST be mentioned in bodhi update release notes and justified.
Why does the packager have to do this, when bodhi itself could read
the before/after dependencies and fill in those details?
Rich.
* Adding this to
https://fedoraproject.org/wiki/Updates_Policy#All_other_updates
* Avoid updates that introduce any new dependencies
Thoughts?
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
12:21 p.m.
On Mon, 27 Feb 2017 18:15:32 +0000
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
On Wed, Feb 22, 2017 at 10:53:01PM +0100, Dominik 'Rathann'
Mierzejewski wrote:
> Dear Fedora developers,
> there have been a number of examples where an update in a stable
> branch brought in new dependencies and in significant numbers. The
> most recent case was discussed on this list even today:
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
> I opened a ticket with FESCo to clarify the Updates Policy:
> https://pagure.io/fesco/issue/1682
>
> In particular, I propose:
> * Mandating that all dependency changes in package updates must be
> mentioned in the package's %changelog and justified.
>
> * Mandating that all dependency changes in package updates in a
> stable release MUST be mentioned in bodhi update release notes and
> justified.
Why does the packager have to do this, when bodhi itself could read
the before/after dependencies and fill in those details?
right, let the machines do the work
or even ask/let the maintainer to confirm the changes as intentional
before going on with the update
Dan
> Rich.
>
> > * Adding this to
> > https://fedoraproject.org/wiki/Updates_Policy#All_other_updates
> > * Avoid updates that introduce any new dependencies
> >
> > Thoughts?
> >
> > Regards,
> > Dominik
> >
> > --
> > Fedora http://fedoraproject.org/wiki/User:Rathann
> > RPMFusion http://rpmfusion.org
> > "Faith manages."
> > -- Delenn to Lennier in Babylon 5:"Confessions and
> > Lamentations" _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones Read my programming and
> virtualization blog: http://rwmj.wordpress.com libguestfs lets you
> edit virtual machines. Supports shell scripting, bindings from many
> languages. http://libguestfs.org
> _______________________________________________ devel mailing list --
> devel(a)lists.fedoraproject.org To unsubscribe send an email to
> devel-leave(a)lists.fedoraproject.org
12:23 p.m.
On Mon, 2017-02-27 at 18:15 +0000, Richard W.M. Jones wrote:
> * Mandating that all dependency changes in package updates in a
stable
> release MUST be mentioned in bodhi update release notes and justified.
Why does the packager have to do this, when bodhi itself could read
the before/after dependencies and fill in those details?
Bodhi could *list* them, but unless it got rather a lot smarter, it
couldn't *justify* them. ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2622
days inactive
2628
days old
18 comments
9 participants
participants (9)
-
Adam Williamson -
Dan Horák -
Daniel P. Berrange -
Dominik 'Rathann' Mierzejewski -
Neal Gompa -
Ralf Corsepius -
Richard W.M. Jones -
Stephen John Smoogen -
Zbigniew Jędrzejewski-Szmek