Just going to throw out that I can probably make some arrangements for a SCALE related hackfest (1st Q every year) and possibly get some sponsorship from the conference for speaking and/or volunteer work. There would just need to be enough spoken interest in advance for me to run it by the chairs. If we could really get a regular release process down directly linked to the conference I am pretty confident it would be an easy sell.


On Thu, May 5, 2016 at 11:52 AM, Tavmjong Bah <tavmjong@...47...> wrote:
On Wed, 2016-05-04 at 21:12 -0700, Bryce Harrington wrote:
> On Wed, May 04, 2016 at 03:02:24PM +0200, Tavmjong Bah wrote:
> >
> > On Tue, 2016-05-03 at 12:34 -0700, Bryce Harrington wrote:
> > >
> > >  
> > > This will be a good opportunity to debrief from the hackfest and
> > > identify followup actions that the board should work on in coming
> > > months.
> > I'm almost done with collecting receipts from the hackfest and LGM.
> > We
> > spent roughly $7200 (plus or minus a few hundred dollars) out of
> > the
> > $13100 budgeted.
> >
> > This hackfest was very successful in my opinion. Part of the reason
> > it
> > was so successful was having (somewhat accidentally) critical
> > masses to
> > work on the CMake build as well as GTK3 problems. I think we could
> > duplicate this success by having some focused hacking sessions. In
> > particular, I think it would be quite beneficial to have a
> > gathering
> > focused on getting 0.92 out. A follow up gathering could focus in
> > fixing GTK 3 issues. Both these topics should be exciting to our
> > user
> > community which would help with raising funds to cover their costs.
> Excellent ideas all around.
> With releases traditionally the work falls into these categories:
>   0.  Getting tests to all pass and the build to build cleanly
>   1.  The actual release mechanics (make dist, signing, etc.)
>   2.  Translation
>   3.  Fixing release-critical bugs
>   4.  PR/announcement
>   5.  Website/infrastructure related bits and pieces
> Some of these may be better suited to co-location than others.  #0 I
> suspect is probably already in the bag, and #1 I've been working on
> behind the scenes so am not worried there.  Translation I think kind
> of
> by definition is going to be hard to do as a hackfest.  The PR and
> Website stuff probably would benefit from a hackfest but they're not
> areas likely to be blockers for us, although a strong case could be
> made
> from a fundraising perspective that it would be time well invested.
> I suspect for this release bugfixing is the biggest remaining hurdle,
> but I don't have anywhere close to a handle on what it's going to
> look
> like so who knows.  If we knew what bugs needed fixed the worst, and
> who
> the fixers would be, that would tell us the suitability of a hackfest
> and clue us in on where geographically it should be held.

Yes, I was thinking work category 3 as the primary reason to have a
release hackfest. Work on the other categories might also benefit from
a hackfest but not as much as 3.

> I'm guessing that there's enough of us typically involved in releases
> that are located in the western half of the US, that a west-coast or
> midwest location might be sensible, and might be a fair turn since
> we've
> had hackfests on the east coast and England.

It's a bit far away, but we will be able to send two people to the
Google Mentor Summit which is in the later part of October. So timing a
hackfest on the west coast at that time might be good. If not for a
release then perhaps for working on GTK3.


> Bryce

Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
Inkscape-board mailing list