On 01.06.2009 20:14, Jesse Keating wrote: > On Mon, 2009-06-01 at 19:49 +0200, Thorsten Leemhuis wrote: >> On 29.05.2009 22:57, Jesse Keating wrote: Thx for your reply and sorry, I didn't found time to answer earlier. Some more comments: [...] >> - how about reducing the number or zero day updates (which is ridiculous >> high for F11) by setting a different, later freeze date for all packages >> that are neither on the install DVD or on a Spin? > That's a bit hard to determine easily and programaticaly. I've all but > given up on my quest to reduce the number of updates. Just a general comment, not relevant for the "Announcing Fedora Activity Day". I'm glad that you gave up that quest, as "Fedora gets lot's of updates" is afaics a reason why a lot people actually use or contribute to Fedora. But that doesn't matter much. What I really want to say: I totally agree with this: > It's just doesn't > seem to be in line with the desires of the package maintainers, whether > or not it's in line with the desires of (some of) the project leaders. It IMHO shows a big and more and more pressing problem in Fedora: Packagers and leadership are not working towards the same direction. Anyway, back to topic: >> - other distributions seems to manage a whole lot more test releases >> (e.g. alphas, beta, RC, milestones, ...) per devel cycle; is that >> something we should aim for as well? > If there was a way to do it without adding stress and work needed to > teams like releng, installer, etc.. [...] One comment: *from a outside* it often looks a bit like - some (not all) people go crazy for weeks or months and ignore some of those bugs that are not pressing, but nevertheless pressing (e.g. kind of bugs that tend to land on target or blocker tracker bugs or already are there) - then you send a reminder "there will be a a test release next week" - people suddenly wake up and try to fix those bugs for the test release - they notice: arghh, serious things are broken, we need more time; can we please slip? - we slip Maybe more target dates where people should "get things into shape" might help to reduce the work for the real test/final releases. >> - how about doing something like a "cp -l development devel-snapshot" >> now and then (once a week) when we know rawhide is mostly working? > The rawhide trees for at least the past month are kept in the Fedora > infrastructure and are even available by a public url. We haven't > tagged any of them as "stable" though. They are afaics way to far away/way to slow to reach to do a proper network install in an acceptable period of time (at least from Germany). Is rsync available -- I'm not aware of it, so I doubt it? >> - how can we reduce our time between finishing a (test) release and >> releasing it dramatically? It seems other distributions get new (test) >> release out to the users a lot quicker then the three to five days days >> we require, which seems a whole lot for a devel cycle that takes 180 >> days in total (and we all know how much rawhide can move on with a few days) > If we didn't care to let the mirrors sync up we could "release" it > earlier. However what good does that do when nobody can /get/ to the > release because none of the mirrors have it, and the ones that do can't > help sync to those that don't because users are tying up all the > bandwidth? I didn't say to not care. But maybe shorten the time we wait for them and help to get the bits out more quickly; pushing users to use bittorrent more might help a lot as well. >> - I'd be glad if we could stick to our release targets a lot better. >> Delaying releases looks quite unprofessional. Delaying also creates >> trouble for those depending on our releases. Take computer magazines >> (which have hard deadlines for productions) that might want to ship with >> a new release on a CD or DVD together with the next issue -- due to our >> fame in missing deadlines it seems to me that we are a lot more >> unattractive than Ubuntu (which afaics is on the shelf's here in Germany >> with new computer magazines just a few days after it has been released) > What looks more unprofessional? Delaying the release, or hitting our > date and releasing with bugs that eat people's data? Or releasing with > broken graphics for large swaths of users? I think you drifted a bit way to far away and into a opposition without need. I for example nowhere said that we should not slip if there is a strong reason to. But my comment was quite open, so it's partly my fault; so let me rephrase: What is rel-eng doing in the next devel cycle to make sure we slip less then we used to in the past? Or does rel-eng think everything was fine and missing three and a half target dates (alpha, beta, release and the first slipped release target date) out of four is acceptable? >> - why do we have to slip by a whole week most of the time? can't we find >> ways to slip just a day or two if there really is no way around a delay? > The marketing machine has very strongly requested that we only do > releases on Tuesdays. Some reasons why Tuesdays are "must" instead of "good" would be way more helpful then a simple statement "they said so". So all I can say is: Yes, let's target Tuesdays if that is idea (which I agree), but if there is a slip then slip only a day, two or three if the problem can be fixed within that timeframe (which for example was not the case for the first release slip for the final, but maybe for the second). > [...] >> - I'd be glad if the final release directories (e.g. >> release/12/Everything" could be available earlier, even if what is in >> them is not yet what "12" actually will become > You'll have to enumerate why that is. Kevin outlined some of the reasons already in a reply: https://www.redhat.com/archives/fedora-devel-list/2009-June/msg00073.html > One reason I've avoided this is > added confusion as to when the "release" happens. If we created that > directory and put content in there, would we have then released Fedora > 12? When does it become "released" and thus trusted? As Kevin said as well: It seems to work quite well for Ubuntu and actually avoids a lot of confusion. I'd say their scheme even works better then our scheme. I'd also think most "normal" users don't ever look on the servers. BTW, one more general thing for the FAD: Would it make sense to make rawhide updates more than once a day in case something that bugs lot's of people can be fixed easily by a quick update? CU knurd -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
