You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Dave Brondsema <da...@brondsema.net> on 2004/04/26 16:50:38 UTC
[vote] freeze for release
As mentioned on some earlier threads, we should do a release soon. I propose we
put a freeze on new development, finish existing work, and make a release.
Here's what I'm aware of for existing work that needs to be finished:
copyless branch
forrestbot2 deploy.cvs
move forrestbot2 into main
check all outstanding bugs in JIRA
Then after the release we can start working on some significant changes:
Nicola's promising (but backwards-compatiblity breaking) ideas for skinconf.xml
xhtml2
i18n
etc.
We might want to develop a roadmap (flexible of course) for features to be added
in the next release. nicola's branch-per-feature suggestion will help this be
work smoothly.
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: [vote] freeze for release
Posted by Upayavira <uv...@upaya.co.uk>.
Sjur Nørstebø Moshagen wrote:
> På 27. apr. 2004 kl. 13.25 skrev Nicola Ken Barozzi:
>
>> Sjur Nørstebø Moshagen wrote:
>> ...
>>
>>> I'm eagerly looking forward to Upayavira's work on i18n, and would
>>> like it to be included in the next release rather than be put off
>>> for the future. On the other hand I do understand (and also agree
>>> on) the reasons for releasing Forrest, so my vote would be something
>>> like
>>> +0.5
>>> (but +1 if i18n is ready to roll/be tested - how is it going,
>>> Upayavira?)
>>
>>
>> We can still do a 0.6.1 release some weeks after.
>
>
> That's fine with me.
Ah, but maybe it's not such a good idea - it lets me off the hook ;-)
Regards, Upayavira
Re: [vote] freeze for release
Posted by Sjur Nørstebø Moshagen <sj...@kolumbus.fi>.
På 27. apr. 2004 kl. 13.25 skrev Nicola Ken Barozzi:
> Sjur Nørstebø Moshagen wrote:
> ...
>> I'm eagerly looking forward to Upayavira's work on i18n, and would
>> like it to be included in the next release rather than be put off for
>> the future. On the other hand I do understand (and also agree on) the
>> reasons for releasing Forrest, so my vote would be something like
>> +0.5
>> (but +1 if i18n is ready to roll/be tested - how is it going,
>> Upayavira?)
>
> We can still do a 0.6.1 release some weeks after.
That's fine with me.
Sjur
Re: [vote] freeze for release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sjur Nørstebø Moshagen wrote:
...
> I'm eagerly looking forward to Upayavira's work on i18n, and would like
> it to be included in the next release rather than be put off for the
> future. On the other hand I do understand (and also agree on) the
> reasons for releasing Forrest, so my vote would be something like
>
> +0.5
> (but +1 if i18n is ready to roll/be tested - how is it going, Upayavira?)
We can still do a 0.6.1 release some weeks after.
> to the extent that my vote counts (this is my first vote - I read the
> Apache wiki on voting, but I don't consider myself a committer, one with
> voting power;)
Binding votes are cast only by project members, which, as far as the ASF
is concerned, are project PMC members. This is something that has
somehow been lost with the creation of umbrella projects like Xml and
Jakarta, where committers were not necessarily part of the project
PMC... which makes me think that we should now decide where to go from
Xml.Apache...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [vote] freeze for release
Posted by Sjur Nørstebø Moshagen <sj...@kolumbus.fi>.
På 26. apr. 2004 kl. 17.50 skrev Dave Brondsema:
>
> As mentioned on some earlier threads, we should do a release soon. I
> propose we
> put a freeze on new development, finish existing work, and make a
> release.
>
> Here's what I'm aware of for existing work that needs to be finished:
> copyless branch
> forrestbot2 deploy.cvs
> move forrestbot2 into main
> check all outstanding bugs in JIRA
>
> Then after the release we can start working on some significant
> changes:
> Nicola's promising (but backwards-compatiblity breaking) ideas for
> skinconf.xml
> xhtml2
> i18n
> etc.
I'm eagerly looking forward to Upayavira's work on i18n, and would like
it to be included in the next release rather than be put off for the
future. On the other hand I do understand (and also agree on) the
reasons for releasing Forrest, so my vote would be something like
+0.5
(but +1 if i18n is ready to roll/be tested - how is it going,
Upayavira?)
to the extent that my vote counts (this is my first vote - I read the
Apache wiki on voting, but I don't consider myself a committer, one
with voting power;)
Sjur
Re: [vote] freeze for release
Posted by Dave Brondsema <da...@brondsema.net>.
Quoting David Crossley <cr...@apache.org>:
> Juan Jose Pablos wrote:
> > Dave Brondsema escribió:
> > >
> > > We might want to develop a roadmap (flexible of course) for features to
> be added
> > > in the next release. nicola's branch-per-feature suggestion will help
> this be
> > > work smoothly.
> >
> > Done, You can check this roadmap on JIRA, I move all the bugs that holds
> > a PATCH and seem easy to add, plus the ones that need to be fixed:
> >
> >
> http://issues.cocoondev.org/jira/secure/BrowseProject.jspa?id=10000&report=roadmap
>
> Thanks Cheche. However it seems to be a roadmap of where we have been
> rather than where we are going to. I noticed that you moved many issues
> to be "Fix for 0.6". Would it be better to say "Fix for HEAD"? That way
> the "Unresolved" issues would show on the Roadmap.
>
> --David
>
I think the problem might be
<quote>
View issues due to be fixed in:
next 3 unreleased versions
</quote>
0.5 and 0.5.1 have already been released and are showing up. If an
administrator could mark those as released, I would guess that 0.6 tasks would
show up on that page.
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: [vote] freeze for release
Posted by Juan Jose Pablos <ch...@che-che.com>.
David,
David Crossley escribió:
> Juan Jose Pablos wrote:
>>Done, You can check this roadmap on JIRA, I move all the bugs that holds
>> a PATCH and seem easy to add, plus the ones that need to be fixed:
>>
>>http://issues.cocoondev.org/jira/secure/BrowseProject.jspa?id=10000&report=roadmap
>
>
> Thanks Cheche. However it seems to be a roadmap of where we have been
> rather than where we are going to. I noticed that you moved many issues
> to be "Fix for 0.6". Would it be better to say "Fix for HEAD"? That way
> the "Unresolved" issues would show on the Roadmap.
>
> --David
check this url for the openissues, you should see the 0.6 Version with
19 Bugs
http://issues.cocoondev.org/jira/secure/BrowseProject.jspa?id=10000&report=compversions
If I used "fix for HEAD", we will lose the ability to tell in wich
version was fix it.
Let me know if I am doing this right.
Cheers,
Cheche
Re: [vote] freeze for release
Posted by David Crossley <cr...@apache.org>.
Juan Jose Pablos wrote:
> Dave Brondsema escribió:
> >
> > We might want to develop a roadmap (flexible of course) for features to be added
> > in the next release. nicola's branch-per-feature suggestion will help this be
> > work smoothly.
>
> Done, You can check this roadmap on JIRA, I move all the bugs that holds
> a PATCH and seem easy to add, plus the ones that need to be fixed:
>
> http://issues.cocoondev.org/jira/secure/BrowseProject.jspa?id=10000&report=roadmap
Thanks Cheche. However it seems to be a roadmap of where we have been
rather than where we are going to. I noticed that you moved many issues
to be "Fix for 0.6". Would it be better to say "Fix for HEAD"? That way
the "Unresolved" issues would show on the Roadmap.
--David
Re: [vote] freeze for release
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave Brondsema escribió:
>
> We might want to develop a roadmap (flexible of course) for features to be added
> in the next release. nicola's branch-per-feature suggestion will help this be
> work smoothly.
>
Done, You can check this roadmap on JIRA, I move all the bugs that holds
a PATCH and seem easy to add, plus the ones that need to be fixed:
http://issues.cocoondev.org/jira/secure/BrowseProject.jspa?id=10000&report=roadmap
Cheers,
Cheche
Re: [vote] freeze for release
Posted by David Crossley <cr...@apache.org>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
>
> > As mentioned on some earlier threads, we should do a release soon. I propose we
> > put a freeze on new development, finish existing work, and make a release.
+1
> > Here's what I'm aware of for existing work that needs to be finished:
> > copyless branch
> > forrestbot2 deploy.cvs
> > move forrestbot2 into main
> > check all outstanding bugs in JIRA
And finish the "Re-licencing" job.
We need to all spend some time on Jira to classify and comment on bugs.
There seem to be many that do not show up on the Jira reports because
they are not classified properly.
> Add this too (should be in the bugs):
>
> - krysalis-site skin css images not generated in static site
> - krysalis-site skin menu border fix
> - switch to krysalis-site with Forrest colors for default forrest skin
Yes, and there is probably a lot of other stuff that was discussed
on the mailing list but not yet added as a Jira issue.
Is there any way to "search" for issues in Jira? This was a great
facility in Bugzilla.
--David
Re: [vote] freeze for release
Posted by Dave Brondsema <da...@brondsema.net>.
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
>> We might want to develop a roadmap (flexible of course) for features
>> to be added
>> in the next release. nicola's branch-per-feature suggestion will help
>> this be
>> work smoothly.
>
>
> I really agree, but instead I would put a date on the release.
>
> Releases are, let's say, every two months. Big features are done on
> their own branch. If we are more then 2 weeks from a release, we can
> merge from the branches, else we freeze the trunk and then release.
>
When we released 0.5 over 7 months ago you also suggested a 2-month
cycle.
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=forrest-dev@xml.apache.org&msgId=1023643
It sounds good in theory, but in practice every 3 or 4 months might be
better.
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal
Re: [vote] freeze for release
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> As mentioned on some earlier threads, we should do a release soon. I propose we
> put a freeze on new development, finish existing work, and make a release.
>
> Here's what I'm aware of for existing work that needs to be finished:
> copyless branch
> forrestbot2 deploy.cvs
> move forrestbot2 into main
> check all outstanding bugs in JIRA
+1
Add this too (should be in the bugs):
- krysalis-site skin css images not generated in static site
- krysalis-site skin menu border fix
- switch to krysalis-site with Forrest colors for default forrest skin
> Then after the release we can start working on some significant changes:
> Nicola's promising (but backwards-compatiblity breaking) ideas for skinconf.xml
> xhtml2
> i18n
> etc.
:-)
And forrestdoc too ;-)
> We might want to develop a roadmap (flexible of course) for features to be added
> in the next release. nicola's branch-per-feature suggestion will help this be
> work smoothly.
I really agree, but instead I would put a date on the release.
Releases are, let's say, every two months. Big features are done on
their own branch. If we are more then 2 weeks from a release, we can
merge from the branches, else we freeze the trunk and then release.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------