On Wed, Oct 15, 2008 at 11:25:18AM -0600, Stephen John Smoogen wrote: > On Wed, Oct 15, 2008 at 11:08 AM, Patrice Dumas <pertusus@xxxxxxx> wrote: > > I think its this which is causing people to react in fear to the > proposal. The large amount of uncertainty ( how long, what to do with > bad vulnerabilities not getting fixed, no knowledge of the quality of > the package, etc) is causing doubt. And this is the sort of FUD that > comes about because something is too amorphous and isn't getting > fleshed out. There are 2 reasons why I don't want to flesh it too much. One is because I think it is an iterative process, we don't need much to start and we'll see how it goes, and in the start it won't be public, only something experimental. The other reason is that I see a lot of over confidence in fedora releases although fedora cannot promise anything: some guarantes that Fedora releases cannot make are asked for for that project, I really can't understand why. > 1) Dealing with the fear of hurting the Fedora brand. Come up with a > new brand for this: Long Term Blue Shoes (or something). I proposed UAEL. Update After End of Life. But I don't care a bit about the name, as long as there is one and that it is clear that it is not under the fedora brand. > 2) Dealing with the various uncertainties: > A. Get a list of people dedicated to this I want to do this as soon as possible, but not before there is a formal agreement that it will be possible to use fedora infrastructure and rules, because it completly determines if people are interested. I won't be, for example, if I have to set up a new infrastructure. > B. Put out how long you are extending it: 1 extra year. In my opinion, in the first experimental phase this is not very important. After some thinking I think that 3 years for selected releases and no more than 1 year for others may be right, but I think that this should better be determined by discussing within the SIG and with FESCo for advice and guidance and with infras for the available resources. > C. How to vet package quality/deal with bad trees. Package quality will be checked using the current fedora QA practices (well the practices at the time a branch is EOLed). What do you mean with 'bad tree'? A whole release? For a whole release, I think that first it should be possible to see if there is somebody interested in a given branch for a given package, and if there is a package of @core or @base that is not maintained the branch should be shut (that was basically the UAEL proposal). > D. What stuff is staying 'static/slow-moving' and what gets whatever > is in the latest Fedora? For this one my opinion is that the whole project should be on the side of the stability. However if the packager thinks that there won't be major disruptions by using what is in the oldest fedora, and it lowers his workload he can do it. In fact I think that something that should be discussed within the SIG is how hard we try to keep a possible upgrade path toward the next RHEL/EPEL. If there is a majority to think that it is important, I think that we should try (without impairing the project) to do that. Also if it fixes grave bugs and back porting is no easy. > 3) Dealing with the Doubt. > A. Get the SIG organized That's th efirst thing to do if the basics are agreed. > B. Build a test project of supporting Fedora 9 for 6 extra months. > This allows you time to get procedures, infrastructure, and > whatever else needed. The current plan is more for F8. But indeed this is the plan, begin first with one branch, see if it works both on the infrastructure and packaging side, and stop if not (maybe before 6 months...). > C. Follow your plans > D. Report how it worked. > E. Fix what didn't work and repeat. That's the plan. > [And yes, you are going to need to deal with infrastructure. Disk > space, cpu cycles, memory and power is not 'cheap' as much as people > think it is. Extra build boxes will be needed, extra disk space to I am not sure that cpu cycles, memory and power will be very problematic, since we really should be on the side of stability and, in contrary to EPEL the pacakges are already built. Moreover this is a one time cost. Bandwidth and disk cost is another story, especially since it is replicated in mirrors. > store stuff, and extra cpu cycles as Fedora's current infrastructure > is built on the assumption that it only needs to deal with X releases > for Y time. Adding to X and Y means more equipment needed. It will > also mean that someone's on the team are going ot have to focus on the > infrastructure problems as that addition also increases the number of > people needed to watch builds, etc. Indeed. I am ready to face that the project uses too much resources, but without trying one cannot know. -- Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
