Re: Sync deadlines for self contained and system wide changes

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

 



On Wed, Jan 30, 2019 at 5:50 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>
> On 29. 01. 19 20:31, Stephen John Smoogen wrote:
> > 1) Move System-Wide and Self-Contained proposal deadlines to be the same date
> > and allow FESCO/etc determine if the proposal needs to be moved to SW or SC then?
> > 2) Move Self-Contained deadline BEFORE System-Wide so that  if it is really
> > System-Wide move it to the correct category?
> > 3) Add a re-evaluate deadline after the first two? This allows us to get an idea
> > that "oh wait this is going to really mess things up and we need to push this
> > out one release?" or other items
>
> I'm starting a new thread about this so it is not buried in the YUM3 removal thread.
>
> I don't think 2 brings us any benefit over 1.
>
> I understand the need of soon deadline for changes needing the mass rebuild.
> However I guess changes not needing it might share a deadline, so we are able to
> "upgrade" a Self Contained change proposal to System Wide without postponing to
> the next Fedora release.
>
> Before we do any changes, what is the actual reasoning for two deadlines?
> Is it the assumption that System Wide changes need more time? That is not always
> correct.
>
I think it's more that Self-Contained Changes should have no
downstream impact, so we can give them a little more time to come in.
System-Wide Changes could potentially impact the mass rebuild, etc, so
they need to come in a little earlier. Arguably, it should be a week
or two sooner than it is now since a Change that requires a mass
rebuild that is submitted the day of the deadline doesn't have a lot
of time to get approved and implemented.

On Wed, Jan 30, 2019 at 5:51 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
>
> This split between SW and SC was artificial since the beginning and I'd be happy if we dropped it.
>
It's a meaningful distinction because it changes the level of rigor
that we require. Adding a leaf package and changing the compiler
version should not be treated the same. That was one of the problems
with the old Features process.

I have no objections to unifying the proposal deadlines to the current
System-Wide proposal deadline. It means there's a shorter window for
Self-Contained Change proposals to be submitted, but I don't know if
that's particularly meaningful, especially since some proposals being
labeled as Self-Contained should really be System-Wide. That benefit
may outweigh the downside of the shorter window.

It's clear, though, that the guidance for how to distinguish the
Change types needs improving. I will work on that as I start migrating
content out of the wiki and into docs.fp.o.

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [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