Hey everybody, Software is hard. I feel bad to even suggest this after how hard all the Ubiquity contributors have been working towards this release over the past few weeks, but I am thinking about pushing the 0.5 release back a couple more weeks, until I have returned from my trip. I just got done talking to Atul and he strongly suggested doing so, for the following reasons:
1. The server-side components (bug reporter, command search engine, etc) are not anywhere near ready. I've been working on them all day and discovered that the job is much, much bigger than I thought. I thought it was going to be a one-day thing but it looks more like we will have to seriously rethink the server infrastructure if we want to offer bug reporting and command search services to our users.
2. Support: After we release 0.5 onto addons.mozilla.com, since it is such a big change to how ubiquity works, there is bound to be a huge influx of users with support requests, maybe more serious bugs discovered, etc. This would be happening while I was gone and not able to help with any of the support work. Leaving the users hanging with new problems due to 0.5 might be a worse thing to do to them than making them wait another couple of weeks to get 0.5.
3. Features: If we push it back, we will have time to try to put in some of the features we cut out: Suggestion memory, provider-plugin arguments, and most of all, asynchronous noun-first suggestion (in a way that doesn't count as a DDOS attack on Yelp).
So, if we push it back, then we'll be able to do a more polished release, with the server-side components working, and at a time when I'll be available to help with the support and bug fixing and the inevitable patches that will be needed.
This isn't just my decision, though. What does everybody else think of pushing the release back? --Jono
On Thu, Jul 2, 2009 at 4:52 PM, Jono<jdica...@mozilla.com> wrote: > Hey everybody, > Software is hard. > I feel bad to even suggest this after how hard all the Ubiquity > contributors have been working towards this release over the past few > weeks, but I am thinking about pushing the 0.5 release back a couple > more weeks, until I have returned from my trip. I just got done > talking to Atul and he strongly suggested doing so, for the following > reasons:
> 1. The server-side components (bug reporter, command search engine, > etc) are not anywhere near ready. I've been working on them all day > and discovered that the job is much, much bigger than I thought. I > thought it was going to be a one-day thing but it looks more like we > will have to seriously rethink the server infrastructure if we want to > offer bug reporting and command search services to our users.
> 2. Support: After we release 0.5 onto addons.mozilla.com, since it is > such a big change to how ubiquity works, there is bound to be a huge > influx of users with support requests, maybe more serious bugs > discovered, etc. This would be happening while I was gone and not > able to help with any of the support work. Leaving the users hanging > with new problems due to 0.5 might be a worse thing to do to them than > making them wait another couple of weeks to get 0.5.
> 3. Features: If we push it back, we will have time to try to put in > some of the features we cut out: Suggestion memory, provider-plugin > arguments, and most of all, asynchronous noun-first suggestion (in a > way that doesn't count as a DDOS attack on Yelp).
> So, if we push it back, then we'll be able to do a more polished > release, with the server-side components working, and at a time when > I'll be available to help with the support and bug fixing and the > inevitable patches that will be needed.
> This isn't just my decision, though. What does everybody else think > of pushing the release back? > --Jono
I agree with the decision to push back the release until Jono's return from
his trip, for the same reasons Jono has described. I was listening in on the
conversation with Atul and it seems like the logical choice. Jono being gone
for the whole support phase following the release would be pretty bad, and
coupled with the server-side problems I think we need to push it back. On a
side note, with this extra time I'm excited about the possibility of getting
noun first suggestions into 0.5 in a way that's more reflective of what we
were advertising with the 0.5pre blog posts and so forth, though modified to
avoid DDOS attacks of course =)
On Thu, Jul 2, 2009 at 5:02 PM, Jono <jdica...@mozilla.com> wrote:
> P.S.
> I think we should keep releasing 0.5pre versions periodically during
> the next three weeks. Aza will take care of organizing that effort.
> --Jono
> On Thu, Jul 2, 2009 at 4:52 PM, Jono<jdica...@mozilla.com> wrote:
> > Hey everybody,
> > Software is hard.
> > I feel bad to even suggest this after how hard all the Ubiquity
> > contributors have been working towards this release over the past few
> > weeks, but I am thinking about pushing the 0.5 release back a couple
> > more weeks, until I have returned from my trip. I just got done
> > talking to Atul and he strongly suggested doing so, for the following
> > reasons:
> > 1. The server-side components (bug reporter, command search engine,
> > etc) are not anywhere near ready. I've been working on them all day
> > and discovered that the job is much, much bigger than I thought. I
> > thought it was going to be a one-day thing but it looks more like we
> > will have to seriously rethink the server infrastructure if we want to
> > offer bug reporting and command search services to our users.
> > 2. Support: After we release 0.5 onto addons.mozilla.com, since it is
> > such a big change to how ubiquity works, there is bound to be a huge
> > influx of users with support requests, maybe more serious bugs
> > discovered, etc. This would be happening while I was gone and not
> > able to help with any of the support work. Leaving the users hanging
> > with new problems due to 0.5 might be a worse thing to do to them than
> > making them wait another couple of weeks to get 0.5.
> > 3. Features: If we push it back, we will have time to try to put in
> > some of the features we cut out: Suggestion memory, provider-plugin
> > arguments, and most of all, asynchronous noun-first suggestion (in a
> > way that doesn't count as a DDOS attack on Yelp).
> > So, if we push it back, then we'll be able to do a more polished
> > release, with the server-side components working, and at a time when
> > I'll be available to help with the support and bug fixing and the
> > inevitable patches that will be needed.
> > This isn't just my decision, though. What does everybody else think
> > of pushing the release back?
> > --Jono
-- Brandon James Pung
Massachusetts Institute of Technology Class of 2010
Department of Electrical Engineering and Computer Science
828.777.8640 | bp...@mit.edu
How about we release Tuesday? Mitcho points out the following reasons we should release after all:
1. if we push it back we will be letting down all the people who have already blogged/written/read about the 0.5 release 2. the XPI itself is ready 3. The server components are not ready, but 0.5 without bug reporter / herd is at least not any worse than 0.1.8 without bug reporter/herd 4. The rest of the community can handle support without me ;-) 5. Getting people onto 0.5 will reduce the load on the ubiquity.mozilla.com.
We should replace the herd and bug reporter pages with notifications that tell users those services are down for repair, and then focus on getting them working after the 0.5 release is out.
Atul and Aza have agreed to manage the release while I'm gone. --Jono
P.S. remember that if upgrading to 0.5 breaks a user's favorite third-party command, they can always go back to parser 1 using the Settings page. (Anybody doing support should keep this in mind as it will be a common complaint.) --Jono
On Thu, Jul 2, 2009 at 6:08 PM, Jono<jdica...@mozilla.com> wrote: > How about we release Tuesday? Mitcho points out the following reasons > we should release after all:
> 1. if we push it back we will be letting down all the people who have > already blogged/written/read about the 0.5 release > 2. the XPI itself is ready > 3. The server components are not ready, but 0.5 without bug reporter / > herd is at least not any worse than 0.1.8 without bug reporter/herd > 4. The rest of the community can handle support without me ;-) > 5. Getting people onto 0.5 will reduce the load on the ubiquity.mozilla.com.
> We should replace the herd and bug reporter pages with notifications > that tell users those services are down for repair, and then focus on > getting them working after the 0.5 release is out.
> Atul and Aza have agreed to manage the release while I'm gone. > --Jono
As Jono already mentioned a number of the reasons I gave to strongly
push for a release today, it suffices to say that I agree whole- heartedly with Blair. Amen.
I'm fine with a Tuesday release, but we should make it a firm
commitment and we should make it crystal clear on trac and/or the list
(ideally both) *EXACTLY* what the blockers are that we are up against
(if any).
> I think Personas has a dual release schedule - one for the client, one
> for the server-side stuff. It seems to work pretty well, and I don't
> see
> why that method couldn't be applied to Ubiquity. To me, client
> (Ubiquity) and server (Herd) are two separate products.
> I don't think the release should be pushed back for new features. For
> serious bugs yes, but there's nothing major blocking that I know of.
> There's no such thing as a perfect release - there will always be
> something that could have been fixed, could have been better.
> So I'm for releasing now. Or Tuesday if really necessary. But not
> any later.
> - Blair
> On 3/07/09 1:09 PM, Jono wrote:
>> P.S. remember that if upgrading to 0.5 breaks a user's favorite
>> third-party command, they can always go back to parser 1 using the
>> Settings page.
>> (Anybody doing support should keep this in mind as it will be a
>> common
>> complaint.)
>> --Jono
>> On Thu, Jul 2, 2009 at 6:08 PM, Jono<jdica...@mozilla.com> wrote:
>>> How about we release Tuesday? Mitcho points out the following
>>> reasons
>>> we should release after all:
>>> 1. if we push it back we will be letting down all the people who
>>> have
>>> already blogged/written/read about the 0.5 release
>>> 2. the XPI itself is ready
>>> 3. The server components are not ready, but 0.5 without bug
>>> reporter /
>>> herd is at least not any worse than 0.1.8 without bug reporter/herd
>>> 4. The rest of the community can handle support without me ;-)
>>> 5. Getting people onto 0.5 will reduce the load on the
>>> ubiquity.mozilla.com.
>>> We should replace the herd and bug reporter pages with notifications
>>> that tell users those services are down for repair, and then focus
>>> on
>>> getting them working after the 0.5 release is out.
>>> Atul and Aza have agreed to manage the release while I'm gone.
>>> --Jono
Aza, Atul, and I just had a lengthy conversation about the release plans for
tomorrow, and we have decided to somewhat tweak the way we are doing this
release. Ubiquity 0.5 will still be released tomorrow, but it will be
released as a separate entity from 0.1.8, and will be called Ubiquity.Next
or something along those lines. It will be on addons.mozilla.org under this
separate name, so both 0.1.8 and 0.5 will be available there. The two
versions of Ubiquity will be kept separate until 0.5 is in a state that we
are ready to push on to all of our ~400,000 users. The requirements for this
merge will be something like:
1) Have the top x percent of 3rd party commands converted to Parser 2 format
2) Fix the network call problem in a way that allows us to re-enable async
network calls for noun first suggestions (through server-side caching or
other means)
3) Resolve bugs by design that will surely be identified as we get a bunch
of new users on Ubiquity.Next
The reason we do not want to force everyone to upgrade to 0.5 at this point
is because the benefits of 0.5 in it's current state don't necessarily
outweigh the negative changes for many of our users. With the async
suggestions basically disabled for noun first suggestions, the biggest
positive changes made between 0.1.8 and 0.5 are the more sophisticated
parser, resulting in the removal of hyphens, and internationalization. While
this stuff is very cool, and moving in the right direction, 0.5 breaks all
3rd party commands and also breaks some user habits (like the way delimiters
force you to type "weather near boston", whereas in 0.1.8 you can just type
"weather boston"). Breaking user habits is ok if the positive gains outweigh
the necessary changes in behavior. We think that 0.1.8 and 0.5 should be
kept separate until it is clear that 0.5 is a valuable upgrade to nearly all
of our users, which will be true when the requirements listed above are
fulfilled. While this is a labs project, we also have hundreds of thousands
of users who depend on Ubiquity to make their computing lives easier, so we
need to be cautious about pushing major changes on everybody.
Aza will be creating a screencast further describing the reason for
maintaining the two separate extensions soon. How does this sound to
everyone? Any questions or concerns?
-Brandon
On Sat, Jul 4, 2009 at 2:54 PM, Fernando Takai <fernando.ta...@gmail.com>wrote:
> Btw, i emailed the couchdb user-list, but i really need the logs from
> the server (so they can say what's going on).
> Also, i prototyped another bug-report app [1], using MongoDB [2] - if
> we can't make couchdb work, i think this is a good replacement.
> > What about folding the Ubiquity commands into the pre-existing add-ons
> > site? Can we bring SUMO on board to get the documentation up to
> > snuff? That would get us back on track much more quickly- and it's
> > what is going to happen sometime down the line anyway.
> > Wasn't there a plan to get someone working on the HERD full time for
> > the summer- an intern or something...
> > On Jul 3, 8:38 pm, "mitcho (Michael 芳貴 Erlewine)"
> > <mit...@mitcho.com>
> > wrote:
> >> Jono, this sounds great. The server-side is definitely a priority
> >> worth seriously working on in the near future. Looking forward to
> >> seeing you on Monday! :D
> >> I will email ubiquity-i18n about the localization time schedule. I
> >> personally think the more public outreach to the broader localization
> >> community (through dev-l10n), especially given the limited time until
> >> next Tuesday, is better suited to right after the 0.5 release.
> >> mitcho
> >>> Hey everybody,
> >>> I apologize for my panicky email on Thursday afternoon; I was very
> >>> frustrated at my inability to get the server-side components
> >>> working,
> >>> and I got pretty emotional (as those who have to share an office
> >>> with
> >>> me can attest). Anyway, after hearing from everyone about it, I
> >>> think
> >>> we are good to launch early Tuesday morning.
> >>> Today I pushed a 0.5pre4 (up on the site now). It includes
> >>> changes to
> >>> the web content and the Report Bug command, so that users who are
> >>> looking to report bugs are directed to Get Satisfaction, and users
> >>> looking for more commands are directed to the Commands In The Wild
> >>> wiki page. I think both of these will be more helpful than
> >>> directing
> >>> them to non-functional Herd and Bug Reporter services.
> >>> I think 0.5pre4 is ready to be renamed 0.5.0 and released, but it
> >>> should be stress-tested by everyone involved to make sure it can
> >>> upgrade cleanly, that it has decent performance and generates
> >>> reasonable suggestions, and that the tutorial works.
> >>> The Herd and the report-bug service will likely require a complete
> >>> rewrite of the backend infrastructure before they are functional.
> >>> They both depend on a single couchdb install which currently
> >>> stands at
> >>> 6 GB, and which cannot run for more than a few minutes without
> >>> crashing. I was unable to get it to stay up for any length of
> >>> time,
> >>> even after spending most of yesterday on it. So I think we'll
> >>> need to
> >>> start some new server infrastructure from scratch in order to
> >>> support
> >>> Herd and the bug reporter the way we want to. That should be one of
> >>> the main priorities after we release 0.5.0.
> >>> As I said, I think we're good to release Tuesday morning. I agree
> >>> with Christian about pushing to get translations done for that.
> >>> Please, no new features or functional changes: just translations,
> >>> testing, and bug fixes.
> >>> Aza has agreed to take responsibility while I'm gone, to write the
> >>> release blog post for 0.5 and to manage the release of any dot-
> >>> patches
> >>> that are afterwards found to be neccessary (0.5.1 etc).
> >>> I am leaving on my trip tomorrow morning, so I can do no more on
> >>> this
> >>> release. The rest of you will have to decide the exact timing of
> >>> the
> >>> 0.5.0 release, and manage its execution.
> >>> Good luck!
> >>> --Jono
> >>> On Fri, Jul 3, 2009 at 9:19 AM, "mitcho (Michael 芳貴
> >>> Erlewine)"<mit...@mitcho.com> wrote:
> >>>> As Jono already mentioned a number of the reasons I gave to
> >>>> strongly
> >>>> push for a release today, it suffices to say that I agree whole-
> >>>> heartedly with Blair. Amen.
> >>>> I'm fine with a Tuesday release, but we should make it a firm
> >>>> commitment and we should make it crystal clear on trac and/or the
> >>>> list
> >>>> (ideally both) *EXACTLY* what the blockers are that we are up
> >>>> against
> >>>> (if any).
> >>>> m
> >>>>> I think Personas has a dual release schedule - one for the client,
> >>>>> one
> >>>>> for the server-side stuff. It seems to work pretty well, and I
> >>>>> don't
> >>>>> see
> >>>>> why that method couldn't be applied to Ubiquity. To me, client
> >>>>> (Ubiquity) and server (Herd) are two separate products.
> >>>>> I don't think the release should be pushed back for new features.
> >>>>> For
> >>>>> serious bugs yes, but there's nothing major blocking that I know
> >>>>> of.
> >>>>> There's no such thing as a perfect release - there will always be
> >>>>> something that could have been fixed, could have been better.
> >>>>> So I'm for releasing now. Or Tuesday if really necessary. But not
> >>>>> any later.
> >>>>> - Blair
> >>>>> On 3/07/09 1:09 PM, Jono wrote:
> >>>>>> P.S. remember that if upgrading to 0.5 breaks a user's favorite
> >>>>>> third-party command, they can always go back to parser 1 using
> >>>>>> the
> >>>>>> Settings page.
> >>>>>> (Anybody doing support should keep this in mind as it will be a
> >>>>>> common
> >>>>>> complaint.)
> >>>>>> --Jono
> >>>>>> On Thu, Jul 2, 2009 at 6:08 PM, Jono<jdica...@mozilla.com>
> >>>>>> wrote:
> >>>>>>> How about we release Tuesday? Mitcho points out the following
> >>>>>>> reasons
> >>>>>>> we should release after all:
> >>>>>>> 1. if we push it back we will be letting down all the people who
> >>>>>>> have
> >>>>>>> already blogged/written/read about the 0.5 release
> >>>>>>> 2. the XPI itself is ready
> >>>>>>> 3. The server components are not ready, but 0.5 without bug
> >>>>>>> reporter /
> >>>>>>> herd is at least not any worse than 0.1.8 without bug reporter/
> >>>>>>> herd
> >>>>>>> 4. The rest of the community can handle support without me ;-)
> >>>>>>> 5. Getting people onto 0.5 will reduce the load on the
> >>>>>>> ubiquity.mozilla.com.
> >>>>>>> We should replace the herd and bug reporter pages with
> >>>>>>> notifications
> >>>>>>> that tell users those services are down for repair, and then
> >>>>>>> focus
> >>>>>>> on
> >>>>>>> getting them working after the 0.5 release is out.
> >>>>>>> Atul and Aza have agreed to manage the release while I'm gone.
> >>>>>>> --Jono
I really like this idea and think it will make the end user experience
much smoother for english language users who are mostly interested in
Ubiquity as a productivity enhancer. I also have a few concerns.
1. I think it is important that we figure out a way to differentiate
0.1.8 from Ubiquity.Next for purposes of support/command feeds/
documentation. I think the documentation needs some major cleanup -
some of which I am willing to do tonight if we can come up with a good
way to explain the differences. Anyone have any suggestions about the
best way to do this? This means maintaining two sets of user
documentation and two sets of command developer documentation.
2. In terms of command developers, is there any easy way we can make
Ubiquity handle command feeds for both versions? We have some
developers that have done great work getting their commands ready for
Parser2, and we're making their lives harder temporarily by making
them maintain two versions of their commands. It would be nice if
Ubiquity could handle subscribing to one feed for 0.1 and one feed for
0.5 without having to make links to both.
3. Another limitation of this approach is it weakens "ubiquity the
platform" a little in terms of being easy to use and understand, since
the Parser1 documentation is not so good right now (the auto generated
docs, including the command API, are generated from the source tip),
and as a community we'll need to expect some people developing for
Parser1 and some for Parser2. I think most of this concern is
remedied by urging people interested in command development to use 0.5
and develop for Parser2.
4. It's a little late to do this this time around, but I think in
general the core development team should think about maintaining a
release trunk and a beta branch (haha, i'm using developer words,
probably incorrectly). Right now maintaining 0.1.8 is actually fairly
difficult if I understand correctly. I think 0.1.8 is fairly stable,
but it has a few bugs that would be worth fixing if we're going to
keep it out there. I think it's worth having a conversation about how
we're going to handle ubiquity the product vs. ubiquity the experiment
in the future, but I think this idea is a step in the right direction.
5. I think this gives us a great opportunity to think about how to
best engineer the herd to smooth over the upgrade issues of when 0.5
is pushed to be the "used by everybody" version. If the herd is
parser1/parser2 aware, then we can use it to measure how many 3rd
party commands have been ported to parser2 and when people make the
switch, they can use the herd to actually find commands, which would
be pretty sweet! Fern has done some awesome work on the Herd, but I
think a complete rewrite will require some developer resources that
Ubiquity just doesn't have right now.
I think that's about it.
Heather
On Jul 6, 7:33 pm, Brandon Pung <bp...@mit.edu> wrote:
> Aza, Atul, and I just had a lengthy conversation about the release plans for
> tomorrow, and we have decided to somewhat tweak the way we are doing this
> release. Ubiquity 0.5 will still be released tomorrow, but it will be
> released as a separate entity from 0.1.8, and will be called Ubiquity.Next
> or something along those lines. It will be on addons.mozilla.org under this
> separate name, so both 0.1.8 and 0.5 will be available there. The two
> versions of Ubiquity will be kept separate until 0.5 is in a state that we
> are ready to push on to all of our ~400,000 users. The requirements for this
> merge will be something like:
> 1) Have the top x percent of 3rd party commands converted to Parser 2 format
> 2) Fix the network call problem in a way that allows us to re-enable async
> network calls for noun first suggestions (through server-side caching or
> other means)
> 3) Resolve bugs by design that will surely be identified as we get a bunch
> of new users on Ubiquity.Next
> The reason we do not want to force everyone to upgrade to 0.5 at this point
> is because the benefits of 0.5 in it's current state don't necessarily
> outweigh the negative changes for many of our users. With the async
> suggestions basically disabled for noun first suggestions, the biggest
> positive changes made between 0.1.8 and 0.5 are the more sophisticated
> parser, resulting in the removal of hyphens, and internationalization. While
> this stuff is very cool, and moving in the right direction, 0.5 breaks all
> 3rd party commands and also breaks some user habits (like the way delimiters
> force you to type "weather near boston", whereas in 0.1.8 you can just type
> "weather boston"). Breaking user habits is ok if the positive gains outweigh
> the necessary changes in behavior. We think that 0.1.8 and 0.5 should be
> kept separate until it is clear that 0.5 is a valuable upgrade to nearly all
> of our users, which will be true when the requirements listed above are
> fulfilled. While this is a labs project, we also have hundreds of thousands
> of users who depend on Ubiquity to make their computing lives easier, so we
> need to be cautious about pushing major changes on everybody.
> Aza will be creating a screencast further describing the reason for
> maintaining the two separate extensions soon. How does this sound to
> everyone? Any questions or concerns?
> -Brandon
> On Sat, Jul 4, 2009 at 2:54 PM, Fernando Takai <fernando.ta...@gmail.com>wrote:
> > I think Tuesday is a good day ;D
> > Btw, i emailed the couchdb user-list, but i really need the logs from
> > the server (so they can say what's going on).
> > Also, i prototyped another bug-report app [1], using MongoDB [2] - if
> > we can't make couchdb work, i think this is a good replacement.
> > > What about folding the Ubiquity commands into the pre-existing add-ons
> > > site? Can we bring SUMO on board to get the documentation up to
> > > snuff? That would get us back on track much more quickly- and it's
> > > what is going to happen sometime down the line anyway.
> > > Wasn't there a plan to get someone working on the HERD full time for
> > > the summer- an intern or something...
> > > On Jul 3, 8:38 pm, "mitcho (Michael 芳貴 Erlewine)"
> > > <mit...@mitcho.com>
> > > wrote:
> > >> Jono, this sounds great. The server-side is definitely a priority
> > >> worth seriously working on in the near future. Looking forward to
> > >> seeing you on Monday! :D
> > >> I will email ubiquity-i18n about the localization time schedule. I
> > >> personally think the more public outreach to the broader localization
> > >> community (through dev-l10n), especially given the limited time until
> > >> next Tuesday, is better suited to right after the 0.5 release.
> > >> mitcho
> > >>> Hey everybody,
> > >>> I apologize for my panicky email on Thursday afternoon; I was very
> > >>> frustrated at my inability to get the server-side components
> > >>> working,
> > >>> and I got pretty emotional (as those who have to share an office
> > >>> with
> > >>> me can attest). Anyway, after hearing from everyone about it, I
> > >>> think
> > >>> we are good to launch early Tuesday morning.
> > >>> Today I pushed a 0.5pre4 (up on the site now). It includes
> > >>> changes to
> > >>> the web content and the Report Bug command, so that users who are
> > >>> looking to report bugs are directed to Get Satisfaction, and users
> > >>> looking for more commands are directed to the Commands In The Wild
> > >>> wiki page. I think both of these will be more helpful than
> > >>> directing
> > >>> them to non-functional Herd and Bug Reporter services.
> > >>> I think 0.5pre4 is ready to be renamed 0.5.0 and released, but it
> > >>> should be stress-tested by everyone involved to make sure it can
> > >>> upgrade cleanly, that it has decent performance and generates
> > >>> reasonable suggestions, and that the tutorial works.
> > >>> The Herd and the report-bug service will likely require a complete
> > >>> rewrite of the backend infrastructure before they are functional.
> > >>> They both depend on a single couchdb install which currently
> > >>> stands at
> > >>> 6 GB, and which cannot run for more than a few minutes without
> > >>> crashing. I was unable to get it to stay up for any length of
> > >>> time,
> > >>> even after spending most of yesterday on it. So I think we'll
> > >>> need to
> > >>> start some new server infrastructure from scratch in order to
> > >>> support
> > >>> Herd and the bug reporter the way we want to. That should be one of
> > >>> the main priorities after we release 0.5.0.
> > >>> As I said, I think we're good to release Tuesday morning. I agree
> > >>> with Christian about pushing to get translations done for that.
> > >>> Please, no new features or functional changes: just translations,
> > >>> testing, and bug fixes.
> > >>> Aza has agreed to take responsibility while I'm gone, to write the
> > >>> release blog post for 0.5 and to manage the release of any dot-
> > >>> patches
> > >>> that are afterwards found to be neccessary (0.5.1 etc).
> > >>> I am leaving on my trip tomorrow morning, so I can do no more on
> > >>> this
> > >>> release. The rest of you will have to decide the exact timing of
> > >>> the
> > >>> 0.5.0 release, and manage its execution.
> > >>> Good luck!
> > >>> --Jono
> > >>> On Fri, Jul 3, 2009 at 9:19 AM, "mitcho (Michael 芳貴
> > >>> Erlewine)"<mit...@mitcho.com> wrote:
> > >>>> As Jono already mentioned a number of the reasons I gave to
> > >>>> strongly
> > >>>> push for a release
|
