tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ant elder" <ant.el...@gmail.com>
Subject Re: R1.1. Status - was: Outstanding JIRA,, release 1.1 and Quality
Date Wed, 02 Jan 2008 14:20:46 GMT
On Jan 2, 2008 2:11 PM, Simon Laws <simonslaws@googlemail.com> wrote:

> On Dec 20, 2007 10:07 PM, Simon Laws <simonslaws@googlemail.com> wrote:
>
> > As an experiment I looked down the first page of the outstanding bug
> list
> > [1] allocating to release 1.1 those bugs that I believed should be
> fixed.
> > I was looking for the sort of thing which showed a failure of some
> feature
> > of Tuscany, didn't obviously have a work round and that wasn't obviously
> > some kind of enhancement from what we have already. Difficult to apply
> this
> > consistently and I'm sure we would all come up with different lists. Non
> the
> > less I came up with 9 JIRA on the page of 50 (I moved some others as I'm
> > trying to address as many of the release build related bugs as I can.
> I'm
> > not counting them for this purpose). Just be multiplying that up for the
> > remaining pages that gives us over 30 must fixes before 1.1.  So if you
> > are planning to work on the release during the rest of the year please
> use
> > this as a guide.
> >
> > In reality I know we won't get these all done but we need to ensure 1.1.
> > is of suitable quality. Perhaps a more realistic way of looking at this
> is
> > if we we had to do 2 each before we start voting on a release candidate
> in
> > January which two would they be? I'm working my way though the
> (hopefully)
> > straightforward release related JIRA but I expect the RC process will
> raise
> > more of these so experience tells us we will have these to deal with
> also.
> >
> > Any thoughts about how we approach this?
> >
> > Regards
> >
> > Simon
> >
> > [1]
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310210&status=1&status=3&status=4&component=-1&component=12310625&component=12311294&component=12310646&component=12310649&component=12311818&component=12310652&component=12311651&component=12310647&component=12310952&component=12311790&component=12311980&component=12311785&component=12311645&component=12311586&component=12311583&component=12310648&component=12311793&component=12311650&component=12310921&component=12311792&component=12311791&component=12311648&component=12311890&component=12310651&component=12310800&component=12311649&component=12310650&component=12310801&component=12311647&component=12311910&component=12310644&component=12311354&component=12310590&component=12310642&fixfor=-1&fixfor=-2&fixfor=12312358&sorter/field=issuekey&sorter/order=DESC
> >
> >
>
> As you may have noticed I've just moved over the rest of the easy JIRA
> that
> relate to samples for 1.1 and that mostly got deferred last time round.
> These are primarily README type fixes and take little effort to either fix
> or discount so I'll get on with them. I've still not had any feedback on
> how
> people feel about the harder technical JIRA that remain outstanding.
>
> Currently I'm waiting for a few things before I can potentially cut the
> branch. In particular,
>
> JMS
> Venkat's last policy changes (he's committed but there may be a few
> adjustments to make)
> Some help with the Saxon dependency
>
> This means the formal branch won't happen for a couple of days yet.
> However,
>
>
> Should we get some more of the outstanding JIRA fixed for 1.1?
> If so which ones (I moved some of the likely candidates to 1.1 before
> Christmas but not all), i.e. who is going to do what ?
>
> Personally there are a couple of domain related JIRAs I want to fix but I
> need to know from everyone whether I should go ahead and cut the branch
> (once I'm in a position to do so) or whether we are going to spend some
> time
> fixing JIRA.
>
> Thanks
>
> Simon
>

Does taking the branch have to wait for JMS? I'm a little behind so it may
be a day or two before the binding is in a releasable state but the branch
could still happen now and I'll can just copy over any changes.

   ...ant

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message