On Sun, 29 Mar 2020 at 15:20, Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote:
>
> On Sun, Mar 29, 2020 at 2:36 PM clime <clime@xxxxxxxxxxxxxxxxx> wrote:
> >
> > On Sun, 29 Mar 2020 at 13:34, Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote:
> > >
> > > Hi,
> > >
> > > On Sat, Mar 28, 2020 at 11:25 PM clime <clime@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > > 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@xxxxxxxxxxxxxxxxxxxxxxx
> > _______________________________________________
> > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxxxxx
>
> --
> Aleksandra Fedorova
> bookwar
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
