7:55 p.m.
Hi all,
Today's an important day on the Fedora 31 schedule[1], with several
significant cut-offs. First of all today is
the Bodhi activation point [2]. That means that from now all Fedora 31
packages must be submitted to
updates-testing and pass the relevant requirements[3] before they will be
marked as 'stable' and moved to the
fedora repository.
Today is also the Beta freeze[4]. This means that only packages which fix
accepted blocker or freeze exception
bugs[5][6] will be marked as 'stable' and included in the Beta composes.
Other builds will remain in updates-
testing until the Beta release is approved, at which point the Beta freeze
is lifted and packages can move to
'stable' as usual until the Final freeze.
Finally, Today is the '100% code complete deadline' Change Checkpoint[5],
meaning that Fedora 31 Changes
must now be code complete, meaning all the code required to enable to the
new change is finished. The level
of code completeness is reflected as tracker bug state ON_QA. The change
does not have to be fully tested
by this deadline'.
Finally, today is also the Software String freeze[7], which means that
strings marked for translation in Fedora-
translated projects should not now be changed for Fedora 31.
Mohan Boddu
[1] https://fedoraproject.org/wiki/Releases/31/Schedule
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
_______________________________________________
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test-announce@lists.fedorap...
5:43 a.m.
Mohan Boddu wrote on 2019/08/27 9:55:
Hi all,
<snip>
Today is also the Beta freeze[4]. This means that only packages which fix
accepted blocker or freeze exception
bugs[5][6] will be marked as 'stable' and included in the Beta composes.
Other builds will remain in updates-
testing until the Beta release is approved, at which point the Beta freeze
is lifted and packages can move to
'stable' as usual until the Final freeze.
[1] https://fedoraproject.org/wiki/Releases/31/Schedule
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
Well, the above [1] says 2019/08/27 is beta freeze, however python people
seem to be saying that beta freeze is 2019/08/29, as said in [8] and [9]
(and so I thought beta freeze was 2019/08/29 as such emails were repeatedly
sent to me). Which is correct?
[8]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
[9] https://bugzilla.redhat.com/show_bug.cgi?id=1701888#c6
Regards,
Mamoru
5:50 a.m.
On Tue, Aug 27, 2019 at 4:14 PM Mamoru TASAKA <mtasaka(a)fedoraproject.org>
wrote:
Mohan Boddu wrote on 2019/08/27 9:55:
> Hi all,
<snip>
>
>
> Today is also the Beta freeze[4]. This means that only packages which fix
> accepted blocker or freeze exception
> bugs[5][6] will be marked as 'stable' and included in the Beta composes.
> Other builds will remain in updates-
> testing until the Beta release is approved, at which point the Beta
freeze
> is lifted and packages can move to
> 'stable' as usual until the Final freeze.
>
>
> [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> [2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
> [3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
> [4] https://fedoraproject.org/wiki/Milestone_freezes
> [5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
> [6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
> [7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
>
>
Well, the above [1] says 2019/08/27 is beta freeze, however python people
seem to be saying that beta freeze is 2019/08/29, as said in [8] and [9]
(and so I thought beta freeze was 2019/08/29 as such emails were repeatedly
sent to me). Which is correct?
I too got confused because I have already recorded 29th August as Beta
Freeze in my calendar. I see that Ben has edited the Schedule page[1] but I
am yet to see if there is any accompanying FESCo ticket approval for this
change.
Regards,
Parag
[1]
https://fedoraproject.org/w/index.php?title=Releases%2F31%2FSchedule&...
6:30 a.m.
On 27. 08. 19 12:50, Parag Nemade wrote:> I too got confused because I have
already recorded 29th August as Beta Freeze in
my calendar. I see that Ben has edited the Schedule page[1] but I am
yet to see
if there is any accompanying FESCo ticket approval for this change.
That totally confused me as well. Technically, it was approved by fesco to be on
the 27th since the beginning, it was just wrongly marked in the wiki.
The wiki indeed says: "The authoritative schedule is on Fedora People."
https://fedorapeople.org/groups/schedule/f-31/f-31-key-tasks.html
But I think people actually just look at the wiki.
I've proposed yesterday to actually start the freeze on the 29th to unconfuse
people, but there was no useful reply.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:30 a.m.
Dne 27. 08. 19 v 12:50 Parag Nemade napsal(a):
On Tue, Aug 27, 2019 at 4:14 PM Mamoru TASAKA
<mtasaka(a)fedoraproject.org <mailto:mtasaka@fedoraproject.org>> wrote:
Mohan Boddu wrote on 2019/08/27 9:55:
> Hi all,
<snip>
>
>
> Today is also the Beta freeze[4]. This means that only packages
which fix
> accepted blocker or freeze exception
> bugs[5][6] will be marked as 'stable' and included in the Beta
composes.
> Other builds will remain in updates-
> testing until the Beta release is approved, at which point the
Beta freeze
> is lifted and packages can move to
> 'stable' as usual until the Final freeze.
>
>
> [1] https://fedoraproject.org/wiki/Releases/31/Schedule
> [2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
> [3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
> [4] https://fedoraproject.org/wiki/Milestone_freezes
> [5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
> [6]
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
> [7]
https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
>
>
Well, the above [1] says 2019/08/27 is beta freeze, however python
people
seem to be saying that beta freeze is 2019/08/29, as said in [8]
and [9]
(and so I thought beta freeze was 2019/08/29 as such emails were
repeatedly
sent to me). Which is correct?
I too got confused because I have already recorded 29th August as Beta
Freeze in my calendar. I see that Ben has edited the Schedule page[1]
but I am yet to see if there is any accompanying FESCo ticket approval
for this change.
I think that all the major milestones happen typically on Tuesday, so
this must have been (unfortunate) typo IMO.
Vít
Regards,
Parag
[1]
https://fedoraproject.org/w/index.php?title=Releases%2F31%2FSchedule&...
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
7:31 p.m.
Vít Ondruch wrote:
I think that all the major milestones happen typically on Tuesday,
so
this must have been (unfortunate) typo IMO.
But the point is that this was corrected less than 24 hours before the
freeze kicks in. This is a completely unacceptably short notice.
It is already bad enough that Fedora freezes happen on 00:00 UTC on the
announced day as opposed to 24:00 UTC as used in almost all other projects
(and fixing that would not even require any kind of procedure or policy
change, it would just require subtracting 1 from all the freeze dates that
get posted on the wiki!), which caught several of us off guard more than
once (yet, nobody even bothered replying to my requests to fix that), but
now even that can no longer be trusted because the posted dates get "fixed"
with a 0-day notice.
IMHO, the right thing to do would be to quickly postpone the freeze (i.e.,
unfreeze where necessary) by a whole week, then it's still on midnight from
Monday to Tuesday as usual, but people will have gotten a reasonable
advanced notice.
Kevin Kofler
12:30 p.m.
On 8/27/19 5:31 PM, Kevin Kofler wrote:
Vít Ondruch wrote:
> I think that all the major milestones happen typically on Tuesday, so
> this must have been (unfortunate) typo IMO.
But the point is that this was corrected less than 24 hours before the
freeze kicks in. This is a completely unacceptably short notice.
It is already bad enough that Fedora freezes happen on 00:00 UTC on the
announced day as opposed to 24:00 UTC as used in almost all other projects
24:00 does not exist? Or to me it makes as little sense as 00:00.
(and fixing that would not even require any kind of procedure or
policy
change, it would just require subtracting 1 from all the freeze dates that
get posted on the wiki!), which caught several of us off guard more than
once (yet, nobody even bothered replying to my requests to fix that), but
now even that can no longer be trusted because the posted dates get "fixed"
with a 0-day notice.
I'd support changing the freeze dates to be something more like 18:00UTC
the date they are listed. That would give people more time/be actually
on the date when people are awake. I'll float the idea to releng and
then fesco.
IMHO, the right thing to do would be to quickly postpone the freeze (i.e.,
unfreeze where necessary) by a whole week, then it's still on midnight from
Monday to Tuesday as usual, but people will have gotten a reasonable
advanced notice.
I'm not sure thats very possible (at least it would be difficult to undo
some things).
I'd suppport doing another stable push before we go into freeze tho...
there's a fesco ticket where I suggested that.
kevin
1:05 p.m.
On Thu, Aug 29, 2019 at 1:31 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
24:00 does not exist? Or to me it makes as little sense as 00:00.
You're technically correct, which Futurama taught me is the best kind
of correct. I've seen it to mean "midnight at the end of the day" in
order to distinguish from "midnight at the beginning of the day". It's
functionally equivalent to 23:59:59.999999.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1:43 p.m.
On 8/29/19 11:05 AM, Ben Cotton wrote:
On Thu, Aug 29, 2019 at 1:31 PM Kevin Fenzi <kevin(a)scrye.com>
wrote:
>
> 24:00 does not exist? Or to me it makes as little sense as 00:00.
>
You're technically correct, which Futurama taught me is the best kind
of correct. I've seen it to mean "midnight at the end of the day" in
order to distinguish from "midnight at the beginning of the day". It's
functionally equivalent to 23:59:59.999999.
well, but more importantly, what day is it on?
If I say:
2019-08-20 at 00:00UTC I think I can guess this to be the very start of
that day, perhaps?
2019-08-29 at 24:00UTC is... what? the last miliseconds of that day and
thus really right next to 2019-08-30 00:00UTC?
If I say: 2019-09-29 at 18:00UTC we all know what time I mean I think,
or at least it's more clear than 00:00 and 24:00.
kevin
2:23 p.m.
On Thu, Aug 29, 2019 at 12:44 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On 8/29/19 11:05 AM, Ben Cotton wrote:
> On Thu, Aug 29, 2019 at 1:31 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
>>
>> 24:00 does not exist? Or to me it makes as little sense as 00:00.
>>
> You're technically correct, which Futurama taught me is the best kind
> of correct. I've seen it to mean "midnight at the end of the day" in
> order to distinguish from "midnight at the beginning of the day".
It's
> functionally equivalent to 23:59:59.999999.
>
well, but more importantly, what day is it on?
If I say:
2019-08-20 at 00:00UTC I think I can guess this to be the very start of
that day, perhaps?
2019-08-29 at 24:00UTC is... what? the last miliseconds of that day and
thus really right next to 2019-08-30 00:00UTC?
If I say: 2019-09-29 at 18:00UTC we all know what time I mean I think,
or at least it's more clear than 00:00 and 24:00.
I can't say I ever came across 2400Z in aviation, but from reading
military stuff, 0000 hours and 2400 hours are the exact same moment in
time and which gets used is determined by context. I'd say "my shift
ends August 29 at 2400 hours, and Joe's starts August 30 at 0000
hours" and it's the exact same moment in time (assuming UTC, zulu, or
the same time zone).
--
Chris Murphy
4:51 p.m.
Kevin Fenzi wrote:
If I say:
2019-08-20 at 00:00UTC I think I can guess this to be the very start of
that day, perhaps?
2019-08-29 at 24:00UTC is... what? the last miliseconds of that day and
thus really right next to 2019-08-30 00:00UTC?
2019-08-29 24:00UTC = 2019-08-30 00:00UTC
The idea of the 24:00 (or 23:59 if you prefer) deadlines is that if the
deadline is given as 2019-08-29, you actually have until 2019-08-29 included
to publish your change, whereas using the 00:00 formulation means that the
exact same deadline would be listed as 2019-08-30, but 2019-08-30 is already
too late for your changes.
E.g., KDE Applications uses 23:59 UTC deadlines:
https://community.kde.org/Schedules/Applications/19.08_Release_Schedule
If I say: 2019-09-29 at 18:00UTC we all know what time I mean I
think,
or at least it's more clear than 00:00 and 24:00.
A deadline within the day is the other alternative (used, e.g., by KDE
Plasma: https://community.kde.org/Schedules/Plasma_5 – I presume "midday
UTC" means 12:00 noon UTC), but IMHO it is more confusing than a 23:59/24:00
deadline, and for Fedora, it would actually mean a procedure change contrary
to my proposal.
For academic paper submissions, I have also seen both kinds of deadlines
(23:59/24:00 deadlines and mid-day (12:00 noon or some other arbitrary time)
deadlines), but never the confusing 00:00 deadlines used by Fedora.
Kevin Kofler
2:08 a.m.
On 8/29/19 8:30 PM, Kevin Fenzi wrote:
I'd support changing the freeze dates to be something more like
18:00UTC
the date they are listed. That would give people more time/be actually
on the date when people are awake. I'll float the idea to releng and
then fesco.
That would be awesome.
It's really annoying to wake up to find a freeze reminder in your inbox
when the freeze already happened. At least, as I also understand 00:00
to be the first second of a new day.
- Panu -
5:03 a.m.
On Fri, 2019-08-30 at 10:08 +0300, Panu Matilainen wrote:
On 8/29/19 8:30 PM, Kevin Fenzi wrote:
> I'd support changing the freeze dates to be something more like 18:00UTC
> the date they are listed. That would give people more time/be actually
> on the date when people are awake. I'll float the idea to releng and
> then fesco.
>
That would be awesome.
It's really annoying to wake up to find a freeze reminder in your inbox
when the freeze already happened. At least, as I also understand 00:00
to be the first second of a new day.
We also hit this at least once with Anaconda
in the past as we are basically
setting an internal deadline a day before the freez date to avoid any such surprises.
Just setting the freeze data on some sane time point would make think clear and we could
stop doing that. :)
- Panu -
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
6:59 a.m.
Panu Matilainen wrote:
On 8/29/19 8:30 PM, Kevin Fenzi wrote:
> I'd support changing the freeze dates to be something more like 18:00UTC
> the date they are listed. That would give people more time/be actually
> on the date when people are awake. I'll float the idea to releng and
> then fesco.
>
That would be awesome.
But wouldn't 24:00/23:59 be even better than 18:00? And changing from 00:00
to 24:00 wouldn't even require changing the actual time (as changing to
18:00 does), just the way it is announced.
It's really annoying to wake up to find a freeze reminder in your
inbox
when the freeze already happened.
Well, that one is really a different issue, that there is an announcement
when the freeze has happened, but no reminder before it happens. Changing
the time of the freeze won't really fix this, sending one or more reminder
mails before the freeze time would. But of course there's also a tradeoff in
that the reminders should not become spam.
Kevin Kofler
7:25 a.m.
On Fri, 2019-08-30 at 13:59 +0200, Kevin Kofler wrote:
Panu Matilainen wrote:
> On 8/29/19 8:30 PM, Kevin Fenzi wrote:
> > I'd support changing the freeze dates to be something more like 18:00UTC
> > the date they are listed. That would give people more time/be actually
> > on the date when people are awake. I'll float the idea to releng and
> > then fesco.
> >
>
> That would be awesome.
But wouldn't 24:00/23:59 be even better than 18:00? And changing from 00:00
to 24:00 wouldn't even require changing the actual time (as changing to
18:00 does), just the way it is announced.
I would personally still find even 24:00
confusing & would really suggest something
clearly inambigous, such as 23:45 UTC or similar - that should clear any doubt of which
day
the freeze is part of once and for all & yet again no actualy changes in the machinery
are needed.
> It's really annoying to wake up to find a freeze reminder in your inbox
> when the freeze already happened.
Well, that one is really a different issue, that there is an announcement
when the freeze has happened, but no reminder before it happens. Changing
the time of the freeze won't really fix this, sending one or more reminder
mails before the freeze time would. But of course there's also a tradeoff in
that the reminders should not become spam.
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
10:10 a.m.
On 8/30/19 8:25 AM, Martin Kolman wrote:
But wouldn't 24:00/23:59 be even better than 18:00? And changing
from 00:00
to 24:00 wouldn't even require changing the actual time (as changing to
18:00 does), just the way it is announced.
That is a little confusing in my opinion.
I would like to suggest this wording:
The deadline is 18:00 UTC, with a six hour grace period
3:49 p.m.
On Fri, Aug 30, 2019 at 6:26 AM Martin Kolman <mkolman(a)redhat.com> wrote:
I would personally still find even 24:00 confusing & would really suggest something
clearly inambigous, such as 23:45 UTC or similar - that should clear any doubt of which
day
the freeze is part of once and for all & yet again no actualy changes in the
machinery are needed.
2400 is totally confusing, I'm only finding it used in military
contexts and even there it seems to be vernacular. I'd rather be
surprised if military police use it.
But anyway, I did laugh a bit out loud at 23:45 UTC because *of
course* there are many other totally unambiguous times to choose from
instead. Some of the best comedy is pointing out the obvious.
My suggestion would be, without respect to preference, 0015 UTC, 0030
UTC, or 0100 UTC. And that's only because it acts like a kind of grace
period for anyone used to 0000 UTC, not paying attention to this
thread, and maybe misses the next announcement.
--
Chris Murphy
3:22 a.m.
Chris Murphy wrote:
2400 is totally confusing, I'm only finding it used in military
contexts and even there it seems to be vernacular. I'd rather be
surprised if military police use it.
Then just write 23:59 instead.
My suggestion would be, without respect to preference, 0015 UTC,
0030
UTC, or 0100 UTC. And that's only because it acts like a kind of grace
period for anyone used to 0000 UTC, not paying attention to this
thread, and maybe misses the next announcement.
A one-hour (or less) "grace period" in the middle of the night is entirely
useless.
Kevin Kofler
3:44 a.m.
On Sat, Aug 31, 2019 at 10:22:32AM +0200, Kevin Kofler wrote:
Chris Murphy wrote:
> 2400 is totally confusing, I'm only finding it used in military
> contexts and even there it seems to be vernacular. I'd rather be
> surprised if military police use it.
Then just write 23:59 instead.
+1.
(I asked a few people what 24:00 means to them, and after getting a
few strange looks and answers, I'm convinced that 23:59 is much
better. (It's only English-speaking people who are confused.
I think this stems from US imperial culture, where 12:00 PM is noon,
and 12:00 AM is midnight. It is labelling the boundary of a range with
a value from the neighbouring range, which is ... bleh. But the
confusion is unlikely to go away, so let's just avoid this.))
I also think 23:59 UTC (i.e. ~midnight UTC) is the best choice of the
actual time. We generally specify almost all times in UTC in Fedora,
and using a different timezone for this important date would be
confusing.
Contributors are primarily located in Europe and US, so midnight UTC
is 2 AM, 8 PM, or 5 PM, which is something like "close of the business
day", and I think it's nice the start the freeze at that time.
Zbyszek
> > My suggestion would be, without respect to preference, 0015 UTC, 0030
> > UTC, or 0100 UTC. And that's only because it acts like a kind of grace
> > period for anyone used to 0000 UTC, not paying attention to this
> > thread, and maybe misses the next announcement.
>
> A one-hour (or less) "grace period" in the middle of the night is entirely
> useless.
3:52 a.m.
On Sat, Aug 31, 2019, 10:46 Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>
wrote:
On Sat, Aug 31, 2019 at 10:22:32AM +0200, Kevin Kofler wrote:
> Chris Murphy wrote:
> > 2400 is totally confusing, I'm only finding it used in military
> > contexts and even there it seems to be vernacular. I'd rather be
> > surprised if military police use it.
>
> Then just write 23:59 instead.
+1.
Agreed. Let's make it 23:59 on Monday.
Kalev
1:43 p.m.
On 8/31/19 1:52 AM, Kalev Lember wrote:
On Sat, Aug 31, 2019, 10:46 Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl>
wrote:
> On Sat, Aug 31, 2019 at 10:22:32AM +0200, Kevin Kofler wrote:
>> Chris Murphy wrote:
>>> 2400 is totally confusing, I'm only finding it used in military
>>> contexts and even there it seems to be vernacular. I'd rather be
>>> surprised if military police use it.
>>
>> Then just write 23:59 instead.
>
> +1.
>
Agreed. Let's make it 23:59 on Monday.
So, we are moving it one minute earlier? If it's listed as tuesday on
the schedule it should be 23:59 on tuesday at least. :)
I would still like a bit earlier so releng folks don't need to work at
night. Perhaps 20UTC could be a ok compromise?
kevin
2:32 p.m.
On Sat, Aug 31, 2019 at 8:45 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On 8/31/19 1:52 AM, Kalev Lember wrote:
> On Sat, Aug 31, 2019, 10:46 Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl>
> wrote:
>
>> On Sat, Aug 31, 2019 at 10:22:32AM +0200, Kevin Kofler wrote:
>>> Chris Murphy wrote:
>>>> 2400 is totally confusing, I'm only finding it used in military
>>>> contexts and even there it seems to be vernacular. I'd rather be
>>>> surprised if military police use it.
>>>
>>> Then just write 23:59 instead.
>>
>> +1.
>>
>
> Agreed. Let's make it 23:59 on Monday.
So, we are moving it one minute earlier? If it's listed as tuesday on
the schedule it should be 23:59 on tuesday at least. :)
Yes, just move it one minute earlier and list Monday as the start of the
freeze in the schedule. This would, In my opinion, fix all the schedule
confusion.
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Kalev
2:42 p.m.
On Sat, Aug 31, 2019 at 8:45 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
So, we are moving it one minute earlier? If it's listed as
tuesday on
the schedule it should be 23:59 on tuesday at least. :)
I would still like a bit earlier so releng folks don't need to work at
night. Perhaps 20UTC could be a ok compromise?
I don't have a strong preference about 20:00 UTC vs 23:59 UTC. Moving it 4
hours earlier would obviously be a slightly bigger schedule change. Above
all, I'd just like to fix the schedule confusion and moving it one minute
earlier would be an easy fix for that. Let's just make sure we do the easy
fix if we can't get a consensus on the larger 4-hour change.
Kalev
4:50 a.m.
Le 2019-08-31 10:44, Zbigniew Jędrzejewski-Szmek a écrit :
(I asked a few people what 24:00 means to them, and after getting a
few strange looks and answers,
To be fair:
1. ISO 8501 allows writing 24:00
Wikipedia> Midnight is a special case and may be referred to as either
"00:00" or "24:00". The notation "00:00"
Wikipedia> is used at the beginning of a calendar day and is the more
frequently used. At the end of a day use
Wikipedia> "24:00". "2007-04-05T24:00" is the same instant as
"2007-04-06T00:00"
2. However the IETF explicitely forbid it when defining the ISO 8501
subset allowed on the Internet
RFC 3339> Although ISO 8601 permits the hour to be "24", this profile of
ISO
RFC 3339> 8601 only allows values between "00" and "23" for the
hour in
order
RFC 3339> to reduce confusion.
Therefore, banning the 24:00 notation is necessary for interoperability,
even if one does not agree with the IETF decision. (00:00 however is
well-defined and not ambiguous)
Regards,
--
Nicolas Mailhot
12:27 p.m.
Nicolas Mailhot via devel wrote:
2. However the IETF explicitely forbid it when defining the ISO 8501
subset allowed on the Internet
RFC 3339> Although ISO 8601 permits the hour to be "24", this profile of
ISO
RFC 3339> 8601 only allows values between "00" and "23" for the
hour in
order
RFC 3339> to reduce confusion.
Therefore, banning the 24:00 notation is necessary for interoperability,
even if one does not agree with the IETF decision. (00:00 however is
well-defined and not ambiguous)
IETF RFCs are only relevant for software. Humans need to comply only with
ISO standards.
RFC 3339 specifically only claims to be about "representing and using date
and time in Internet protocols", not on websites (which are just an
arbitrary unformatted payload as far as the HTTPS protocol is concerned).
Kevin Kofler
3:09 a.m.
Le 2019-09-02 19:27, Kevin Kofler a écrit :
Nicolas Mailhot via devel wrote:
> 2. However the IETF explicitely forbid it when defining the ISO 8501
> subset allowed on the Internet
>
> RFC 3339> Although ISO 8601 permits the hour to be "24", this profile
> of
> ISO
> RFC 3339> 8601 only allows values between "00" and "23" for
the hour
> in
> order
> RFC 3339> to reduce confusion.
>
> Therefore, banning the 24:00 notation is necessary for
> interoperability,
> even if one does not agree with the IETF decision. (00:00 however is
> well-defined and not ambiguous)
IETF RFCs are only relevant for software. Humans need to comply only
with
ISO standards.
Humans need not comply with anything, they have free will, however it
helps out if they exert their will wisely.
And when the IETF forbids using 24h to avoid confusion do you really
thing it is writing about software? Software does not get confused,
software is dumb as a brick, people get confused.
RFC 3339 specifically only claims to be about "representing and
using
date
and time in Internet protocols", not on websites (which are just an
arbitrary unformatted payload as far as the HTTPS protocol is
concerned).
In this date and age is it quite naïve to think the data on a website is
for human consumption only and will never be plugged on a message bus,
an API, or whatever is the buzzword of the day for automated processing
Regards,
--
Nicolas Mailhot
6:23 p.m.
>>>> "CM" == Chris Murphy
<lists(a)colorremedies.com> writes:
CM> But anyway, I did laugh a bit out loud at 23:45 UTC because *of
CM> course* there are many other totally unambiguous times to choose
CM> from instead. Some of the best comedy is pointing out the obvious.
If we're going to bikeshed it, I'll vote for two minutes to midnight.
- J<
6:06 a.m.
On Mon, 26 Aug 2019 20:55:18 -0400
Mohan Boddu <mboddu(a)bhujji.com> wrote:
Hi all,
Today's an important day on the Fedora 31 schedule[1], with several
significant cut-offs. First of all today is
the Bodhi activation point [2]. That means that from now all Fedora 31
packages must be submitted to
updates-testing and pass the relevant requirements[3] before they
will be marked as 'stable' and moved to the
fedora repository.
I don't know if this is related but the Rawhide (f32) builds I've done
today (e.g. perl-MCE-1.846-1.fc32) don't seem to be going through the
gating process and into rawhide.
$ koji -q list-tagged --latest f32-updates-candidate perl-MCE
perl-MCE-1.846-1.fc32 f32-updates-candidate pghmcfc
$ koji -q list-tagged --latest f32 perl-MCE
perl-MCE-1.845-1.fc32 f32 pghmcfc
Paul.
6:27 a.m.
On 27. 08. 19 13:06, Paul Howarth wrote:
On Mon, 26 Aug 2019 20:55:18 -0400
Mohan Boddu <mboddu(a)bhujji.com> wrote:
> Hi all,
>
> Today's an important day on the Fedora 31 schedule[1], with several
> significant cut-offs. First of all today is
> the Bodhi activation point [2]. That means that from now all Fedora 31
> packages must be submitted to
> updates-testing and pass the relevant requirements[3] before they
> will be marked as 'stable' and moved to the
> fedora repository.
I don't know if this is related but the Rawhide (f32) builds I've done
today (e.g. perl-MCE-1.846-1.fc32) don't seem to be going through the
gating process and into rawhide.
$ koji -q list-tagged --latest f32-updates-candidate perl-MCE
perl-MCE-1.846-1.fc32 f32-updates-candidate pghmcfc
$ koji -q list-tagged --latest f32 perl-MCE
perl-MCE-1.845-1.fc32 f32 pghmcfc
https://pagure.io/fedora-infrastructure/issue/8138
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
7:52 p.m.
On 8/27/19 4:27 AM, Miro Hrončok wrote:
On 27. 08. 19 13:06, Paul Howarth wrote:
> On Mon, 26 Aug 2019 20:55:18 -0400
> Mohan Boddu <mboddu(a)bhujji.com> wrote:
>
>> Hi all,
>>
>> Today's an important day on the Fedora 31 schedule[1], with several
>> significant cut-offs. First of all today is
>> the Bodhi activation point [2]. That means that from now all Fedora 31
>> packages must be submitted to
>> updates-testing and pass the relevant requirements[3] before they
>> will be marked as 'stable' and moved to the
>> fedora repository.
>
> I don't know if this is related but the Rawhide (f32) builds I've done
> today (e.g. perl-MCE-1.846-1.fc32) don't seem to be going through the
> gating process and into rawhide.
>
> $ koji -q list-tagged --latest f32-updates-candidate perl-MCE
> perl-MCE-1.846-1.fc32 f32-updates-candidate pghmcfc
>
> $ koji -q list-tagged --latest f32 perl-MCE
> perl-MCE-1.845-1.fc32 f32 pghmcfc
https://pagure.io/fedora-infrastructure/issue/8138
This was fixed earlier today, sorry for not circling back and noting
that here.
I think everything should be processed that was stuck, if anyone sees
anything amiss, please let me know here, in email or via a releng or
infrastructure ticket.
kevin
9:37 a.m.
On Tue, 27 Aug 2019 17:52:00 -0700
Kevin Fenzi <kevin(a)scrye.com> wrote:
On 8/27/19 4:27 AM, Miro Hrončok wrote:
> On 27. 08. 19 13:06, Paul Howarth wrote:
>> On Mon, 26 Aug 2019 20:55:18 -0400
>> Mohan Boddu <mboddu(a)bhujji.com> wrote:
>>
>>> Hi all,
>>>
>>> Today's an important day on the Fedora 31 schedule[1], with
>>> several significant cut-offs. First of all today is
>>> the Bodhi activation point [2]. That means that from now all
>>> Fedora 31 packages must be submitted to
>>> updates-testing and pass the relevant requirements[3] before they
>>> will be marked as 'stable' and moved to the
>>> fedora repository.
>>
>> I don't know if this is related but the Rawhide (f32) builds I've
>> done today (e.g. perl-MCE-1.846-1.fc32) don't seem to be going
>> through the gating process and into rawhide.
>>
>> $ koji -q list-tagged --latest f32-updates-candidate perl-MCE
>> perl-MCE-1.846-1.fc32 f32-updates-candidate
>> pghmcfc
>>
>> $ koji -q list-tagged --latest f32 perl-MCE
>> perl-MCE-1.845-1.fc32 f32
>> pghmcfc
>
> https://pagure.io/fedora-infrastructure/issue/8138
This was fixed earlier today, sorry for not circling back and noting
that here.
I think everything should be processed that was stuck, if anyone sees
anything amiss, please let me know here, in email or via a releng or
infrastructure ticket.
Is it stuck again? I built perl-Path-Class-0.37-14.fc32 over three
hours ago and still no sign of an update or tagging into f32.
Paul.
11:47 a.m.
I'm still getting these messages when I try to do "fedpkg update" for F31:
fedpkg update
Could not execute update: Could not generate update request: Cannot find
release associated with build: copyq-3.9.2-1.fc31, tags: ['f31']
A copy of the filled in template is saved as bodhi.template.last
On Wed, Aug 28, 2019 at 7:37 AM Paul Howarth <paul(a)city-fan.org> wrote:
On Tue, 27 Aug 2019 17:52:00 -0700
Kevin Fenzi <kevin(a)scrye.com> wrote:
> On 8/27/19 4:27 AM, Miro Hrončok wrote:
> > On 27. 08. 19 13:06, Paul Howarth wrote:
> >> On Mon, 26 Aug 2019 20:55:18 -0400
> >> Mohan Boddu <mboddu(a)bhujji.com> wrote:
> >>
> >>> Hi all,
> >>>
> >>> Today's an important day on the Fedora 31 schedule[1], with
> >>> several significant cut-offs. First of all today is
> >>> the Bodhi activation point [2]. That means that from now all
> >>> Fedora 31 packages must be submitted to
> >>> updates-testing and pass the relevant requirements[3] before they
> >>> will be marked as 'stable' and moved to the
> >>> fedora repository.
> >>
> >> I don't know if this is related but the Rawhide (f32) builds I've
> >> done today (e.g. perl-MCE-1.846-1.fc32) don't seem to be going
> >> through the gating process and into rawhide.
> >>
> >> $ koji -q list-tagged --latest f32-updates-candidate perl-MCE
> >> perl-MCE-1.846-1.fc32 f32-updates-candidate
> >> pghmcfc
> >>
> >> $ koji -q list-tagged --latest f32 perl-MCE
> >> perl-MCE-1.845-1.fc32 f32
> >> pghmcfc
> >
> > https://pagure.io/fedora-infrastructure/issue/8138
>
> This was fixed earlier today, sorry for not circling back and noting
> that here.
>
> I think everything should be processed that was stuck, if anyone sees
> anything amiss, please let me know here, in email or via a releng or
> infrastructure ticket.
Is it stuck again? I built perl-Path-Class-0.37-14.fc32 over three
hours ago and still no sign of an update or tagging into f32.
Paul.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
10:23 a.m.
On Wed, 28 Aug 2019 09:47:49 -0700
"Gerald B. Cox" <gbcox(a)bzb.us> wrote:
I'm still getting these messages when I try to do "fedpkg
update" for
F31:
fedpkg update
Could not execute update: Could not generate update request: Cannot
find release associated with build: copyq-3.9.2-1.fc31, tags: ['f31']
A copy of the filled in template is saved as bodhi.template.last
The package was built on the 25th, before the Beta freeze. Hence it
went straight into the repo (it is there already, check for yourself:
https://dl.fedoraproject.org/pub/fedora/linux/development/31/Everything/s...)
and hence there's no need to create an update for it.
Paul.
1695
days inactive
1703
days old
32 comments
18 participants
participants (18)
-
Ben Cotton -
Chris Murphy -
Gerald B. Cox -
Jason L Tibbitts III -
Kalev Lember -
Kevin Fenzi -
Kevin Kofler -
Mamoru TASAKA -
Martin Kolman -
Miro Hrončok -
Mohan Boddu -
Nicolas Mailhot -
Panu Matilainen -
Parag Nemade -
Paul Howarth -
Przemek Klosowski -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek