Re: policy on changes in or introduction of new dependencies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
> On Thu, Feb 23, 2017 at 7:33 AM, Dominik 'Rathann' Mierzejewski
> <dominik@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx/message/BVUZWJYW2UVO53EZ2G2ALAQPU5PLDJZR/
> >> > >
> >> > > 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"
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux