On Tue, Mar 18, 2014 at 07:20:10AM +0100, Martin Bähr wrote: > there will be a FUDCon APAC held in beijing in may. > since i live in beijing i'll surely participate. > > now i am wondering if we want to share with the fedora community what we are > doing with fedora. > > do we want to keep it quiet until we have fl:3 up and running or do we want to > share what we are doing now?
Just to be clear, there are definitely people in the Fedora community who know what we are doing. My intent has been the usual open source way: get something minimally working before advertising. Not keeping quiet, just not advertising until there is something that people would want to test. If the f20 import isn't up and running in two months, I'll be surprised and sad. So there should be something to say. > the deadline to submit a talk is the 20th of march noon EST! > http://tinyurl.com/FUDConAPAC2014CFP > > i can probably work out a presentation in the next two months, but i would > need > help making a submission. (an outline of what to talk about would help a lot, > i > can work out an abstract based on that) I'm afraid that this is where I fall down. I'm not sure I'll be much help. I want to make sure that we're clear that the f20 import into a Conary repository is putting it into a location (label) equivalent to a subdirectory in a file-based repository system and that we are not modifying the contents. It makes sense to think of this import as most like a yum alternative. And to be sure that we are representing only fedora proper in this location, we are keeping the necessary tools (like conary itself) in a separate location (label) just as someone building a yum alternative would best put it in a separate directory from a repository containing fedora proper. In fact, we really are making conary be a yum alternative, except that it also has many other features. Then, having done this, we have the opportunity to explore whether in doing so we have solved problems that have plagued Fedora. For example, while many people upgrade Fedora regularly without problems, there are also many horror stories of fedup breaking people's systems. Many of the kinds of breakage that show up are things that Conary could address. Among those are more complete deps and dep-complete update jobs often avoiding the "broken screensaver" problem, and groups allowing a more precise migration that avoids leaving straggling bits that create untested situations that break. I have not been the one experiencing these problems, so I can't say for sure. We just know that we've been able to maintain a rolling distro across major updates for years (though we quit updating gnome when gnome3 showed up...) and so it's worth trying. It might be that if people trusted Fedora updates more, they would update more, which would be good for Fedora. It's a distraction when people complain about the short maintenance lifetime. Can we make that better? Then Foresight becomes a rolling remix, not only useful on its own, but an opportunity and context in which to demonstrate whether or not Conary can make the Fedora base bits roll forward with fewer update failures. We've already found packaging bugs in the release just from trying to import into Conary. I expect we'll find more. That has typically happened during Conary imports of RPM distributions. If we import the beta releases of Fedora, we can find bugs before they hit users, and the kinds of bugs Conary finds are usually the ones that are easy to fix, "low hanging fruit" that can really contribute to fit and finish. There was some interest last year in whether the conary build process could make it easier to build RPMs. I encouraged that, but there was really not enough interest to get enough people involved to make it happen. In this context, though, it might make a lot more sense. So if we succeed in demonstrating this, there might be more interest in what conary could do inside Fedora in a way that there is not now. In summary, I see several points of potential interest to the Fedora community: * Enabling Fedora users to consume Fedora using a rolling model. * Demonstrating a new way to build a Fedora remix, one that takes advantage of the rolling model and helps the remixes stay current. * Contributing to upstream quality by catching certain classes of bugs prior to release. * Using Conary's extensive package build automation to make it easier to build better packages for Fedora. Does that seem like something you would feel comfortable talking to? _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
