Release wranglers notes 29 Sep 2004

[Kevin E Martin]

Here are the notes taken by Leon Shiman from our last release wranglers
meeting.  Thank you Leon for taking them!

---------------------------------------------

Release Wrangler's Mtg Notes: 29 September 2004

Mtg began at 11:08 am edt, ended 12:03 pm edt

Attendees:

Jim Gettys
Stuart Kreitman
Kevin Martin
Dan McNichol
Leon Shiman

Rough running notes of discussion of KEM's process review:

- not everyone has read it.

- review misses the fact that tinderbox helped. tinderbox needs to be in a 
more robust state so that it runs throughout the development cycle.

- main intention of review was to capture what it could of the process, and 
to spark discussion for improvement; wanted to get it done now. it is 
brokeninto three parts. intention in to go through them linearly.

-the major moral is to start earlier in deciding when next release should 
be.

	1. scheduling. 

- how do we get things going? at redhat (fedora) we knew when we'd have our 
next release. summer travel interfered, but we finally set the date. 

- we need to flag things early.so how do we do this? 

- in this case what happened was that there were two major vednor releases 
scheduled near the same date.

- there were two considerations: the vendor release dates and new 
technologies to be released.

- knowing that a release is coming at a fixed date is important; this will 
come. so where do release dates come from? for example, releases from gnome 
are now predictable. known dates do help [everyone]. fedora picked up both 
gnome and X. a number of major projects are now doing twice yearlyreleases.
some vendors don't want their release dates known publicly.redhat fedora is 
open source, and so has published dates. but redhat's enterprise release 
isn't public. i think the same is true for suse. so the question to raise 
is: do we want just to react to vendor needs and schedules? 

- how do we autonomously decide on a release train? is it to be a feature 
based release or a date based release. it is easier to keep a large 
community engaged if they know that there are releases coming at fixed 
times. how do we keep developers motivated.

- there are social consequence of this decision. a release schedule that is 
autonomous isn't necesarily better. but in this case, kevin's scheduling 
depended on fedora. the release mgrs for gnome are sometimes comercial and 
sometimes not. this time several x.org members had a common need. we need to 
clarify what the developer and interested employer/vendor priorities are.
[kem noted that] he was involved in xfree86 since 92 while in grad school, 
[and that based on his experience he felt that: if we are more proactive and 
set dates i think that vendors could schedule participation of their 
employees, and that [we should keep track of] vendor schedules, and know 
which are coming up.

- each major release could be planned out far in advance. we could say that 
our next major release will be no more than 6 months out, but that the exact 
time may be shortened. this would allow and encourage more energy applied.  
we can plan, announce, and then ask for input. simply saying that in  next 
six months we would like to have a release isn't enough. we need to ask 
why should there be a release, and what features would [the community] like 
to have in it. 

- [jim gettys remarked:]e.g. bringing cairo under gnome has been pushed to 
2.10. but we saw this over a year ago. planning also needs to include more 
than one release cycle. e.g. driver work may require scheduling 12-18 months 
out. there are a lot of new features that i would like to see included. once 
we have set a date, how do we ask for feature requirements?

- [regarding interim releases:] if we have a scheduled major release, do we 
also allow interim releases, or do we just schedule a release further out? 
we need to get to this. we have lots on our plate. we need to begin to plan. 
we need to give a feeling of comfort that there will be future releases. 
this allows developers freedom, and to be comfortable with pushing release 
of particular code further out.

- [on availability of release managers.] we can't necessarily know in 
advance when a volunteer release manager will be free to do work. 3/4 months 
in advance may be the max. being a release manager with a very short time is 
very time consuming and stressful. it isn't a situation where you can mentor 
or train [someone new to the process. somehow we have to lessen the burden 
on the RM for some tasks, so that there is time even in a compresssed 
schedule. [this is easier] if plans are worked out earlier.

- [on testing resources:] it would be better if we had more serious 
resources for testing involved much earlier. if should be automated. 
[possibly we could] get commercial people involved. we need engineering 
work in testing in open source community. seldom are open source community 
members interested in testing. gettng that infrastructure built and working 
would help a lot. 

- should the board draft a letter to sponsoring organizations that our 
experience has shown that testing is the greatest barrier, and that sponsors 
should consider giving resources to it. 

- how do we solicit active engineering help? kem grew [an engineering plan] 
organically working with stuart anderson. it was somewhat manageable by the 
end. we made huge strides, but there is more to be done.

- how can we reward people for testing? what would people want? there
are several sets of communities involved in this. one set is the chip
vendors for example, who need stable releases. are there rewards? for
example, prestige among peers. there are organizations such as ati,
nvidia, etc., who have commercial stakes, some of whom have commercial
motivation to help on commercial testing. we can make a fuss about
people who are helping on tinderbox and testing. such work should be
rewarded by recognition. this is a multifaceted situation.

- can we publicly emphasize testing, giving it marketing spin. we do know 
its value after what we've now done. [an impotant] moral from this release 
is that browing a testing infrastructure would be very beneficial. But it is 
not only allocating resources, but deciding where those resources need to be 
put. we want and need concrete suggestions. there are a lot of in-house 
testing groups used by chip manufacturers and software vendors. how do we 
let them see that they can benefit [by working with us].

- [stuart kreitman noted:] at sun we've [the X Group ] gotten significant 
internal advantage and credibility from the new release(s). this fall we 
should work with the stake holders to get them integrated. we need to 
announce the next release, then make a schedule, then contact stake holders 
to get fully engaged in that release. 

- [kem noted:] i'd like to see how we can take my notes (kem) and carry them 
forward. [kem] volunteered to try to make a list to help focus discussions 
as we go forward. [ kem also took ] an action item to make a concise list of 
discussion points for next mtg, and will make an announcement for planning 
the next release, building in a continuing discussion of process issues.

- jim volunteered his line for the next meeting anticipating a larger
number of participants.