Summary/Minutes from today's FESCo Meeting (2015-01-07)

[Vít Ondruch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dne 8.1.2015 v 17:08 Stephen Gallagher napsal(a):
>
>
>
> On Thu, 2015-01-08 at 15:31 +0100, Vít Ondruch wrote:
>> Dne 8.1.2015 v 15:03 Stephen Gallagher napsal(a):
>>>
>>>
>>>
>>> On Thu, 2015-01-08 at 10:40 +0100, Vít Ondruch wrote:
>>>> Dne 7.1.2015 v 21:14 Stephen Gallagher napsal(a):
>>>>>
>>>>>   * Tentative date for side-tag merge is 2015-01-28  (sgallagh,
>>>>>     19:09:55)
>>>>>
>>>>
>>>> What does it mean actually? Does it mean that if I plan to do
rebuild of
>>>> Ruby packages in side-tag, I am supposed to be finished before 28th,
>>>> i.e. in less then 3 weeks? Considering that Ruby was not approved
yet by
>>>> FESCO and that Ruby change more or less blocks Ruby on Rails
change, how
>>>> are we supposed to handle everything?
>>>>
>>>
>>> Yes, it needs to be finished before the 28th. If that cannot be done,
>>> then consider deferring this change to Fedora 23.
>>
>> My feature was submitted to wrangler 17th of December and it will be
>> hopefully approved 14th January (one month later) ... I could even
>> submit it until 20th of January, which means FESCo would approve it 28th
>> of January at the best, which is the same date like the side-tag merge.
>> So where is the time in the schedule I can actually do my work?
>>
>> And I won't start with any builds until the change is approved, because
>> .... I don't know actually, but I believe that the FESCo approval should
>> come first prior I start any rebuilds, because although the builds are
>> done in side tag, the possible reverts in master are not for free.
>>
>>>
>>>
>>> The reason for "tentative" was mostly so we could get feedback from
>>> rel-eng on whether this is actually feasible.
>>>
>>>>
>>>> On the other hand, there are two week between branch and freeze, what
>>>> are these good for? Is it just for maintainers to enjoy work with
>> branches?
>>>
>>> I'm sorry, I don't understand the question. There needs to be a gap
>>> between branching and Freeze so that things can settle out. (For
>>> example, there are often a few packages that need post-branch updates
>>> for a variety of reasons. Also, the branch process itself sometimes
>>> needs some time to shake out the bugs.
>>
>> Obviously, you don't give me as a developer any time to actually develop
>> something, but then you give two weeks to settle down something which
>> does not need settling ... or it needs settling because I don't have
>> time to develop something, depends on the way how you look at it.
>>
>> Sorry for being grumpy about this but according to the original proposal
>> [1], I should have enough time till branch in worst case, which was
>> scheduled to 10th February, now suddenly you shorten the period just to
>> half of the time. This is not nice.
>>
>
> I'm not sure where you got that this was shortened. In the link you
> offered, it said:
>
> "no earlier than 2015-XX-XX (to be set)    Side Tag Builds Deadline"
>
> We hadn't set it previously, but it has *always* been at least some time
> before the branch date. (We don't want it to be *after* branch, because
> then you would have to handle side-tags for both rawhide and branched,
> and that's unreasonable).

Considering the "Side Tag Builds Deadline" is new milestone since F21
and since it happened almost 2 months after Change Proposals Submission
Deadline (System Wide Changes) during F21 period, the one week period
(which is even very tight to fulfill the full change procedure, although
not impossible) is simply too short.

>
>
> That being said, I'll bring it up with FESCo (CCed) whether we could
> shorten the branch->freeze period by a week and add another week before
> the side-tag and mass-rebuild dates. It's a reasonable request. We'll
> need to hear from rel-eng whether it's acceptable.

Thank you.

Vít


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUrrLkAAoJEAzgnueZF7h8GhcP/ROCWzQS6CyPvw6V6RQfvQcx
yo2CO2E64oIP/jLyptmruuP+md07VHpZnXIf2TCuaiXR3hoFG0TfY3ou562Me9gB
bxQb2J4dLkxAMeY47EAFT+hW1k1dwWBu7BZw9seqyaYUff7hDjpcHegljCfC5RjH
N782JK+cfYpH5FzpDGnj4dKshBWQ65uW1KymOkxC3lXyrogxUm/MxJEA0B/RNA4i
iX5n6zu/ncq7gsRY707wSzota80Dz25yCjP8iQv4CDRp8U/WCLcExwGXPM2PaV8a
XFdDXtfiJcFIJptqqDzVzuJMZbIlIEYLvi5woiv3i9AgVZzVYN678OUFKgVlCiIN
BG7sIPCQJmc+3Y5+csVv6hOL9HZJ8Ved7K8eWSa+1N/LETcu1EtY9Q3q74CU7+/u
T4OkoM5/veFjX2ffF9oUqKRG/zp7CmCbbL/dPQUvOgcfFZeCA3fRK8EotYCugbxi
MdcOIdJKTc5Ln552Jsf7GbY04OoH2wLbt9cVPNrPD6sVfNSaTGkfTnLsWFmQMdVK
dZHGikwGi2IXWCxn2iTEb05O7N84a7Zyf/SauGSCHwJC3s25D7wyODyXDg+vYv8o
jZCMQlRKvrjxbzoOYtIgbzemXAEueD1RFTz7WK0nQVCA9v/Tj1vCTcrGdWaJEqIs
cWT6dWzXMCkxJqP+rV9h
=dpKJ
-----END PGP SIGNATURE-----