SeaMonkey:First Release: Difference between revisions
Jump to navigation
Jump to search
m (→Features) |
m (The text needed wrapping) |
||
Line 22: | Line 22: | ||
Quoting Ben Goodger from IRC: | Quoting Ben Goodger from IRC: | ||
<ben_> so here's what you need to do to ship a release. 1. decide what you want out of it (a good start is to develop a product plan in wiki.mozilla.org with checkmarked features/etc) 2. find engineers to do each of the items in the aforementioned list 3. get those engineers to provide blurb+swag for each - this is a description of the item + estimated time to completion or an ETA. 4. have them implement the features. 5. deal with bugs that arise, manage the | <ben_> so here's what you need to do to ship a release. | ||
<ben_> 6. when your features are done, you can beta... when you get to a low level of remaining bugs, you can kick off the final release process. | 1. decide what you want out of it (a good start is to develop a product plan in | ||
wiki.mozilla.org with checkmarked features/etc) | |||
2. find engineers to do each of the items in the aforementioned list 3. | |||
get those engineers to provide blurb+swag for each - this is a description of | |||
the item + estimated time to completion or an ETA. | |||
4. have them implement the features. | |||
5. deal with bugs that arise, manage the | |||
<ben_> 6. when your features are done, you can beta... when you get to a low level of | |||
remaining bugs, you can kick off the final release process. | |||
<Callek> ben_ 5. Deal with bugs that arise, manage the ...??? (cut off) | <Callek> ben_ 5. Deal with bugs that arise, manage the ...??? (cut off) | ||
<ben_> the final release process involves things like documenting changes (release noets, product pages, etc). | <ben_> the final release process involves things like documenting changes (release noets, | ||
<ben_> er, "manage them using bugzilla flags, etc. prioritize them and have people work on those." | product pages, etc). | ||
<ben_> ... getting testing builds spun, having interested users test them and submit feedback, driving the list to zero and handling new bugs as they come in. | <ben_> er, "manage them using bugzilla flags, etc. prioritize them and have people | ||
work on those." | |||
<ben_> ... getting testing builds spun, having interested users test them and submit feedback, | |||
driving the list to zero and handling new bugs as they come in. | |||
<ben_> Asa probably has more info on the latter half of this process. | <ben_> Asa probably has more info on the latter half of this process. | ||
<ben_> but what I would suggest starting with is saying, "what do we want from Seamonkey 1.8?" | <ben_> but what I would suggest starting with is saying, "what do we want from Seamonkey 1.8?" |
Revision as of 12:59, 11 March 2005
from n.p.m.seamonkey (written by bz):
> Without me knowing well what is involved in "pushing out a release" At least: 1) Tagging the trunk at some point when it's stable (coordinating this with other trunk Gecko/etc consumers, one hopes). 2) Lots of organized and thorough testing of the branch you created. 3) Filing bugs based on the results of that testing. 4) Getting said bugs fixed on that branch. 5) Writing release notes. 6) Creating builds from the branch. 7) Pushing those builds to the FTP server. 8) Announcing the release. Asa, please chime in if I missed something through ignorance? I suspect step #2 is somewhat time-consuming, as are step #4 and step #5. -Boris
Quoting Ben Goodger from IRC:
<ben_> so here's what you need to do to ship a release. 1. decide what you want out of it (a good start is to develop a product plan in wiki.mozilla.org with checkmarked features/etc) 2. find engineers to do each of the items in the aforementioned list 3. get those engineers to provide blurb+swag for each - this is a description of the item + estimated time to completion or an ETA. 4. have them implement the features. 5. deal with bugs that arise, manage the <ben_> 6. when your features are done, you can beta... when you get to a low level of remaining bugs, you can kick off the final release process. <Callek> ben_ 5. Deal with bugs that arise, manage the ...??? (cut off) <ben_> the final release process involves things like documenting changes (release noets, product pages, etc). <ben_> er, "manage them using bugzilla flags, etc. prioritize them and have people work on those." <ben_> ... getting testing builds spun, having interested users test them and submit feedback, driving the list to zero and handling new bugs as they come in. <ben_> Asa probably has more info on the latter half of this process. <ben_> but what I would suggest starting with is saying, "what do we want from Seamonkey 1.8?" <ben_> and start listmaking in wiki.mozilla.org
<ben_> you need to identify the work involved in that task then <ben_> break it down into pieces <ben_> findpeople to help and get estimates.
We'd really like to know what can be done by which people (perhaps some of those tasks can still be done or helped with by MoFo, but it seems we can't rely on that any more).
Features
- Current Gecko - many improvements since 1.7
- Ship a final release with the various UI improvements since 1.7
- Enable calendar?
If time permits (rumours talk of a beta3):
- Port to toolkit, at least partial?
- Extension Manager (maybe too much work for 1.8)
- Consider enabling SVG?
...feel free to fill in more...