On Tue, Dec 10, 2013 at 7:33 PM, Michael K. Johnson <[email protected]> wrote: > On Mon, Nov 18, 2013 at 08:40:38AM +0100, Mark Trompell wrote: >> So we're down to the crossroad I feel, where we have to quickly decide >> where we are heading. Do we want do revive foresight and jump on the >> fl3 train or do we want to go on with our lifes and let foresight die. > > I've been silently pondering this thread for a while. I apologize for > being so quiet, but I didn't want to be too hasty.
Thinking before writing is a good thing in most cases. > I still think that my old proposal (as Rune referenced) is a general > good start. > > I'd suggest taking bite-size pieces would make it easier to get to > something that works: > > 1. Import Fedora 20 (it is just about to be released) using mirrorball. > Just do a binary import to start with. We might be able to start > small by starting with one of the smaller "spins" and then add > more packages as we go, in order to make the pieces more bite-sized. > > 2. Optionally, developers who would like to explore rebuilding from > SRPMs with mirrorball could start a track doing that work, bootstrapping > from the binary import, in a different repository. > > 3. Building Foresight as a conary-native layer that can run on top of > either the binary import or the bootstrapped source build, that > has only things different from the underlying platform, would let > Foresight return to its roots. > > 4. Import newer versions of Fedora as they are released, and as they > are ready, move the Foresight layer on top of them. That actually sounds like a good summary of the thoughts floating around, So starting with 1) and if time and manpower permits go on to 2 + 3 (4 is mandatory I think), sounds like a plan. > Here's my problem: I know I will personally have limited time > available to participate in this process. So I would suggest doing > this only in concert with developers now at SAS who were previously > at rPath. In order to make this proposal, I'd need to know who of > the Foresight developers would be willing to run the import process, > noting and investigating failures in the import process, and working > through updates and fixes with those developers. To propose this > internally, I'd need to know who was volunteering to work on the > import process. How much time would you think will it keep to get on track? I think as you already played with fedora imports and centos/redhat works too, Fedora won't be a big issue. Though systemd and especially the usr-merge that followed its introducion will need some extra love. I think after the first import, regular updates and bumping fedora versions shouldn't be that hard (mainly because people will know mirrorball by then) I think I can dedicate some time a day, but unfortunatly all sas guys are still sleeping at that time. > So: If you care enough about this that you'd be willing to help > drive the import process and help isolate bugs in the import process > so that we can build on top of an existing base, please respond, > either to the list or privately to me, so that I can propose this > internally at SAS. I'm willing to help and keep us running, but timezones maybe an issue here. > Just being very clear: this is expressing my own ideas, and does > not represent any views of my employer. But if we (Foresight) > have enough commitment to working on this, I'm willing to propose > it internally (SAS) and then follow up with the volunteers regarding > the result. > > _______________________________________________ > Foresight-devel mailing list > [email protected] > https://lists.foresightlinux.org/mailman/listinfo/foresight-devel > -- Mark Trompell Foresight Linux Xfce Edition Cause your desktop should be freaking cool (and Xfce) _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
