Otherwise, I think the change is a nice idea.
On Sun, 29 Mar 2020 at 16:03, clime <cl...@fedoraproject.org> wrote:
>
> On Sun, 29 Mar 2020 at 15:20, Aleksandra Fedorova <al...@bookwar.info> wrote:
> >
> > On Sun, Mar 29, 2020 at 2:36 PM clime <cl...@fedoraproject.org> wrote:
> > >
> > > On Sun, 29 Mar 2020 at 13:34, Aleksandra Fedorova <al...@bookwar.info>
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Sat, Mar 28, 2020 at 11:25 PM clime <cl...@fedoraproject.org> wrote:
> > > > >
> > > > > From the proposal:
> > > > >
> > > > > %if 0%{?fedora} < 32 && 0%{?rhel} <= 8
> > > > >
> > > > > The fix will be done via a pull request that states a time limit. We
> > > > > want the regular maintainers to see / comment / commit, but we also
> > > > > don't want things to stall for months and get forgotten about.
> > > > >
> > > > > ---
> > > > >
> > > > > What kind of pull request is that? It's like saying either merge or
> > > > > ...
> > > > > In other words, great way to lose community members.
> > > >
> > > > This is a better version of what proven packages already do nowadays.
> > > >
> > > > If package already has a disttag-specific conditional, and this
> > > > conditional leads to a build failure in the eln-environment, then we
> > > > need a fix for that. Here we are not talking about introducing new
> > > > conditionals, feature switches or dependency adjustments. We will be
> > > > fixing the existing conditional so that package can be built.
> > > >
> > > > Currently proven packagers fix such build failures directly. We will
> > > > propose changes via pull requests, so that maintainer has a
> > > > possibility to say "no", or to say "do it differently". But if we can
> > > > not get any feedback from a maintainer on it, we will fix the build
> > > > failure.
> > >
> > > Hi,
> > >
> > > I think it would be nice to say in the change that it's okay to say
> > > "no"
> >
> > It is a common sense. I don't see how it can be interpreted the other way.
>
> Well, the change doesn't describe concretely what to do in such a case
> except "we will talk about it or look into the options".
>
> If you said something like:
>
> "ELN SIG may opt for maintaining an ELN version of a package in a fork
> in case upstream maintainer doesn't wish to support the eln use-case."
> + technical details of this should be figured out (in terms of
> auto-syncing).
>
> It would indicate that you are ready for the situation, i.e. you are
> ready to respect a maintainers' wish.
>
> Idk, maybe you also consider this common sense or you haven't thought
> about it or something else.
>
> But I think that being more explicit in the change description could
> only help for people to understand better what it means for them.
>
> >
> > > and what
> > > ELN SIG will do in that case.
> >
> > It is described as other options in the change: We talk, we look into
> > options, we may consider removing the conditional altogether, if it is
> > not relevant anymore and continue using a clean "unconditionalized"
> > package.
> >
> > If you are asking me what I am going to do if I meet Fedora packager,
> > who deliberately _adds_ conditional to the package to make this
> > package to fail to build in the eln environment and refuses to remove
> > it, then the answer is - I don't know. But I will be surprised, and I
> > will start questioning my life choices, for sure.
> >
> > > clime
> > >
> > > >
> > > > --
> > > > Aleksandra Fedorova
> > > > bookwar
> > > > _______________________________________________
> > > > devel mailing list -- devel@lists.fedoraproject.org
> > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > > Fedora Code of Conduct:
> > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
> > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > > _______________________________________________
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> > --
> > Aleksandra Fedorova
> > bookwar
> > _______________________________________________
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
