I forgot to mention this in my last message. I was highlighted while my network was acting up on me. I have looked *very little* at this point, but it's fundamental for us to work on it soon. I know it's not just by chance that I was seen as "the driver" for it. So, during the work about it we had at DC12, we had two apparent runner-ups: Frab and Zookeepr. If I am to be seen as the driver for the change, I'm clearly for Frab, for a linguistic issue: I have failed to love Python, and feel quite at ease with Ruby. Frab looks as a clean, neat implementation. I have not yet done a even test install of it (I'm creating a VM for it right now). I expect to have it ready soon, and I'll start looking at what we have, what we need. I expect not to be the only one doing this. Holger has repeatedly said the Frab upstreams are willing to work together with us - As you know, I have no high hopes of remaining too close to the upstream code (we will fork even if we try not to), but we can start working together and diverge once we really need (i.e. add the missing controllers first, but only later add the DebConf-specific bits). We shall see. Now, what do we need to get this working? - More people involved. I'm very bad at managing my time and have several projects going on, so I know I will fail if I do this myself. - Resources? I can have this on a VM of my personal machine, but I'd very much rather if we have a instance where more people can log in and hack on it. A DebConf machine? A Debian machine? Would be good. But *please* not a painfully underpowered instance as Cletus (the test instance for Penta), it only makes stuff harder. And... Well, we shall later see what else. My proposed roadplan would be to set up a system with no data migration from Penta (to start fresh), have everything ready for other DebConfers to register and point out the bits that need work. Maybe that would need a RT queue to keep track of? Greetings,
Attachment:
signature.asc
Description: Digital signature