-----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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
