Of course I am doing almost none of this work personally. When it makes sense I'll credit the specific people and/or teams. Questions and comments welcome, of course. I have no idea if this kind of thing is useful to folks. But I wonder if I can keep up a weekly cadence of updates.
Unity
This week
- Dx team is working to get the Compiz based experience ready for testing
- Nothing new uploaded this week, so no update to the spider diagram :(
- I hope to start testing new compiz-based experience and update the spider diagram
Testing
This Week
- ara has confirmed that mago will work with apps under unity so it's possible to start writing integration tests
- Unity integration testing is blocked this week on looking into the global menu because of a bug in the dumper tool, but it should be unblocked next week
- Server team outlined steps for packaging Hudson
- Switch Unity Integration testing on Natty
- Start teseting the global menu on Unity (this is important because there are lots of bugs their in Maverick)
- Get more tests in place and running daily
- Progress on packaging and deploying Hudson
This Week
- Created documentation for Path Pilots (a tweak to our system for responding to contributors)
- Straw man schedule for Ubuntu Engineering Engineers set up (these are engineers paid by Canonical to work on Ubuntu)
- Share Patch Piloting schedule with Ubuntu Engineering Engineers, let them change it around to suit self
- Ensure documentation works for Patch Pilots
- Pick a date to start with the tweaked system
This Week
- I followed up on UDS session regarding using /opt for installing new apps on a stable release, and drafted a proposal to the App Review Board that they ask the Tech Board to remove the /opt requirement for Maverick, since there are so few apps we can really review them carefully, and the technology is not there to support /opt properly in Maverick
- didrocks broke out work items to ensure that Python build system and Quickly will support installing to /opt in the future
- Perhaps see some progress by didrocks on making the Python build system work with /opt
- First meeting regarding Donations with IS, I requested that the notes from the call be posted to a mailing list or such
This Week
- I confirmed with cjwatson that we can make good progress on "Text Free Boot" in Natty. It won't surprise anyone to know that I had trouble grocking the blueprint :)
- Open stack is all packaged up and ready for better integration with Ubuntu Server
- Set schedule to get to Feature Definition Freeze with the Ubuntu Engineering Managers (All Blueprints Accepted by 11/11, All Work Items Identified by 11/18)
- Perhaps create a system for getting feedback on which platforms can boot Text Fee so we can start to assemble the white or blacklist
- Some server team members to attend Open Stack Design Summit next week
- pitti to reset work item tracker to start burndowns for teams that are ready
Where is your proposal for the tech board re /opt? We discussed this exact issue in depth at UDS and I'm interested to see your take on it. I don't see it at https://lists.ubuntu.com/archives/technical-board/2010-November
ReplyDeleteHi Scott.
ReplyDeleteIndeed, we took what I consider to be, good decisions at UDS. However, implementation turned out to be harder than expected.
I sent a proposal to the Application Review Board first, but it got caught in their moderation queue, so they (The App Review Board) just got my proposal yesterday. If they are amendable to the suggestion, I'll send it off to Tech Board for review, and I'll cc @ubuntu-devel so that it can be discussed there as well. There's not point discussion it on @ubuntu-devel if the App Review Board itself disagrees.
Here's what I wrote to the App Review Board:
On Wed, 2010-11-03 at 08:11 -0700, Rick Spencer wrote:
> Hello all,
>
> I'm seeking to unblock the New Apps process on Maverick. The decision
> was taken that apps from extras.ubuntu.com should only be installed
> in /opt. However it turns out that this is not currently well supported
> by the Python build system and our system. For example, Python build
> tools can not byte compile into /opt, and it will be a non-trivial
> amount of work to make them do so, and would not be appropriate for an
> SRU.
>
> Considering the very small number of applications that will likely
> require review, I propose that make /opt work in Natty as part of the
> Software Center theme.
>
> For Maverick, I would like to remove the requirement that apps be
> installed into /opt. We can institute fairly detailed review of each
> app, considering the very small number of apps that are being submitted
> for review.
>
> Please let me know your thoughts, and I will be happy to take this
> proposal to the Technical Board.
>
> Cheers, Rick
If new build system code were put in a new package that was suggested (for ARB apps) by the existing packages, then I think it would be perfectly fine to SRU.
ReplyDeleteI worry that if we take a soft line now for convenience reasons it will be difficult to do it right later.