Looks good in general. I found it a little confusing how the info was
split across the two pages (Home and All Proposals). How about
changing the All Proposals page to encapsulate all proposal
information in one table? It would look similar to the
work-in-progress table on Home, but it could
On 27 Jun 07, at 6:15 AM 27 Jun 07, Mark Hobson wrote:
Looks good in general. I found it a little confusing how the info was
split across the two pages (Home and All Proposals). How about
changing the All Proposals page to encapsulate all proposal
information in one table? It would look
On 27/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 27 Jun 07, at 6:15 AM 27 Jun 07, Mark Hobson wrote:
Looks good in general. I found it a little confusing how the info was
split across the two pages (Home and All Proposals). How about
changing the All Proposals page to encapsulate all
On 27 Jun 07, at 7:15 AM 27 Jun 07, Mark Hobson wrote:
On 27/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 27 Jun 07, at 6:15 AM 27 Jun 07, Mark Hobson wrote:
Looks good in general. I found it a little confusing how the
info was
split across the two pages (Home and All Proposals).
On 27/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
I think I like having a listing of the work in progress on the main
page so that you don't have to click to another page to see the work
in progress.
That said I like them all on one page, but I would like to extract
the current ongoing work
On 27 Jun 07, at 8:55 AM 27 Jun 07, Mark Hobson wrote:
On 27/06/07, Jason van Zyl [EMAIL PROTECTED] wrote:
I think I like having a listing of the work in progress on the main
page so that you don't have to click to another page to see the work
in progress.
That said I like them all on one
I'm coming into the thread late so I see lots of updates already. I
second the suggestion that having two states called Approved
Proposal(s) is a little confusing. I think that the move to a
Completed Proposals can be used to combine the Completed and
Approved Proposals because there doesn't seem
On 6/26/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 25 Jun 07, at 7:11 PM 25 Jun 07, John Casey wrote:
I like this approach, and I think it's just a slightly more
detailed version
of what some of us are already trying to do when we put together
major new
pieces for Maven. I agree with
On 26 Jun 07, at 6:46 AM 26 Jun 07, Jesse McConnell wrote:
On 6/26/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 25 Jun 07, at 7:11 PM 25 Jun 07, John Casey wrote:
I like this approach, and I think it's just a slightly more
detailed version
of what some of us are already trying to do
Looking over the current page, I see one mention of the Embedder. I'm
unclear whether there are plans to release any embedder updates in the
2.0.* line. From the The Embedder for all client use in 2.1, I'm also
unsure if the Embedder is to be released in the 2.1 line either.
We're currently using
A few things:
1. Can I get edit access? My username is 'pschneider'.
2. Are there any thoughts re: how pages are parented? I noticed that only
the 'Toolchains' proposal is parented by 'All Proposals'. Most of the rest
seem to be under 'Maven 2.1 Design Documents'. It would be nice to see,
On 26 Jun 07, at 1:20 PM 26 Jun 07, Patrick Schneider wrote:
A few things:
1. Can I get edit access? My username is 'pschneider'.
Sure. I'll find all the user names and add them to the group.
2. Are there any thoughts re: how pages are parented? I noticed
that only
the 'Toolchains'
On 6/26/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 26 Jun 07, at 1:20 PM 26 Jun 07, Patrick Schneider wrote:
A few things:
1. Can I get edit access? My username is 'pschneider'.
Sure. I'll find all the user names and add them to the group.
2. Are there any thoughts re: how pages
The proposal looks generally ok to me. I'll try to follow it when
working on Toolchains. I'm sure I'll have questions on the way.
more regarding api changes below.
On 6/26/07, John Casey [EMAIL PROTECTED] wrote:
I like this approach, and I think it's just a slightly more detailed version
of
On 26 Jun 07, at 2:05 PM 26 Jun 07, Patrick Schneider wrote:
Ok, so the new features start on trunk but the new feature is a
branch of trunk. The point being feature additions don't destabilize
the trunk. The series of branches associated with issues also
provides a clear path of what
Hi Jason,
Sounds very good to me. You're right that making things surface is a
good thing. It requires more discipline but Maven being so successful
and so many people relying on it now makes it a necessity I think to
better control its evolution.
Now all you need is a good wiki that
Not that this is really the thread for it, but +1 on trying out xwiki!
Namely because Vincent is an insider (always nice to have) and I never
really liked Confluence much anyway.
Eric
Not an XWiki Developer ;-)
On 6/26/07, Vincent Massol [EMAIL PROTECTED] wrote:
Hi Jason,
Sounds very good to
Looks good.
Basically it revolves around making sure things are documented in the
Wiki and providing a clear record of the evolution of the project
that anyone can follow at any point in time. So far from perfect but
I think a good starting point and I would like to field feedback so I
can
I kind of like the idea of this process applying to any API change - even if
it's just a bug fix, not necessarily a feature request.
It would also be nice to either have the Work articles under Work in
Progress themselves contain contain the related JIRA issues (since there
could be more than
I like this approach, and I think it's just a slightly more detailed version
of what some of us are already trying to do when we put together major new
pieces for Maven. I agree with Eric that any API or behavioral change should
probably follow this process, basically anything that could change
On 25 Jun 07, at 6:55 PM 25 Jun 07, Barrie Treloar wrote:
Looks good.
Basically it revolves around making sure things are documented in the
Wiki and providing a clear record of the evolution of the project
that anyone can follow at any point in time. So far from perfect but
I think a good
On 25 Jun 07, at 6:59 PM 25 Jun 07, Eric Redmond wrote:
I kind of like the idea of this process applying to any API change
- even if
it's just a bug fix, not necessarily a feature request.
It would also be nice to either have the Work articles under
Work in
Progress themselves contain
On 25 Jun 07, at 7:11 PM 25 Jun 07, John Casey wrote:
I like this approach, and I think it's just a slightly more
detailed version
of what some of us are already trying to do when we put together
major new
pieces for Maven. I agree with Eric that any API or behavioral
change should
23 matches
Mail list logo
