Re: Fedora 23 Final RC10 status is GO !

[Kevin Kofler]

Kamil Paral wrote:
> So we could ignore freeze just for packages not being on any install
> medium. But then I'm not sure how much that is helpful and it might be
> difficult to implement this in Bodhi.

In the old manual process, I just had to ask rel-eng and they'd blanket-OK 
freeze overrides for such packages (with the same arguments as yours, i.e., 
it cannot really break anything). These days, such freeze override requests 
get blanket-rejected instead (because it doesn't make much of a difference, 
so they don't see any reason to make exceptions to the processes).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Kamil Paral]

> Very frequently in such cases the entire test matrix is not completely
> retested. A lot of prior tests a carried over because they're known
> (or strongly suspected) of not having been touched in any way by the
> fix of one or two blocker bugs.
> 
> If hundreds of packages get unfrozen and sync'd all bets are off. The
> state of the release is now sufficiently non-determinstic that it
> means all testing has to be started completely from scratch. So I
> would say no, this isn't a good idea, just because the resources
> aren't there to do this additional amount of testing.
> 
> The goal isn't to have a release that's super current. It's to have a
> release that's stable and works.

I think that Chris described it very well. I'm quite skeptical that such a 
proposal would work in practice because of these reasons. It's quite demanding 
for us to just fix and test the outstanding blockers. Updating everything would 
mean:
a) retesting everything from scratch, and of course our testing covers only a 
few selected areas, we rely on many people from community to report blockers 
when they find them -- that takes time, not just a few days of testing crunch
b) potentially breaking anything, from boot to installer to desktop environment 
to apps

Of course if things break immediately after first system update, our users are 
not much better off. But at least the install medium booted and installer 
worked. The broken updates can be fixed, they are not baked into the install 
medium.

Maybe we could consider some middle approach, where things not in the critical 
path (not directly affecting the core system and installer) would not be 
affected by freeze. That shouldn't break much and would help many pre-release 
users and maintainers. It can still introduce new blockers, though, if those 
apps are e.g. on Live medium or are installed by Server by default (and then 
don't start). So we could ignore freeze just for packages not being on any 
install medium. But then I'm not sure how much that is helpful and it might be 
difficult to implement this in Bodhi.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Adam Williamson]

On Mon, 2015-11-09 at 13:56 +0100, Kevin Kofler wrote:
> Kamil Paral wrote:
> > So we could ignore freeze just for packages not being on any install
> > medium. But then I'm not sure how much that is helpful and it might be
> > difficult to implement this in Bodhi.
> 
> In the old manual process, I just had to ask rel-eng and they'd blanket-OK 
> freeze overrides for such packages (with the same arguments as yours, i.e., 
> it cannot really break anything).

Yes - and that frequently went wrong. That's precisely why we ditched
that process and came up with a better one, where the decision isn't
made on-the-fly by whoever happens to be reading the tickets in releng,
but is made according to an established process, by a sensible group of
stakeholders, with proper tracking and a paper trail.

>  These days, such freeze override requests 
> get blanket-rejected instead (because it doesn't make much of a difference, 
> so they don't see any reason to make exceptions to the processes).

Nothing gets blanket rejected. Each FE proposal is evaluated
individually on its merits.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Adam Williamson]

On Mon, 2015-11-09 at 17:11 -0800, Adam Williamson wrote:
> On Mon, 2015-11-09 at 13:56 +0100, Kevin Kofler wrote:
> > Kamil Paral wrote:
> > > So we could ignore freeze just for packages not being on any install
> > > medium. But then I'm not sure how much that is helpful and it might be
> > > difficult to implement this in Bodhi.
> > 
> > In the old manual process, I just had to ask rel-eng and they'd blanket-OK 
> > freeze overrides for such packages (with the same arguments as yours, i.e., 
> > it cannot really break anything).
> 
> Yes - and that frequently went wrong. That's precisely why we ditched
> that process and came up with a better one, where the decision isn't
> made on-the-fly by whoever happens to be reading the tickets in releng,
> but is made according to an established process, by a sensible group of
> stakeholders, with proper tracking and a paper trail.

Sorry, I missed that you were talking about packages not on the release
media. Yeah, those are kind of odd because you can argue them either
way: on the one hand pulling them in is unlikely to break anything, on
the other hand, what's the point of doing it? I'd usually still err on
the side of caution and leave them out, just in case they somehow break
the buildroot or do something else strange, if there's no actual
particular reason to push them.

And yes, there is an obvious technical problem - we don't actually have
the ability, right now, to know for sure exactly what packages are
somehow directly involved in building the media.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Chris Murphy]

On Wed, Nov 4, 2015 at 3:30 PM, Kevin Fenzi  wrote:
> On Tue, 3 Nov 2015 09:23:49 +0100
> Petr Spacek  wrote:
>
>> On 3.11.2015 01:56, Kevin Kofler wrote:
>> > And with my proposed change to the release
>> > policy (slip = unfreeze, sync all updates, refreeze), you could
>> > also use the time to get fixes/improvements in that would have
>> > otherwise missed the release.
>>
>> +1, this seems like a very reasonable proposal to me.
>
> The problem here is that a slip is a week.
>
> Right now, if we slip it's usually just a bug or two and those get
> worked on and we spin a new RC and test, etc.
>
> If we did this it could mean potentially lots more blockers, so it
> could leed to longer slips. Also, it could make changes such that
> things don't even compose.
>
> But it's an interesting idea.
> I'd love to hear what QA folks think about it.


Very frequently in such cases the entire test matrix is not completely
retested. A lot of prior tests a carried over because they're known
(or strongly suspected) of not having been touched in any way by the
fix of one or two blocker bugs.

If hundreds of packages get unfrozen and sync'd all bets are off. The
state of the release is now sufficiently non-determinstic that it
means all testing has to be started completely from scratch. So I
would say no, this isn't a good idea, just because the resources
aren't there to do this additional amount of testing.

The goal isn't to have a release that's super current. It's to have a
release that's stable and works.

The proposal could be attempted for alpha to see what happens in a
less detrimental fashion. But for final, it's already enough of whack
a mole, and this would be like putting the moles on fertility drugs.
Or throwing a deck of cards up into the air to shuffle it. Or...


--
Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates (was Fedora 23 Final RC10 status is GO !)

[Mustafa Muhammad]

Hi,
I think the better approach is to allow more updates, as Kevin suggested,
usually they fix more than they break.
I also think shorter freezes with unfreeze on slip are better than the
current approach of accumulated updates on release day.

>From my point of view, the best approach is rolling release, if the
manpower allows for it, openSUSE and Arch do it well, and for the more
conservative people, there is the "Security Updates Only" way of
dnf-automatic that Johnny mentioned.

Regards
Mustafa
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates (was Fedora 23 Final RC10 status is GO !)

[Michael Catanzaro]

On Thu, 2015-11-05 at 02:16 +0100, Kevin Kofler wrote:
> Michael Catanzaro wrote:
> > 1) More time to catch regressions
> 
> In theory. In practice, it mostly means more wasted time until a
> regression 
> is FIXED, i.e., it is entirely counterproductive. Many regressions
> are only 
> noticed once the update goes stable, because that's when most users
> start 
> trying it.

I think we would need an alternate "fast path" for updates, in case of
regressions. I agree with you that the current karma system hurts more
than it helps there. It should be possible to push an update that
merely reverts a previous update directly to stable.

> I don't see how even longer delays in testing would help. The
> majority that 
> does not have updates-testing enabled won't get it before it goes
> stable no 
> matter how long it sits in testing. The users who use updates-testing
> are 
> those who want updates fast and so will get it within the first
> couple days.

In practice, I've seen bugs caught in updates-testing, and others
caught only after entering stable. More time in updates-testing can
only reduce regressions that make it to stable, but yes, also delay
fixes that we would wish to release sooner. I suspect the ideal amount
of time spent in testing is "more than we do now."

But since you pointed out that service packs could be implemented on
the existing updates system, I'm now leaning towards keeping everything
we have now the same, and using the stable updates repo as a level of
testing for service packs released to Workstation users via GNOME
Software. (You could still get all the latest updates with dnf if you
want.)

> I don't see how a huge mix of unrelated updates is in any way easier
> to QA 
> than the individual small, targeted updates. In fact, I think it is
> the 
> exact opposite: there is no way to adequately QA the whole service
> pack, it 
> just does not scale.

Well yes, it would be worse if we got rid of the karma system and no
longer QAed individual updates, but we should layer our release QA on
top of the updates we do now. After an update graduates from testing,
it'll be automatically included in the next service pack. Then every,
say, six weeks, we do the normal release validation on it and release
updated install media. If it doesn't pass release validation, then
quality has decreased since the initial release and we know there's a
problem with our updates.

> > 3) Less-frequent updates
> 
> That is a BAD thing. I want to get my bugfixes as quickly as
> possible. (In 
> fact, I'm unhappy that our infrastructure does not support instant
> pushes.) 
> I have Apper set to check for updates hourly because the default
> daily is 
> too slow for me! Sure, we don't have hourly pushes (sadly), but daily
> means 
> up to an ADDITIONAL day of delay.

Ah, but while you like this for yourself, I think that is too fast for
the common user.

Maybe you're right, though. The frequency that we release updates
itself isn't necessarily the problem, so much as the frequency the tool
checks for updates. We shouldn't have weekly LO updates by *default*,
but that shouldn't stop you from getting them if you want them. Maybe
we should just configure GNOME Software to check for updates less
frequently, and apply only the security updates and no other update
when there is a security issue. Or do service packs and not worry about
it.

Either way allows us to achieve slower updates for Workstation without
slowing things down for you.

> The negative effect that the whole thing hits at once would be the
> much more 
> noticeable effect. So the updates would actually feel slower, and
> probably 
> even BE slower because the mirrors would be swamped, just as they are
> on a 
> release day.

True, that is a risk... but I think it is less an exception than you
believe. I notice most package updates are for packages that were
updated quite recently. I speculate that a small portion of packages in
the distro make for a fairly large portion of updates, and that service
packs won't balloon to be as large as you expect. Regardless, they
shouldn't be as bad as a post-install update is now, which take 30-45
minutes for me. Install media respins will fix that.

But yes, you're right in that we have a trade-off between frequency of
updates and duration of updates. We have less total time spent updating
if updates are further apart, as updates that would otherwise be
applied separately are obsoleted by newer updates, but more total time
spent in each individual update.

> As for bandwidth-limited users, what would REALLY be a massive
> disaster is 
> your "service pack" approach! If even just LibreOffice alone is a
> problem, 
> imagine all updates of the whole month at once!

People are generally are charged by the month, right? So ensuring each
package is updated at most once per month can only reduce the fees.

> Of course, the contention point is then what is a "core system
> application". 
> If you mean things like 

Re: Updates (was Fedora 23 Final RC10 status is GO !)

[Kevin Kofler]

Michael Catanzaro wrote:
> 1) More time to catch regressions

In theory. In practice, it mostly means more wasted time until a regression 
is FIXED, i.e., it is entirely counterproductive. Many regressions are only 
noticed once the update goes stable, because that's when most users start 
trying it.

> (1) doesn't require the service pack approach and could be implemented
> by just adding a longer waiting period to bodhi. I'm of the mind that
> all updates should spend two weeks in testing before they go stable,
> regardless of karma, since otherwise how will people have time to
> notice regressions?

I don't see how even longer delays in testing would help. The majority that 
does not have updates-testing enabled won't get it before it goes stable no 
matter how long it sits in testing. The users who use updates-testing are 
those who want updates fast and so will get it within the first couple days.

> Currently updates tend to stay in testing for a week or less, which isn't
> even enough time for GNOME Software to prompt the user about new updates.

That is a defect/misfeature in GNOME Software and needs to be fixed there. 
But I'd expect most updates-testing users to be using command-line tools (or 
at least more advanced GUIs such as Yumex-DNF) anyway (and this very issue 
is one of the reasons).

> 2) A reasonable way to QA a snapshot of what gets released
> 
> (2) allows us to solve the problem of having no effective QA for our
> updates. Maybe the current team is not big enough to QA service packs
> as well as the next release, but at least with service packs there is
> something that can reasonably be QAed.

I don't see how a huge mix of unrelated updates is in any way easier to QA 
than the individual small, targeted updates. In fact, I think it is the 
exact opposite: there is no way to adequately QA the whole service pack, it 
just does not scale.

> It also allows for regular install media respins, which I think you want?
> That will make Linus happy, too.

The respins can be done from the current updates, it is in fact already 
being done, just not "officially". The respins, by their nature, 
automatically cumulate the updates, and so don't need them already 
cumulated.

And I believe the respins to be much easier to QA if the updates have all 
already been QAed individually. As I explained above, I don't think a 
"service pack" can be adequately QAed as a unit.

> 3) Less-frequent updates

That is a BAD thing. I want to get my bugfixes as quickly as possible. (In 
fact, I'm unhappy that our infrastructure does not support instant pushes.) 
I have Apper set to check for updates hourly because the default daily is 
too slow for me! Sure, we don't have hourly pushes (sadly), but daily means 
up to an ADDITIONAL day of delay.

> (3) is quite important, since in Workstation we reboot to install
> updates, which is quite annoying.

And that is another defect/misfeature in GNOME Software that needs to be 
fixed there.

> (No point in arguing about that here, it's a done deal)

So instead of fixing broken software, we should break the whole distribution 
to work around it? No thanks!

> Here you would only have one reboot per service pack, plus security
> updates.

The "plus security updates" caveat makes even that mostly moot.

> 4) Small total size of updates
> 
> (4) would be true if a package would otherwise have been updated
> multiple times between service packs.

Which is the exception rather than the rule. I think the win would be 
negligible.

The negative effect that the whole thing hits at once would be the much more 
noticeable effect. So the updates would actually feel slower, and probably 
even BE slower because the mirrors would be swamped, just as they are on a 
release day.

> I will pick on LibreOffice. Individually, the updates rarely ever break
> anything, and fix bugs, so they're good updates taken alone. But
> collectively, it's problematic because there's a new update every week,
> and LibreOffice is big: it takes a lot of time to download and install.
> Does the inconvenience of making the update take longer offset the
> value provided by the update? It's a function of how often you use
> LibreOffice, how much the relevant bugs affect you, your download
> bandwidth, and your hard drive speed. I rarely use LO, so weekly
> updates are definitely not worth it for me: I'd rather have the updates
> once a month, at most, but it's just an inconvenience. For the
> maintainer, weekly updates are surely worth it, or they wouldn't be
> happening. For most users, probably not, but I guess it depends on the
> bug. For bandwidth-limited users, it's not an inconvenience, but a
> massive disaster. We're currently lacking criteria to say how frequent
> is too frequent. I think 3-4 weeks between updating one package is
> probably as fast as is ever appropriate, except in special
> circumstances (maintainer discretion there), but weekly updates as a
> rule is problematic, especially for 

Re: Updates (was Fedora 23 Final RC10 status is GO !)

[Johnny Robeson]

On Wed, 2015-11-04 at 20:03 -0600, Michael Catanzaro wrote:
> On Thu, 2015-11-05 at 02:16 +0100, Kevin Kofler wrote:
> > Michael Catanzaro wrote:
> > > 1) More time to catch regressions
> > 
> > In theory. In practice, it mostly means more wasted time until a
> > regression 
> > is FIXED, i.e., it is entirely counterproductive. Many regressions
> > are only 
> > noticed once the update goes stable, because that's when most users
> > start 
> > trying it.
> 
> I think we would need an alternate "fast path" for updates, in case
> of
> regressions. I agree with you that the current karma system hurts
> more
> than it helps there. It should be possible to push an update that
> merely reverts a previous update directly to stable.
> 
> > I don't see how even longer delays in testing would help. The
> > majority that 
> > does not have updates-testing enabled won't get it before it goes
> > stable no 
> > matter how long it sits in testing. The users who use updates-
> > testing
> > are 
> > those who want updates fast and so will get it within the first
> > couple days.
> 
> In practice, I've seen bugs caught in updates-testing, and others
> caught only after entering stable. More time in updates-testing can
> only reduce regressions that make it to stable, but yes, also delay
> fixes that we would wish to release sooner. I suspect the ideal
> amount
> of time spent in testing is "more than we do now."
> 
> But since you pointed out that service packs could be implemented on
> the existing updates system, I'm now leaning towards keeping
> everything
> we have now the same, and using the stable updates repo as a level of
> testing for service packs released to Workstation users via GNOME
> Software. (You could still get all the latest updates with dnf if you
> want.)
> 
> > I don't see how a huge mix of unrelated updates is in any way
> > easier
> > to QA 
> > than the individual small, targeted updates. In fact, I think it is
> > the 
> > exact opposite: there is no way to adequately QA the whole service
> > pack, it 
> > just does not scale.
> 
> Well yes, it would be worse if we got rid of the karma system and no
> longer QAed individual updates, but we should layer our release QA on
> top of the updates we do now. After an update graduates from testing,
> it'll be automatically included in the next service pack. Then every,
> say, six weeks, we do the normal release validation on it and release
> updated install media. If it doesn't pass release validation, then
> quality has decreased since the initial release and we know there's a
> problem with our updates.
> 
> > > 3) Less-frequent updates
> > 
> > That is a BAD thing. I want to get my bugfixes as quickly as
> > possible. (In 
> > fact, I'm unhappy that our infrastructure does not support instant
> > pushes.) 
> > I have Apper set to check for updates hourly because the default
> > daily is 
> > too slow for me! Sure, we don't have hourly pushes (sadly), but
> > daily
> > means 
> > up to an ADDITIONAL day of delay.
> 
> Ah, but while you like this for yourself, I think that is too fast
> for
> the common user.
> 
> Maybe you're right, though. The frequency that we release updates
> itself isn't necessarily the problem, so much as the frequency the
> tool
> checks for updates. We shouldn't have weekly LO updates by *default*,
> but that shouldn't stop you from getting them if you want them. Maybe
> we should just configure GNOME Software to check for updates less
> frequently, and apply only the security updates and no other update
> when there is a security issue. Or do service packs and not worry
> about
> it.
> 
I've been using dnf-automatic with:

apply_updates=True
upgrade_type=security

on Fedora Server for that.
> Either way allows us to achieve slower updates for Workstation
> without
> slowing things down for you.
> 
> > The negative effect that the whole thing hits at once would be the
> > much more 
> > noticeable effect. So the updates would actually feel slower, and
> > probably 
> > even BE slower because the mirrors would be swamped, just as they
> > are
> > on a 
> > release day.
> 
> True, that is a risk... but I think it is less an exception than you
> believe. I notice most package updates are for packages that were
> updated quite recently. I speculate that a small portion of packages
> in
> the distro make for a fairly large portion of updates, and that
> service
> packs won't balloon to be as large as you expect. Regardless, they
> shouldn't be as bad as a post-install update is now, which take 30-45
> minutes for me. Install media respins will fix that.
> 
> But yes, you're right in that we have a trade-off between frequency
> of
> updates and duration of updates. We have less total time spent
> updating
> if updates are further apart, as updates that would otherwise be
> applied separately are obsoleted by newer updates, but more total
> time
> spent in each individual update.
> 
> > As for bandwidth-limited users, what would 

Re: Fedora 23 Final RC10 status is GO !

[Kevin Fenzi]

On Tue, 3 Nov 2015 09:23:49 +0100
Petr Spacek  wrote:

> On 3.11.2015 01:56, Kevin Kofler wrote:
> > And with my proposed change to the release 
> > policy (slip = unfreeze, sync all updates, refreeze), you could
> > also use the time to get fixes/improvements in that would have
> > otherwise missed the release.  
> 
> +1, this seems like a very reasonable proposal to me.

The problem here is that a slip is a week. 

Right now, if we slip it's usually just a bug or two and those get
worked on and we spin a new RC and test, etc. 

If we did this it could mean potentially lots more blockers, so it
could leed to longer slips. Also, it could make changes such that
things don't even compose. 

But it's an interesting idea. 
I'd love to hear what QA folks think about it. 

kevin



pgpsJhhVjxSB1.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates (was Fedora 23 Final RC10 status is GO !)

[Petr Spacek]

On 3.11.2015 02:13, Kevin Kofler wrote:
> Michael Catanzaro wrote:
>> Yeah, that's the clear disadvantage. The service pack approach
>> sidesteps that problem: everything still goes out, just not so soon, so
>> everything spends plenty of time in testing. All the bugs still get
>> fixed, just not as fast.
> 
> And that's "better" HOW?
> 
>> (This also solves the problem of maintainers releasing individually
>> -good updates too frequently.)
> 
> What problem? "too frequently" according to whom? I don't see any problem 
> here, and I think updates (especially bugfixes) cannot be frequent enough.

+1 again. If you are not comfortable with updating e.g. every day, just
schedule the cron job to do it weekly/monthly instead of daily. It is
end-user's choice, there is not need to delay updates on distribution's side.

Petr Spacek

>> The counterargument is that we keep seeing major version updates that
>> violate our existing updates policy.
> 
> This means the policy is broken, not the updates. I am glad that we are not 
> following that policy to the letter, that's the only reason the system works 
> at all! We need to encourage pushing new versions unless there is a good 
> reason not to, including, but not limited to:
> * incompatibility with existing data (including documents, config files,
>   savegames, etc.),
> * feature regressions (including deliberately removed features and features
>   missing from a rewrite),
> * major UI changes (but a menu item moving to some other place is harmless),
> * new bugs (known in advance or found during testing) unless outweighed by
>   the bugs that are fixed,
> etc. If none of the above hold, then why would we not let the users benefit 
> from the new features in the new version of the package? Upstream clearly 
> considers it stable or they would not have released it as such.
> 
>> Who if not a neutral party charged with upholding that policy should have
>> the final say? Some maintainers who clearly haven't read it?
> 
> I have read it. I just don't interpret it as being in contradiction with my 
> updates. See e.g. Routino, which only went from 2.7.3 to 3.0 because it 
> added a shared library (which in turn allows building new versions of 
> applications such as qmapshack). The changes to the routing software itself 
> are minor and almost entirely bugfixes. It is also compatible with databases 
> from 2.7.3. (I NEVER push an update of Routino that is NOT database-
> compatible!) I don't see any reason why the update would be a problem.
> 
>> If we have another party approving updates, then it's the maintainer's
>> job to write an argument in favor of releasing the update: a quick
>> summary of what the fix is and the regression potential. If the update
>> gets rejected, the maintainer might really be wrong! and if not would
>> have to try again to explain better. I think this would be good
>> regardless of whether or not we do updates packs.
> 
> I think this would just be added bureaucracy and a royal PITA. Bodhi is 
> already painful enough as it stands!
> 
> If you keep making it harder for packagers to do their job, you will find 
> yourself losing packagers rapidly.
> 
> Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Petr Spacek]

On 3.11.2015 01:56, Kevin Kofler wrote:
> And with my proposed change to the release 
> policy (slip = unfreeze, sync all updates, refreeze), you could also use the 
> time to get fixes/improvements in that would have otherwise missed the 
> release.

+1, this seems like a very reasonable proposal to me.

-- 
Petr Spacek  @  Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Michael Catanzaro]

On Tue, 2015-11-03 at 02:28 +0100, Kevin Kofler wrote:
> (And to those people who want to do "service packs": please focus
> your 
> "service pack" testing on the respins instead, and don't break the
> existing 
> update system that works fine.)

Yeah, there's really no reason service packs would have to be
mandatory. It could definitely be layered on top of the existing
system. Well, someone would have to implement it that way, of
course

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates (was Fedora 23 Final RC10 status is GO !)

[Michael Catanzaro]

On Tue, 2015-11-03 at 02:13 +0100, Kevin Kofler wrote:
> Michael Catanzaro wrote:
> > Yeah, that's the clear disadvantage. The service pack approach
> > sidesteps that problem: everything still goes out, just not so
> > soon, so
> > everything spends plenty of time in testing. All the bugs still get
> > fixed, just not as fast.
> 
> And that's "better" HOW?

In order of importance:

1) More time to catch regressions
2) A reasonable way to QA a snapshot of what gets released
3) Less-frequent updates
4) Small total size of updates

(1) doesn't require the service pack approach and could be implemented
by just adding a longer waiting period to bodhi. I'm of the mind that
all updates should spend two weeks in testing before they go stable,
regardless of karma, since otherwise how will people have time to
notice regressions? Currently updates tend to stay in testing for a
week or less, which isn't even enough time for GNOME Software to prompt
the user about new updates.

(2) allows us to solve the problem of having no effective QA for our
updates. Maybe the current team is not big enough to QA service packs
as well as the next release, but at least with service packs there is
something that can reasonably be QAed. It also allows for regular
install media respins, which I think you want? That will make Linus
happy, too.

(3) is quite important, since in Workstation we reboot to install
updates, which is quite annoying. (No point in arguing about that here,
it's a done deal) Here you would only have one reboot per service
pack, plus security updates.

(4) would be true if a package would otherwise have been updated
multiple times between service packs.

> > (This also solves the problem of maintainers releasing individually
> > -good updates too frequently.)
> 
> What problem? "too frequently" according to whom? I don't see any
> problem 
> here, and I think updates (especially bugfixes) cannot be frequent
> enough.

I will pick on LibreOffice. Individually, the updates rarely ever break
anything, and fix bugs, so they're good updates taken alone. But
collectively, it's problematic because there's a new update every week,
and LibreOffice is big: it takes a lot of time to download and install.
Does the inconvenience of making the update take longer offset the
value provided by the update? It's a function of how often you use
LibreOffice, how much the relevant bugs affect you, your download
bandwidth, and your hard drive speed. I rarely use LO, so weekly
updates are definitely not worth it for me: I'd rather have the updates
once a month, at most, but it's just an inconvenience. For the
maintainer, weekly updates are surely worth it, or they wouldn't be
happening. For most users, probably not, but I guess it depends on the
bug. For bandwidth-limited users, it's not an inconvenience, but a
massive disaster. We're currently lacking criteria to say how frequent
is too frequent. I think 3-4 weeks between updating one package is
probably as fast as is ever appropriate, except in special
circumstances (maintainer discretion there), but weekly updates as a
rule is problematic, especially for such a large package.

I'd like to get to the point where a reboot to install weekly updates
takes about a minute. Currently, it's about five minutes per weekly
update. I recently made the mistake of installing all of texlive, so
that I wouldn't have to bang my head against a wall when trying to
figure out what Fedora package to install to get a particular texlive
package; that caused my weekly updates to take 2-3 hours apiece, so my
computer was unusable for the rest of the evening when I made the
mistake of applying updates. (texlive is a good example of another set
of packages that must be updated very rarely, even if the content of
the updates itself is fine.)

> > The counterargument is that we keep seeing major version updates
> > that
> > violate our existing updates policy.
> 
> This means the policy is broken, not the updates. I am glad that we
> are not 
> following that policy to the letter, that's the only reason the
> system works 
> at all! We need to encourage pushing new versions unless there is a
> good 
> reason not to, including, but not limited to:
> * incompatibility with existing data (including documents, config
> files,
>   savegames, etc.),
> * feature regressions (including deliberately removed features and
> features
>   missing from a rewrite),
> * major UI changes (but a menu item moving to some other place is
> harmless),
> * new bugs (known in advance or found during testing) unless
> outweighed by
>   the bugs that are fixed,
> etc. If none of the above hold, then why would we not let the users
> benefit 
> from the new features in the new version of the package? Upstream
> clearly 
> considers it stable or they would not have released it as such.

For most applications (not core system applications), major version
updates are fine, and the policy could be changed. For lower-level
system 

Re: Fedora 23 Final RC10 status is GO !

[Gerald B. Cox]

On Mon, Nov 2, 2015 at 9:07 AM, Jonathan Underwood <
jonathan.underw...@gmail.com> wrote:

> I think it is to some extent a question of what we are QA'ing for. As
> I see it (and I may be in the minority), the QA process is a process
> put in place to ensure the *install and live media* function
> correctly, and produce a working installed system from which the user
> can move forward with updates.
>

Exactly.  The purpose of the install and live media is to have a system
that functions.  Regarding the 500+ updates...   No one is forcing you to
update your system - and if you do, as another person pointed out,
deltarpms will reduce the amount of bandwidth required.  If you wait for
updates to stop before you decide to go GA, you're going to be waiting
forever.  Additionally, artificially manipulating the process more than it
already is serves no real purpose.  It just adds additional work with no
real benefit.  Eventually there are going to be updates.  This seems to me
about coming up with additional arbitrary criteria for a system that by its
nature is always going to be arbitrary.  I think there are more pressing
issues and better ways for the community to spend it's resources.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Neal Gompa]

On Mon, Nov 2, 2015 at 12:33 PM, Kevin Fenzi  wrote:

> On Mon, 02 Nov 2015 01:28:07 +
> Sérgio Basto  wrote:
>
> > On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote:
> > > On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto 
> > > wrote:
> > > > On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:
> > > >> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
> > > >> ends, has been Fedora 23 Final-RC10 declared as GOLD.
> > > >> GA of this release is planed on Tuesday 2015-Nov-03.
> > > >>
> > > > Today we got 531 updates for F23 , IMO, you should include it on
> > > > Fedora 23 Final before GA , doesn't make sense (to me) after
> > > > download an ISO have 1/2 Giga of updates, but this happens since
> > > > RedHad 9 at least . IMO, testing team should respin ISO with
> > > > updates and testing again . I have some difficulty in following
> > > > all development, fortunately Fedora is always at great speed, but
> > > > it is not easy to follow. And do more tests we not lose anything,
> > > > IMHO.
> > >
> > > The problem is we have to freeze sometime to ensure stability in the
> > > installer platform, the live and other images which are static. If
> > > not it's too much of a moving target to try and QA and ensure
> > > everything works as expected. To freeze is a fairly standard
> > > procedure for all distro development.
> >
> > Make an respin for F23 with stable updates, IMHO, should not break
> > anything, because at this stage, just stable things are being pushed.
> > So it should be just one more loop in testing phase, anyway if breaks
> > something test team can freeze process again, until provide a  fix.
> > This is not new !, respins of fedoraunity was an example and we
> > already have living respins [1], so we just need do new respin
> > officially!. Shouldn't be a big deal, If I'm not mistaken.
>
> You are. ;)
>
> So, in order to do what you are wanting we need (at least) 3 things:
>
> 1) releng has to make every daily compose a full compose of all
> deliverables. We have actually been working toward this, and perhaps
> for f24 we will get there. However, even if we do that, we can't make
> the daily composes ready for release unless we change our processes
> (test composes/daily composes now have some flags where they do things
> like pop up the 'this is a test release' dialog in the installer, and
> they are called "TC" in the image names).
>
>
​I'm hopeful we can get to this with Rawhide prior to the branching point,
but can our infrastructure handle it?​ I'm somewhat ignorant of the
capabilities of the Fedora infrastructure...



> 2) QA would need to be able to do a full release validation on a set of
> deliverables _every day_. Again, we are making progress here, we have
> openQA now doing a lot of daily install testing, and taskotron doing a
> bunch of testing of things to keep broken packages out of composes.
> That said, there's a lot of stuff that just cannot be automated:
> testing with specific hardware, looking at issues that aren't in test
> cases (like the last minute help in anaconda issue), etc.
> Additionally, while I know QA folks have done hero testing and
> validated a RC in a day, I think they would revolt if you told them
> they had to do this every single day, and I would not blame them at
> all.
>
>
Perhaps full release validation could occur on composes every two weeks for
branched releases? Or is that still too demanding?


> 3) Finally we would need some way to roll back broken things. We have
> distro-sync right now, but it cannot always downgrade things. If/when
> problems are found sometimes a specific package can be found that
> causes the problem, but sometimes it's a lot more complex. Humans need
> to dig in and figure out what happened and how to fix it. We could just
> say "always use distro-sync in a pre-release, and if you run into
> problems, too bad, just re-install" but I think many of our testers
> would find this unacceptable.
>
>
​Could we slip in some settings for TCs that trigger distro-sync behavior
by default on "dnf upgrade"? Or would this still be undesirable?​



> While I am very happy someone is doing live-respins, I don't think they
> go through a complete release validation cycle. There's been talk in
> the past of doing updated deliverables on a "well, they composed"
> basis, but the idea never got too far.
>
>
​I think it'd be pretty nice if we could use our mix of automated tests and
checks for composing weekly snapshots of rawhide that would be
"installable" and "usable". This is not a particularly new idea[0], but in
light of the openSUSE guys being able to pull it off with Tumbleweed, I
don't see why we can't get there too. ​It might be a little more "raw" than
Tumbleweed and serve somewhat a different purpose, but I think it would
make testing the state of the development tree far easier.



> kevin
>

​[0]: 

Re: Fedora 23 Final RC10 status is GO !

[Kevin Fenzi]

On Mon, 2 Nov 2015 12:45:36 -0500
Neal Gompa  wrote:

...snip...

> ​I'm hopeful we can get to this with Rawhide prior to the branching
> point, but can our infrastructure handle it?​ I'm somewhat ignorant
> of the capabilities of the Fedora infrastructure...

Yes, as I noted we are working on it. 

> Perhaps full release validation could occur on composes every two
> weeks for branched releases? Or is that still too demanding?

No idea. I don't want to speak for the QA folks.  

> ​Could we slip in some settings for TCs that trigger distro-sync
> behavior by default on "dnf upgrade"? Or would this still be
> undesirable?​

90% of the time you can just downgrade a package and it's fine. 
However, the other 10% of the time it just won't work. Your postgresql
database will have a different format. Your package will move a
directory to a link or vice versa. The package will have migrated your
settings to the new version and the old version will crash.  

> ​I think it'd be pretty nice if we could use our mix of automated
> tests and checks for composing weekly snapshots of rawhide that would
> be "installable" and "usable". This is not a particularly new
> idea[0], but in light of the openSUSE guys being able to pull it off
> with Tumbleweed, I don't see why we can't get there too. ​It might be
> a little more "raw" than Tumbleweed and serve somewhat a different
> purpose, but I think it would make testing the state of the
> development tree far easier.

Absolutely. We already are. OpenQA has been detecting problems, and we
have been fixing them. I think this will result in a increased amount
of time that rawhide images are installable. 

Thats only sort of related to discussions about releases and updates
tho. ;) 

kevin


pgpgB0hxvF2sO.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Kevin Fenzi]

On Mon, 02 Nov 2015 01:28:07 +
Sérgio Basto  wrote:

> On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote:
> > On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto 
> > wrote:  
> > > On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:  
> > >> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
> > >> ends, has been Fedora 23 Final-RC10 declared as GOLD.
> > >> GA of this release is planed on Tuesday 2015-Nov-03.
> > >>  
> > > Today we got 531 updates for F23 , IMO, you should include it on
> > > Fedora 23 Final before GA , doesn't make sense (to me) after
> > > download an ISO have 1/2 Giga of updates, but this happens since
> > > RedHad 9 at least . IMO, testing team should respin ISO with
> > > updates and testing again . I have some difficulty in following
> > > all development, fortunately Fedora is always at great speed, but
> > > it is not easy to follow. And do more tests we not lose anything,
> > > IMHO.  
> > 
> > The problem is we have to freeze sometime to ensure stability in the
> > installer platform, the live and other images which are static. If
> > not it's too much of a moving target to try and QA and ensure
> > everything works as expected. To freeze is a fairly standard
> > procedure for all distro development.  
> 
> Make an respin for F23 with stable updates, IMHO, should not break
> anything, because at this stage, just stable things are being pushed.
> So it should be just one more loop in testing phase, anyway if breaks
> something test team can freeze process again, until provide a  fix.
> This is not new !, respins of fedoraunity was an example and we
> already have living respins [1], so we just need do new respin
> officially!. Shouldn't be a big deal, If I'm not mistaken.

You are. ;) 

So, in order to do what you are wanting we need (at least) 3 things: 

1) releng has to make every daily compose a full compose of all
deliverables. We have actually been working toward this, and perhaps
for f24 we will get there. However, even if we do that, we can't make
the daily composes ready for release unless we change our processes
(test composes/daily composes now have some flags where they do things
like pop up the 'this is a test release' dialog in the installer, and
they are called "TC" in the image names). 

2) QA would need to be able to do a full release validation on a set of
deliverables _every day_. Again, we are making progress here, we have
openQA now doing a lot of daily install testing, and taskotron doing a
bunch of testing of things to keep broken packages out of composes.
That said, there's a lot of stuff that just cannot be automated:
testing with specific hardware, looking at issues that aren't in test
cases (like the last minute help in anaconda issue), etc. 
Additionally, while I know QA folks have done hero testing and
validated a RC in a day, I think they would revolt if you told them
they had to do this every single day, and I would not blame them at
all. 

3) Finally we would need some way to roll back broken things. We have
distro-sync right now, but it cannot always downgrade things. If/when
problems are found sometimes a specific package can be found that
causes the problem, but sometimes it's a lot more complex. Humans need
to dig in and figure out what happened and how to fix it. We could just
say "always use distro-sync in a pre-release, and if you run into
problems, too bad, just re-install" but I think many of our testers
would find this unacceptable. 

While I am very happy someone is doing live-respins, I don't think they
go through a complete release validation cycle. There's been talk in
the past of doing updated deliverables on a "well, they composed"
basis, but the idea never got too far. 

kevin


pgpWfjRfEZQPi.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Reindl Harald]

Am 02.11.2015 um 02:28 schrieb Sérgio Basto:

On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote:

On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto  wrote:

On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:

At the third round of Fedora 23 Final Go/No-Go Meeting, that just
ends, has been Fedora 23 Final-RC10 declared as GOLD.
GA of this release is planed on Tuesday 2015-Nov-03.


Today we got 531 updates for F23 , IMO, you should include it on Fedora
23 Final before GA , doesn't make sense (to me) after download an ISO
have 1/2 Giga of updates, but this happens since RedHad 9 at least .
IMO, testing team should respin ISO with updates and testing again .
I have some difficulty in following all development, fortunately Fedora
is always at great speed, but it is not easy to follow. And do more
tests we not lose anything, IMHO.


The problem is we have to freeze sometime to ensure stability in the
installer platform, the live and other images which are static. If not
it's too much of a moving target to try and QA and ensure everything
works as expected. To freeze is a fairly standard procedure for all
distro development.


Make an respin for F23 with stable updates, IMHO, should not break
anything, because at this stage, just stable things are being pushed


in theory


it should be just one more loop in testing phase, anyway if breaks
something test team can freeze process again, until provide a  fix.


who does the work for *what* benefit?
it's just wasting ressources and manpower

who cares about the install ISO when you ave anyways to apply updates 
after or in the best case *due* setup



This is not new !, respins of fedoraunity was an example and we already
have living respins [1], so we just need do new respin officially!.
Shouldn't be a big deal, If I'm not mistaken.


and fedoraunity finally gave up because lack of ressources



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Adam Williamson]

On Mon, 2015-11-02 at 10:52 -0700, Kevin Fenzi wrote:
> 
> > Perhaps full release validation could occur on composes every two
> > weeks for branched releases? Or is that still too demanding?
> 
> No idea. I don't want to speak for the QA folks.  

So to put it simply and broadly: there's a trade-off between how often
we want to release, and how heavily we can test those releases.

Frankly, no, I don't think it's viable to do the entire current five-
ring circus release validation process every two weeks. It's not just a
question of QA doing the testing, because of course testing without
fixes is meaningless: it's a question of QA, releng, and maintainers
all being perpetually in the 'ah crap it's two weeks before release'
frame of mind. Which isn't really sustainable on the current level, I
don't think.

But then, that doesn't mean we can't change things, it just means we
re-calibrate our expectations. We can release more often if we want to,
sure: we just have to be okay with each of those releases getting
somewhat less testing.

As Kevin noted upthread there *are* various ways in which we're
tackling automation of testing, which does help here. You can sketch a
beautiful picture where we build the distribution on CI principles: we
run a whole bunch of automated tests any time anyone sneezes on a
package, and anything that breaks gets rejected, and we can thus spin a
new release from the 'approved' bits any damn time we please and be
sure that it'd work. But, also as Kevin noted, I don't think we can
ever really achieve that perfectly; there's just too much in
distribution testing which isn't fully susceptible to automation, I
think at least in practical terms in the medium-term future there's
always gonna need to be some humans in the loop to some degree.

That doesn't mean we can't try and move in that direction, though. We
can keep building out the automation efforts to the point where we can
be pushing out 'releases' that we're fairly sure are at least basically
working very frequently. They wouldn't be as heavily tested as our
current traditional heavy 'releases' are, but they also wouldn't be
unknown quantities. In fact, since Flock, we've more or less been doing
this - any time you see a 'compose check report' email with a pretty
small number of openQA failures, you can grab that nightly build and be
reasonably sure that it will at least install and let you log in,
hardware issues excepted (openQA is all virt testing). There are short-
term plans already in place to improve this general area continuously:
releng is moving towards the nightly composes being much more like TCs
and RCs, QA is working to move openQA public, give it more resources,
and add more tests, Taskotron is definitely coming to a point soon
where it'll be feasible to do more forms of release testing in it, and
there are other mechanisms we're looking at too.

So yeah, if we want to start in *some* form releasing stuff more
frequently, it's possible. We have the technology, and we're making it
better quite frequently. I believe there are plans this cycle to
regularly publish updated Cloud (including Atomic host) images, which
will certainly form a starting point.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Jan Kurik]

​As I found this discussion interesting and I believe FESCo is the right
authority to help with this, I have opened a ticket ​
https://fedorahosted.org/fesco/ticket/1495 for the FESCo meeting on
Wednesday, to discuss it.

Regards,
Jan


On Mon, Nov 2, 2015 at 10:10 AM, Reindl Harald 
wrote:

>
>
> Am 02.11.2015 um 02:28 schrieb Sérgio Basto:
>
>> On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote:
>>
>>> On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto  wrote:
>>>
 On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:

> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
> ends, has been Fedora 23 Final-RC10 declared as GOLD.
> GA of this release is planed on Tuesday 2015-Nov-03.
>
> Today we got 531 updates for F23 , IMO, you should include it on Fedora
 23 Final before GA , doesn't make sense (to me) after download an ISO
 have 1/2 Giga of updates, but this happens since RedHad 9 at least .
 IMO, testing team should respin ISO with updates and testing again .
 I have some difficulty in following all development, fortunately Fedora
 is always at great speed, but it is not easy to follow. And do more
 tests we not lose anything, IMHO.

>>>
>>> The problem is we have to freeze sometime to ensure stability in the
>>> installer platform, the live and other images which are static. If not
>>> it's too much of a moving target to try and QA and ensure everything
>>> works as expected. To freeze is a fairly standard procedure for all
>>> distro development.
>>>
>>
>> Make an respin for F23 with stable updates, IMHO, should not break
>> anything, because at this stage, just stable things are being pushed
>>
>
> in theory
>
> it should be just one more loop in testing phase, anyway if breaks
>> something test team can freeze process again, until provide a  fix.
>>
>
> who does the work for *what* benefit?
> it's just wasting ressources and manpower
>
> who cares about the install ISO when you ave anyways to apply updates
> after or in the best case *due* setup
>
> This is not new !, respins of fedoraunity was an example and we already
>> have living respins [1], so we just need do new respin officially!.
>> Shouldn't be a big deal, If I'm not mistaken.
>>
>
> and fedoraunity finally gave up because lack of ressources
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Jonathan Underwood]

On 1 November 2015 at 22:14, Michael Catanzaro  wrote:
[snip]
> On Sun, 2015-11-01 at 20:03 +0100, Kevin Kofler wrote:
>> IMHO, we should have at most 1 week of strict freeze. If we decide
>> that we
>> have to slip anyway, then we should pull in ALL updates pending
>> stable and
>> restart the release process (freeze, spin RCs, test) from there.
>>
>> (That would also make it less painful to slip multiple times and thus
>> decrease the pressure to rush out quick hacks to work around blockers
>> instead of clean fixes.)
>
> I think Kevin is closer to right on this. It's unreasonable to have 500
> updates queued for users on release day. Yeah, freeze is required to do
> QA on the release, but QA on the release is not worth so much if it all
> goes out the door the first time someone clicks update. (Well, it's
> essential for the installation process, but beyond that)
>
[snip]

I think it is to some extent a question of what we are QA'ing for. As
I see it (and I may be in the minority), the QA process is a process
put in place to ensure the *install and live media* function
correctly, and produce a working installed system from which the user
can move forward with updates. QA has never made any efforts to QA
updates, presumably because there's just not sufficient resource. So,
in a resource limited world, I think the QA team are doing the most
sensible thing they can do with their limited resources.

In lieu of QA resource for updates, we have imperfect community
processes which we hope provide QA for subsequent updates, though
unfortunately the community base that has tested those 500 updates
that are available on release day are probably far less than for
updates produced after release, when more folks have the release
distro installed and are using it and testing updates. I think that's
the issue that we could address by engaging the community more though.
Any other proposal requiring more from the QA team has to identify
where that extra resource comes from.

Cheers,
Jonathan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Adrian Soliard]

2015-11-02 21:36 GMT-03:00 Kevin Fenzi :
> On Mon, 2 Nov 2015 21:33:45 -0300
> Adrian Soliard  wrote:
>
>> 've a question:
>>
>> Installing F23 RC10 is the same that wait to the final release? I'm
>> planning to install it now, tomorrow I will not have time to download
>> and install it.
>
> yes, rc10 was the exact release candidate that is the final release.
>

Thanks, Kevin.
Downloading...

> kevin
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
Adrian Soliard
asoli...@fedoraproject.org
https://fedoraproject.org/wiki/User:Asoliard
http://www.adriansoliard.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Adam Williamson]

On Mon, 2015-11-02 at 20:27 -0500, Eric Griffith wrote:
> Hey all, hate to be a downer but we might have a bug in the installer
> 
> Just installed F23 Workstation via RC10. Encryption with btrfs across
> two
> drives. Intel graphics (Lenovo t450s if anyone has access to one).
> Installed the system, rebooted into system. I get met with a black
> screen
> and the text
> 
> "Error: Can't find the command: /dev/mapper/luks-0be
> 
> Press any key to continue"
> 
> Boot continues forward without any action on users behalf, despite
> what is
> displayed. Plymouth never loads, text based loading. I got prompted
> for
> encryption passphrase, supply it, boot continues.
> 
> I get "A start job is running for dev-mapper-luks\(random
> characters).device ( (timer counter) / no limit)"
> 
> And then boot stalls with the counter incrementing. Will try a
> reinstall
> later tonight, but before I do that does anyone need / want debug
> info?
> Adam?

File a bug, I guess. I don't think we test encrypted btrfs - we test
btrfs, and we test encryption, but the brtfs tests don't specify
encryption and the encryption tests just use the default filesystem (so
ext4 or xfs).

The installer has lots of bugs. We know about some of them. ;)

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Adrian Soliard]

've a question:

Installing F23 RC10 is the same that wait to the final release? I'm
planning to install it now, tomorrow I will not have time to download
and install it.

2015-11-02 19:57 GMT-03:00 Adam Williamson :
> On Mon, 2015-11-02 at 10:52 -0700, Kevin Fenzi wrote:
>>
>> > Perhaps full release validation could occur on composes every two
>> > weeks for branched releases? Or is that still too demanding?
>>
>> No idea. I don't want to speak for the QA folks.
>
> So to put it simply and broadly: there's a trade-off between how often
> we want to release, and how heavily we can test those releases.
>
> Frankly, no, I don't think it's viable to do the entire current five-
> ring circus release validation process every two weeks. It's not just a
> question of QA doing the testing, because of course testing without
> fixes is meaningless: it's a question of QA, releng, and maintainers
> all being perpetually in the 'ah crap it's two weeks before release'
> frame of mind. Which isn't really sustainable on the current level, I
> don't think.
>
> But then, that doesn't mean we can't change things, it just means we
> re-calibrate our expectations. We can release more often if we want to,
> sure: we just have to be okay with each of those releases getting
> somewhat less testing.
>
> As Kevin noted upthread there *are* various ways in which we're
> tackling automation of testing, which does help here. You can sketch a
> beautiful picture where we build the distribution on CI principles: we
> run a whole bunch of automated tests any time anyone sneezes on a
> package, and anything that breaks gets rejected, and we can thus spin a
> new release from the 'approved' bits any damn time we please and be
> sure that it'd work. But, also as Kevin noted, I don't think we can
> ever really achieve that perfectly; there's just too much in
> distribution testing which isn't fully susceptible to automation, I
> think at least in practical terms in the medium-term future there's
> always gonna need to be some humans in the loop to some degree.
>
> That doesn't mean we can't try and move in that direction, though. We
> can keep building out the automation efforts to the point where we can
> be pushing out 'releases' that we're fairly sure are at least basically
> working very frequently. They wouldn't be as heavily tested as our
> current traditional heavy 'releases' are, but they also wouldn't be
> unknown quantities. In fact, since Flock, we've more or less been doing
> this - any time you see a 'compose check report' email with a pretty
> small number of openQA failures, you can grab that nightly build and be
> reasonably sure that it will at least install and let you log in,
> hardware issues excepted (openQA is all virt testing). There are short-
> term plans already in place to improve this general area continuously:
> releng is moving towards the nightly composes being much more like TCs
> and RCs, QA is working to move openQA public, give it more resources,
> and add more tests, Taskotron is definitely coming to a point soon
> where it'll be feasible to do more forms of release testing in it, and
> there are other mechanisms we're looking at too.
>
> So yeah, if we want to start in *some* form releasing stuff more
> frequently, it's possible. We have the technology, and we're making it
> better quite frequently. I believe there are plans this cycle to
> regularly publish updated Cloud (including Atomic host) images, which
> will certainly form a starting point.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
Adrian Soliard
asoli...@fedoraproject.org
https://fedoraproject.org/wiki/User:Asoliard
http://www.adriansoliard.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Kevin Kofler]

Michael Catanzaro wrote:
> My recommendation is the opposite of what Kevin would say, though. I'd
> like to see a third party responsible for giving final approval on all
> updates, charged with reducing the size of the updates pipe dramatically.
> Maintainers should not have final say on updates except in the event of a
> serious regression (in which case we need a revert button to skip
> updates-testing).

No thanks! If I wanted a distribution with such a strict control on updates, 
I'd use RHEL/CentOS, not Fedora! The fact that bugs actually get fixed in 
Fedora (whereas in conservative distributions, they often tell you to wait 
for the next release that comes months to years later) and that we even get 
new improved versions of applications is a huge advantage of Fedora, and 
also part of what Fedora is about (see "First"). Throwing it away would be a 
very bad idea.

I actually think we need a MORE update-friendly policy, where we recommend 
always pushing new versions unless there is a good reason not to. (The 
current policies are written the other way round, they recommend NOT pushing 
new feature releases unless there is a good reason to. I have been 
complaining about that right from the day it was written down.)

> An alternative we've been throwing around in the Workstation group is
> service packs (or "update packs") -- all non-security updates get bundled
> together, QAed, and released every 4-8 weeks. If you want to get your
> update out faster than that, you need a CVE or a special exception.

All that this accomplishes is delaying much needed fixes, it doesn't really 
solve any problem. It just creates new ones, such as dumping a huge set of 
updates on the user all at once, leading to bandwidth bottlenecks, and a 
higher risk of breakage on the flag days.

> Then we need to have separate release cycles for each product, since I
> don't want Workstation blocked indefinitely on everything
> Cloud/Server/KDE want to fix, and presumably those groups don't want to
> block on us... it's frankly annoying to me that we risk blocking
> Workstation on such issues, but it's a compromise we need to make to
> ensure the other releases are good. (And that vice-versa when the other
> releases get blocked on Workstation issues.) As long as we have four
> separate releases on the same cycle, it makes sense that QA gets final
> say.

This egoistical attitude is what is preventing us from shipping quality 
releases. The sky is not going to fall if your product/edition/spin gets 
released a couple weeks later. And with my proposed change to the release 
policy (slip = unfreeze, sync all updates, refreeze), you could also use the 
time to get fixes/improvements in that would have otherwise missed the 
release.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates (was Fedora 23 Final RC10 status is GO !)

[Kevin Kofler]

Michael Catanzaro wrote:
> Yeah, that's the clear disadvantage. The service pack approach
> sidesteps that problem: everything still goes out, just not so soon, so
> everything spends plenty of time in testing. All the bugs still get
> fixed, just not as fast.

And that's "better" HOW?

> (This also solves the problem of maintainers releasing individually
> -good updates too frequently.)

What problem? "too frequently" according to whom? I don't see any problem 
here, and I think updates (especially bugfixes) cannot be frequent enough.

> The counterargument is that we keep seeing major version updates that
> violate our existing updates policy.

This means the policy is broken, not the updates. I am glad that we are not 
following that policy to the letter, that's the only reason the system works 
at all! We need to encourage pushing new versions unless there is a good 
reason not to, including, but not limited to:
* incompatibility with existing data (including documents, config files,
  savegames, etc.),
* feature regressions (including deliberately removed features and features
  missing from a rewrite),
* major UI changes (but a menu item moving to some other place is harmless),
* new bugs (known in advance or found during testing) unless outweighed by
  the bugs that are fixed,
etc. If none of the above hold, then why would we not let the users benefit 
from the new features in the new version of the package? Upstream clearly 
considers it stable or they would not have released it as such.

> Who if not a neutral party charged with upholding that policy should have
> the final say? Some maintainers who clearly haven't read it?

I have read it. I just don't interpret it as being in contradiction with my 
updates. See e.g. Routino, which only went from 2.7.3 to 3.0 because it 
added a shared library (which in turn allows building new versions of 
applications such as qmapshack). The changes to the routing software itself 
are minor and almost entirely bugfixes. It is also compatible with databases 
from 2.7.3. (I NEVER push an update of Routino that is NOT database-
compatible!) I don't see any reason why the update would be a problem.

> If we have another party approving updates, then it's the maintainer's
> job to write an argument in favor of releasing the update: a quick
> summary of what the fix is and the regression potential. If the update
> gets rejected, the maintainer might really be wrong! and if not would
> have to try again to explain better. I think this would be good
> regardless of whether or not we do updates packs.

I think this would just be added bureaucracy and a royal PITA. Bodhi is 
already painful enough as it stands!

If you keep making it harder for packagers to do their job, you will find 
yourself losing packagers rapidly.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Eric Griffith]

Hey all, hate to be a downer but we might have a bug in the installer

Just installed F23 Workstation via RC10. Encryption with btrfs across two
drives. Intel graphics (Lenovo t450s if anyone has access to one).
Installed the system, rebooted into system. I get met with a black screen
and the text

"Error: Can't find the command: /dev/mapper/luks-0be

Press any key to continue"

Boot continues forward without any action on users behalf, despite what is
displayed. Plymouth never loads, text based loading. I got prompted for
encryption passphrase, supply it, boot continues.

I get "A start job is running for dev-mapper-luks\(random
characters).device ( (timer counter) / no limit)"

And then boot stalls with the counter incrementing. Will try a reinstall
later tonight, but before I do that does anyone need / want debug info?
Adam?

--Eric
On Nov 2, 2015 19:56, "Kevin Kofler"  wrote:

> Michael Catanzaro wrote:
> > My recommendation is the opposite of what Kevin would say, though. I'd
> > like to see a third party responsible for giving final approval on all
> > updates, charged with reducing the size of the updates pipe dramatically.
> > Maintainers should not have final say on updates except in the event of a
> > serious regression (in which case we need a revert button to skip
> > updates-testing).
>
> No thanks! If I wanted a distribution with such a strict control on
> updates,
> I'd use RHEL/CentOS, not Fedora! The fact that bugs actually get fixed in
> Fedora (whereas in conservative distributions, they often tell you to wait
> for the next release that comes months to years later) and that we even get
> new improved versions of applications is a huge advantage of Fedora, and
> also part of what Fedora is about (see "First"). Throwing it away would be
> a
> very bad idea.
>
> I actually think we need a MORE update-friendly policy, where we recommend
> always pushing new versions unless there is a good reason not to. (The
> current policies are written the other way round, they recommend NOT
> pushing
> new feature releases unless there is a good reason to. I have been
> complaining about that right from the day it was written down.)
>
> > An alternative we've been throwing around in the Workstation group is
> > service packs (or "update packs") -- all non-security updates get bundled
> > together, QAed, and released every 4-8 weeks. If you want to get your
> > update out faster than that, you need a CVE or a special exception.
>
> All that this accomplishes is delaying much needed fixes, it doesn't really
> solve any problem. It just creates new ones, such as dumping a huge set of
> updates on the user all at once, leading to bandwidth bottlenecks, and a
> higher risk of breakage on the flag days.
>
> > Then we need to have separate release cycles for each product, since I
> > don't want Workstation blocked indefinitely on everything
> > Cloud/Server/KDE want to fix, and presumably those groups don't want to
> > block on us... it's frankly annoying to me that we risk blocking
> > Workstation on such issues, but it's a compromise we need to make to
> > ensure the other releases are good. (And that vice-versa when the other
> > releases get blocked on Workstation issues.) As long as we have four
> > separate releases on the same cycle, it makes sense that QA gets final
> > say.
>
> This egoistical attitude is what is preventing us from shipping quality
> releases. The sky is not going to fall if your product/edition/spin gets
> released a couple weeks later. And with my proposed change to the release
> policy (slip = unfreeze, sync all updates, refreeze), you could also use
> the
> time to get fixes/improvements in that would have otherwise missed the
> release.
>
> Kevin Kofler
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Kevin Kofler]

I think official respins are a good idea, indeed. But:

Kevin Fenzi wrote:
> So, in order to do what you are wanting we need (at least) 3 things:
> 
> 1) releng has to make every daily compose a full compose of all
> deliverables. We have actually been working toward this, and perhaps
[snip]
> 2) QA would need to be able to do a full release validation on a set of
> deliverables _every day_. Again, we are making progress here, we have

Who said we'd have to do a respin every day? Having weekly, biweekly or 
monthly respins would be enough, as long as the updates keep flowing daily. 
Just do the respins only as often as resources (including QA) allow.

(And to those people who want to do "service packs": please focus your 
"service pack" testing on the respins instead, and don't break the existing 
update system that works fine.)

I found the existing live respins to be very helpful even though they are 
not done anywhere near daily. A simple yum/dnf update gets you fully up to 
date, and the respins decrease the amount of needed updates significantly.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Kevin Fenzi]

On Mon, 2 Nov 2015 21:33:45 -0300
Adrian Soliard  wrote:

> 've a question:
> 
> Installing F23 RC10 is the same that wait to the final release? I'm
> planning to install it now, tomorrow I will not have time to download
> and install it.

yes, rc10 was the exact release candidate that is the final release. 

kevin




pgptpyrl9Isee.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Peter Robinson]

On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto  wrote:
> On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:
>> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
>> ends, has been Fedora 23 Final-RC10 declared as GOLD.
>> GA of this release is planed on Tuesday 2015-Nov-03.
>>
> Today we got 531 updates for F23 , IMO, you should include it on Fedora
> 23 Final before GA , doesn't make sense (to me) after download an ISO
> have 1/2 Giga of updates, but this happens since RedHad 9 at least .
> IMO, testing team should respin ISO with updates and testing again .
> I have some difficulty in following all development, fortunately Fedora
> is always at great speed, but it is not easy to follow. And do more
> tests we not lose anything, IMHO.

The problem is we have to freeze sometime to ensure stability in the
installer platform, the live and other images which are static. If not
it's too much of a moving target to try and QA and ensure everything
works as expected. To freeze is a fairly standard procedure for all
distro development.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Kevin Kofler]

Peter Robinson wrote:
> The problem is we have to freeze sometime to ensure stability in the
> installer platform, the live and other images which are static. If not
> it's too much of a moving target to try and QA and ensure everything
> works as expected. To freeze is a fairly standard procedure for all
> distro development.

IMHO, we should have at most 1 week of strict freeze. If we decide that we 
have to slip anyway, then we should pull in ALL updates pending stable and 
restart the release process (freeze, spin RCs, test) from there.

(That would also make it less painful to slip multiple times and thus 
decrease the pressure to rush out quick hacks to work around blockers 
instead of clean fixes.)

I also think that the decision:
* when an image is a Go,
* what issues to consider as blockers and
* what new builds to take as freeze overrides
ought to be made by the WG/SIG responsible for the individual deliverable. 
(And this is NOT a personal power grab attempt. I am no longer a voting 
member of the KDE SIG, for reasons detailed on the kde mailing list.) The 
current process where the SIG/WG has to argue for every single freeze 
override they want to take in, and have rel-eng/QA reject some of them, is 
just broken (and there I can speak from experience, with my 8 years of KDE 
SIG involvement).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Digimer]

On 01/11/15 12:06 PM, Sérgio Basto wrote:
> On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:
>> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
>> ends, has been Fedora 23 Final-RC10 declared as GOLD.
>> GA of this release is planed on Tuesday 2015-Nov-03.
>>
> Today we got 531 updates for F23 , IMO, you should include it on Fedora
> 23 Final before GA , doesn't make sense (to me) after download an ISO
> have 1/2 Giga of updates, but this happens since RedHad 9 at least . 
> IMO, testing team should respin ISO with updates and testing again . 
> I have some difficulty in following all development, fortunately Fedora
> is always at great speed, but it is not easy to follow. And do more
> tests we not lose anything, IMHO.
> 
> 
> Thanks,

How does that compare to the normal volume of incoming updates? What I
mean is, if they re-rolled and re-tested, would a roughly similar number
of updates be waiting again?

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Sérgio Basto]

On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:
> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
> ends, has been Fedora 23 Final-RC10 declared as GOLD.
> GA of this release is planed on Tuesday 2015-Nov-03.
> 
Today we got 531 updates for F23 , IMO, you should include it on Fedora
23 Final before GA , doesn't make sense (to me) after download an ISO
have 1/2 Giga of updates, but this happens since RedHad 9 at least . 
IMO, testing team should respin ISO with updates and testing again . 
I have some difficulty in following all development, fortunately Fedora
is always at great speed, but it is not easy to follow. And do more
tests we not lose anything, IMHO.


Thanks,




> Meeting details can be seen here:
> Minutes:
> http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-30/f23-final-go_no_go-meeting_3.2015-10-30-16.00.html
> Log:
> http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-30/f23-final-go_no_go-meeting_3.2015-10-30-16.00.log.html
> 
> Thanks everyone who participated on this release!
> 
> 
> Regards,
> 
> Jan
> 
> -- 
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel-announce mailing list
> devel-annou...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel-announce

-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Michael Catanzaro]

On Sun, 2015-11-01 at 17:53 +, Peter Robinson wrote:
> The problem is we have to freeze sometime to ensure stability in the
> installer platform, the live and other images which are static. If
> not
> it's too much of a moving target to try and QA and ensure everything
> works as expected. To freeze is a fairly standard procedure for all
> distro development.

Yeah, but most distros stay frozen... to unfreeze after release -- let
alone with 500 updates on day zero! -- is something uniquely Fedora.

Really, only my updates should be allowed out to users. All of yours
should have to wait for the next release. Obviously not a serious
statement, but we all think our own updates are important, whereas
collectively it is important to Fedora to reduce the quantity of
updates. That implies individual maintainers shouldn't have final say
on updates

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Peter Gordon]

On 11/01/2015 09:06 AM, Sérgio Basto wrote:
> Today we got 531 updates for F23 , IMO, you should include it on Fedora
> 23 Final before GA , doesn't make sense (to me) after download an ISO
> have 1/2 Giga of updates, but this happens since RedHad 9 at least . 
> IMO, testing team should respin ISO with updates and testing again . 
> I have some difficulty in following all development, fortunately Fedora
> is always at great speed, but it is not easy to follow. And do more
> tests we not lose anything, IMHO.

Ideally, once the release is GA, deltarpms should mitigate most of the
download cost. Alternatively, you can use the netinstall ISO image
instead (usually about 450 MB or so), and then the newest versions of
packages in the repositories will be download on-demand during install
time. (You can also achieve this by adding the updates repository during
install time on a regular installer image.)

While recreating the installer with more updates may seem like a good
idea , unfortunately it requires more server resources and more
man-hours during which we'd have to freeze with that set of updates. I
feel that if we did that, by the time the testing for that respin is
complete, that new release will itself have a huge number of pending
updates and it could create a cycle of respin-test-respin-test-etc. that
would detract our already-limited community resources from advancing
toward the next release.

Regards.
-- 
Peter Gordon (codergeek42) 
Who am I? :: http://thecodergeek.com/about-me



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Sérgio Basto]

On Dom, 2015-11-01 at 17:53 +, Peter Robinson wrote:
> On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto  wrote:
> > On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:
> >> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
> >> ends, has been Fedora 23 Final-RC10 declared as GOLD.
> >> GA of this release is planed on Tuesday 2015-Nov-03.
> >>
> > Today we got 531 updates for F23 , IMO, you should include it on Fedora
> > 23 Final before GA , doesn't make sense (to me) after download an ISO
> > have 1/2 Giga of updates, but this happens since RedHad 9 at least .
> > IMO, testing team should respin ISO with updates and testing again .
> > I have some difficulty in following all development, fortunately Fedora
> > is always at great speed, but it is not easy to follow. And do more
> > tests we not lose anything, IMHO.
> 
> The problem is we have to freeze sometime to ensure stability in the
> installer platform, the live and other images which are static. If not
> it's too much of a moving target to try and QA and ensure everything
> works as expected. To freeze is a fairly standard procedure for all
> distro development.

Make an respin for F23 with stable updates, IMHO, should not break
anything, because at this stage, just stable things are being pushed. So
it should be just one more loop in testing phase, anyway if breaks
something test team can freeze process again, until provide a  fix.
This is not new !, respins of fedoraunity was an example and we already
have living respins [1], so we just need do new respin officially!.
Shouldn't be a big deal, If I'm not mistaken.



[1] http://alt.fedoraproject.org/pub/alt/live-respins/

> Peter

-- 
Sérgio M. B.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Michael Catanzaro]

On Sun, 2015-11-01 at 20:03 +0100, Kevin Kofler wrote:
> Peter Robinson wrote:
> > The problem is we have to freeze sometime to ensure stability in
> > the
> > installer platform, the live and other images which are static. If
> > not
> > it's too much of a moving target to try and QA and ensure
> > everything
> > works as expected. To freeze is a fairly standard procedure for all
> > distro development.
> 
> IMHO, we should have at most 1 week of strict freeze. If we decide
> that we 
> have to slip anyway, then we should pull in ALL updates pending
> stable and 
> restart the release process (freeze, spin RCs, test) from there.
> 
> (That would also make it less painful to slip multiple times and thus
> decrease the pressure to rush out quick hacks to work around blockers
> instead of clean fixes.)

I think Kevin is closer to right on this. It's unreasonable to have 500
updates queued for users on release day. Yeah, freeze is required to do
QA on the release, but QA on the release is not worth so much if it all
goes out the door the first time someone clicks update. (Well, it's
essential for the installation process, but beyond that)

I will say: Fedora has the *best* release QA *by far* of any comparable 
community distro -- maybe even better than Debian! -- but we all know our 
updates break things all the time. In F22, we had at least two (I think 
actually three, but I lost count) separate updates that broke the ability to 
apply further (PackageKit) updates. Come on! We have to fix this for OEMs to 
have any confidence in shipping Fedora. (At least, I'd like to see Fedora in 
stores, and I think I'm not the only one)

My recommendation is the opposite of what Kevin would say, though. I'd like to 
see a third party responsible for giving final approval on all updates, charged 
with reducing the size of the updates pipe dramatically. Maintainers should not 
have final say on updates except in the event of a serious regression (in which 
case we need a revert button to skip updates-testing).

An alternative we've been throwing around in the Workstation group is service 
packs (or "update packs") -- all non-security updates get bundled together, 
QAed, and released every 4-8 weeks. If you want to get your update out faster 
than that, you need a CVE or a special exception.

> I also think that the decision:
> * when an image is a Go,
> * what issues to consider as blockers and
> * what new builds to take as freeze overrides
> ought to be made by the WG/SIG responsible for the individual
> deliverable. 
> (And this is NOT a personal power grab attempt. I am no longer a
> voting 
> member of the KDE SIG, for reasons detailed on the kde mailing list.)
> The 
> current process where the SIG/WG has to argue for every single freeze
> override they want to take in, and have rel-eng/QA reject some of
> them, is 
> just broken (and there I can speak from experience, with my 8 years
> of KDE 
> SIG involvement).

Then we need to have separate release cycles for each product, since I
don't want Workstation blocked indefinitely on everything
Cloud/Server/KDE want to fix, and presumably those groups don't want to
block on us... it's frankly annoying to me that we risk blocking
Workstation on such issues, but it's a compromise we need to make to
ensure the other releases are good. (And that vice-versa when the other
releases get blocked on Workstation issues.) As long as we have four
separate releases on the same cycle, it makes sense that QA gets final
say.

Besides, they're the ones testing the thing.

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 23 Final RC10 status is GO !

[Reindl Harald]

Am 01.11.2015 um 23:20 schrieb Michael Catanzaro:

On Sun, 2015-11-01 at 17:53 +, Peter Robinson wrote:

The problem is we have to freeze sometime to ensure stability in the
installer platform, the live and other images which are static. If
not
it's too much of a moving target to try and QA and ensure everything
works as expected. To freeze is a fairly standard procedure for all
distro development.


Yeah, but most distros stay frozen... to unfreeze after release -- let
alone with 500 updates on day zero! -- is something uniquely Fedora.

Really, only my updates should be allowed out to users. All of yours
should have to wait for the next release. Obviously not a serious
statement, but we all think our own updates are important, whereas
collectively it is important to Fedora to reduce the quantity of
updates. That implies individual maintainers shouldn't have final say
on updates


nonsense

if individual should not have final say on updates one could use also 
Debian and *not* Fedora - the is no perfect reason because issues are 
different


refrain from updates may keep annoying bugs currently in Fedora fixed 
soon and updates *may* introduce new bugs


*who* if not the package maintainer which hopefully uses his own 
packages should have the final say? some group of people not 
understanding the issues really?




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Updates (was Fedora 23 Final RC10 status is GO !)

[Reindl Harald]

Am 02.11.2015 um 00:36 schrieb Michael Catanzaro:

*who* if not the package maintainer which hopefully uses his own
packages should have the final say? some group of people not
understanding the issues really?


The counterargument is that we keep seeing major version updates that
violate our existing updates policy. Who if not a neutral party charged
with upholding that policy should have the final say? Some maintainers
who clearly haven't read it?


and what about software not breaking randomly?

a version number don't say *anything* about the impact of a update - 
there are stol developers out there which are able to provide new 
feautures without breaking everything left and right


show me as example *one* postfix major update in the last 10 years 
breaking existing setups - not every upstream acts like GNOME




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 23 Final RC10 status is GO !

[Jan Kurik]

At the third round of Fedora 23 Final Go/No-Go Meeting, that just ends, has
been Fedora 23 Final-RC10 declared as GOLD.
GA of this release is planed on Tuesday 2015-Nov-03.

Meeting details can be seen here:
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-30/f23-final-go_no_go-meeting_3.2015-10-30-16.00.html
Log:
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-10-30/f23-final-go_no_go-meeting_3.2015-10-30-16.00.log.html


Thanks everyone who participated on this release!

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct