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

Dennis Gilmore dennis at ausil.us
Tue Jan 13 18:24:53 UTC 2015


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

On Thu, 08 Jan 2015 11:08:30 -0500
Stephen Gallagher <sgallagh at redhat.com> wrote:

> 
> 
> 
> 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.

It is not even close to 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).
> 
> 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.

It is still not reasonable to get everything done in that period of
time. 

Dennis

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJUtWL1AAoJEH7ltONmPFDRBG8QAL0tDHjey5+6CRFX5sP7XeUL
AwB+0xJmop1qDx/XGJH1TKuEi7i0PcDMc2X+IhrQqq6ya/Lj5hs0tkHikPcKb/R8
1UqJhYUS1g7TdMlccDbEWzgcbe+WkJoKtdezD5UKIAX+2OIpo7yxAvH2AL2HE4Dk
50KKgReQKsp+YPQQYNvwU4xyAUYHbibKwoa1MQ9b+PSfJEY1UlXcFojtabScYble
dDyjax5aWZ70hVnFj8arz+6b9R/nH3wgy/Y5G+orzKHn0VMABBqGehJhMeF4gjhc
frgC9+xR+KDrVQcgBDxNHiYFCEJzlpk2EobZwRWJQnqwkqJ4Vxhu/gY3rTPn9sXK
dU1sImogR9YP98fHBRO13O0HAXnzy9PcP94p08vSV3n6iNVAKQ62DTttY+MJQch7
RAshY4N5C+huNFTTkS5opuisDRclNUITkd+vO5JMOhSVpSxSN+GjZgh/9c1mqu5H
K692Hd0S9avitib6ExGctzOUBPeZwAug/zFm5SV7YRu8jOGPBisbuaj3ThW/oqiD
DhXuq8BglqZr7gNQfjpYf2Wh961hna0+C9Bpy5bhqPkG5xm0d0SIyCCS9hoJHINB
mxprdBGpYRjCg+cgn/jH5ry9oZbwbd8/CJcZseRiEN4wsHTN7WnhqDEkwXV9gqJA
Y0f4ylAwdXXAMfYKmuNS
=DWfY
-----END PGP SIGNATURE-----


More information about the devel mailing list