[cairo-commit] [cairo-www] 3 commits - src/summit

Tue Aug 26 14:50:26 PDT 2008

src/summit/2008/notes.mdwn |   59 +++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 57 insertions(+), 2 deletions(-)

New commits:
commit 177c9dd59bcc38ecb45d12b7f4d8247c4900be3b
Merge: 4ece5f4... dfa9a32...
Author: Carl Worth <cworth at cworth.org>
Date:   Tue Aug 26 14:49:59 2008 -0700

    Merge branch 'master' of annarchy.freedesktop.org:/srv/cairo.freedesktop.org/wiki
    
    Conflicts:
    
    	src/summit/2008/notes.mdwn

diff --cc src/summit/2008/notes.mdwn
index a310d9a,9e87f63..78ded9c
--- a/src/summit/2008/notes.mdwn
+++ b/src/summit/2008/notes.mdwn
@@@ -218,55 -218,20 +218,75 @@@ good or not
  
  Vlad: Should be possible, definitely.
  
++<<<<<<< HEAD:src/summit/2008/notes.mdwn
 +Behdad: Let's choose Fedora rawhide as our initial reference platform
 +to make the whole test suite work and then extend from there, (Fedora,
 +Ubuntu, Win32, OS X, etc.).
 +
 +14:00 Automated testing (Travis' notes)
 +---------------------------------------
 +Interesting discussion about testing issues, things like how to
 +compute tolerable differences between images, what to do about
 +reference images that contain text and change from platform to
 +platform. One interesting idea from 3D, do a minimal blur on reference
 +and output, and then compare. Other options are standard image
 +registration algorithms such as SSD, SAD, Mutual information, etc.
 +
 +14:30 Project management issues (Carl's notes)
 +----------------------------------------------
 +
 +Carl: To some extent, I was "checked out" from cairo development the
 +past few months, (for various reasons), and the project clearly
 +stalled. When Behdad went to make a new release, there were 5-600
 +commits piled up with no intervening snapshots. What metrics do we
 +need to know that the project is staying healthy?
 +
 +Behdad: We definitely need snapshots every couple of weeks or so. And
 +the only way to make that happen is to keep the tree in a releasable
 +state at all times, (see buildbot discussion above).
 +
 +Vlad: Would be great to have a fixed schedule for snapshots: Say,
 +there must be a new snapshot every month. And we do let other external
 +projects set the major release schedule, (GNOME, Mozilla, etc.), but
 +we should also guarantee some maximum time that will pass between
 +major releases, (say one year or so).
 +
 +Carl: We need a person to own stable releases. I'm failing to keep up
 +with them.
 +
 +Chris: I'm willing to do that.
 +
 +Behdad: It doesn't need to be the same person every time, either. We
 +can nominate a new person for each stable branch.
 +
 +14:30 Project Management issues (Travis's notes)
 +----------------------------------------------
 +Background: Carl changed jobs this summer, and for a while the project
 +stalled. Last release largely pushed by Gnome->Pango->Cairo, Behdad
 +did the work.
 +
 +Vlad: More and more Cairo consumers may mean timed release better
 +model to keep up.
 +
 +Carl: Tree has to stay releasable. If one falls too far behind, the
 +effort to get to a snapshot-able point is too big. Not in favor of
 +automating it completely.
++=======
+ Interesting discussion about testing issues, things like how to compute tolerable differences between images, what to do about reference images that contain text and change from platform to platform. One interesting idea from 3D, do a minimal blur on reference and output, and then compare. Other options are standard image registration algorithms such as SSD, SAD, Mutual information, etc.
+ 
+ 14.30 Project Management
+ ------------------------------------------------------------
+ Background: Carl changed jobs this summer, and for a while the project stalled. Last release largely pushed by Gnome->Pango->Cairo, Behdad did the work.
+ 
+ Vlad: More and more Cairo consumers may mean timed release better model to keep up.
+ 
+ Carl: Tree has to stay releasable. If one falls too far behind, the effort to get to a snapshot-able point is too big. Not in favor of automating it completely.
+ 
+ Behdad: Six month cycle makes stable releases easier to maintain.
+ 
+ Chris: Willing to maintain the stable release.
+ 
+ Carl: If "new" features done on a separate branch, it makes merging it back into both unstable and stable easier.
+ 
+ Automated Testing WITH feedback important part of keeping project management rolling.
++>>>>>>> dfa9a32584811896f817852097ecc4714fcf06ff:src/summit/2008/notes.mdwn
commit 4ece5f49fcfe7552ccac6e4e659ce09f4a032121
Merge: 0efac7b... 635b73d...
Author: Carl Worth <cworth at cworth.org>
Date:   Tue Aug 26 14:49:48 2008 -0700

    More live notes

diff --cc src/summit/2008/notes.mdwn
index da3ea92,7356c7d..a310d9a
--- a/src/summit/2008/notes.mdwn
+++ b/src/summit/2008/notes.mdwn
@@@ -204,8 -204,8 +204,8 @@@ the new API is uncontroversial, but Car
  entries---it seems we should be able to address the use cases that
  have come up without any new API here.]
  
--14:00 Automated testing (Tinderbox or buildbot or whatever)
-------------------------------------------------------------
++14:00 Automated testing (Carl's notes)
++--------------------------------------
  
  Vlad: Already have several Mac minis---just need to get them all set
  up and running. One issue is building cairo and pixman in an
@@@ -218,33 -218,12 +218,55 @@@ good or not
  
  Vlad: Should be possible, definitely.
  
 -Interesting discussion about testing issues, things like how to compute tolerable differences between images, what to do about reference images that contain text and change from platform to platform. One interesting idea from 3D, do a minimal blur on reference and output, and then compare. Other options are standard image registration algorithms such as SSD, SAD, Mutual information, etc.
 -
 -14.30 Project Management
 -------------------------------------------------------------
 -Background: Carl changed jobs this summer, and for a while the project stalled. Last release largely pushed by Gnome->Pango->Cairo, Behdad did the work.
 -
 -Vlad: More and more Cairo consumers may mean timed release better model to keep up.
 -
 -Carl: Tree has to stay releasable. If one falls too far behind, the effort to get to a snapshot-able point is too big. Not in favor of automating it completely.
 +Behdad: Let's choose Fedora rawhide as our initial reference platform
 +to make the whole test suite work and then extend from there, (Fedora,
 +Ubuntu, Win32, OS X, etc.).
 +
- 14:30 Project management issues
- -------------------------------
++14:00 Automated testing (Travis' notes)
++---------------------------------------
++Interesting discussion about testing issues, things like how to
++compute tolerable differences between images, what to do about
++reference images that contain text and change from platform to
++platform. One interesting idea from 3D, do a minimal blur on reference
++and output, and then compare. Other options are standard image
++registration algorithms such as SSD, SAD, Mutual information, etc.
++
++14:30 Project management issues (Carl's notes)
++----------------------------------------------
 +
 +Carl: To some extent, I was "checked out" from cairo development the
 +past few months, (for various reasons), and the project clearly
 +stalled. When Behdad went to make a new release, there were 5-600
 +commits piled up with no intervening snapshots. What metrics do we
 +need to know that the project is staying healthy?
 +
 +Behdad: We definitely need snapshots every couple of weeks or so. And
 +the only way to make that happen is to keep the tree in a releasable
 +state at all times, (see buildbot discussion above).
 +
 +Vlad: Would be great to have a fixed schedule for snapshots: Say,
 +there must be a new snapshot every month. And we do let other external
 +projects set the major release schedule, (GNOME, Mozilla, etc.), but
 +we should also guarantee some maximum time that will pass between
 +major releases, (say one year or so).
 +
 +Carl: We need a person to own stable releases. I'm failing to keep up
 +with them.
 +
 +Chris: I'm willing to do that.
 +
 +Behdad: It doesn't need to be the same person every time, either. We
 +can nominate a new person for each stable branch.
++
++14:30 Project Management issues (Travis's notes)
++----------------------------------------------
++Background: Carl changed jobs this summer, and for a while the project
++stalled. Last release largely pushed by Gnome->Pango->Cairo, Behdad
++did the work.
++
++Vlad: More and more Cairo consumers may mean timed release better
++model to keep up.
++
++Carl: Tree has to stay releasable. If one falls too far behind, the
++effort to get to a snapshot-able point is too big. Not in favor of
++automating it completely.
commit 0efac7b8b821fe279f42bce45343b980dd61f4df
Author: Carl Worth <cworth at cworth.org>
Date:   Tue Aug 26 14:46:31 2008 -0700

    More live notes

diff --git a/src/summit/2008/notes.mdwn b/src/summit/2008/notes.mdwn
index 645bd8a..da3ea92 100644
--- a/src/summit/2008/notes.mdwn
+++ b/src/summit/2008/notes.mdwn
@@ -217,3 +217,34 @@ Chris: How about allowing a developer to ask the system if a patch is
 good or not?
 
 Vlad: Should be possible, definitely.
+
+Behdad: Let's choose Fedora rawhide as our initial reference platform
+to make the whole test suite work and then extend from there, (Fedora,
+Ubuntu, Win32, OS X, etc.).
+
+14:30 Project management issues
+-------------------------------
+
+Carl: To some extent, I was "checked out" from cairo development the
+past few months, (for various reasons), and the project clearly
+stalled. When Behdad went to make a new release, there were 5-600
+commits piled up with no intervening snapshots. What metrics do we
+need to know that the project is staying healthy?
+
+Behdad: We definitely need snapshots every couple of weeks or so. And
+the only way to make that happen is to keep the tree in a releasable
+state at all times, (see buildbot discussion above).
+
+Vlad: Would be great to have a fixed schedule for snapshots: Say,
+there must be a new snapshot every month. And we do let other external
+projects set the major release schedule, (GNOME, Mozilla, etc.), but
+we should also guarantee some maximum time that will pass between
+major releases, (say one year or so).
+
+Carl: We need a person to own stable releases. I'm failing to keep up
+with them.
+
+Chris: I'm willing to do that.
+
+Behdad: It doesn't need to be the same person every time, either. We
+can nominate a new person for each stable branch.
