We're near the release of 1.0 final

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

We're near the release of 1.0 final

Emmanuel Venisse-2
Hi,

Now, we have only one issue to fix and all issues assigned to 1.0 will be fixed :)

I added two development guide in the site, it would be cool if you can look at it.

Emmanuel

Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

Dennis Lundberg-2
Emmanuel Venisse wrote:

> Hi,
>
> Now, we have only one issue to fix and all issues assigned to 1.0 will
> be fixed :)
>
> I added two development guide in the site, it would be cool if you can
> look at it.
>
> Emmanuel
>

As you might have seen by the commits, I have read through the new docs
and made some minor changes and fixes. I also had a look at the site as
a whole and removed some skin parts that are no longer needed.

--
Dennis Lundberg
Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

Emmanuel Venisse-2


Dennis Lundberg a écrit :

> Emmanuel Venisse wrote:
>> Hi,
>>
>> Now, we have only one issue to fix and all issues assigned to 1.0 will
>> be fixed :)
>>
>> I added two development guide in the site, it would be cool if you can
>> look at it.
>>
>> Emmanuel
>>
>
> As you might have seen by the commits, I have read through the new docs
> and made some minor changes and fixes. I also had a look at the site as
> a whole and removed some skin parts that are no longer needed.
>

Thanks Dennis.

Emmanuel

Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

Dennis Lundberg-2
In reply to this post by Emmanuel Venisse-2
Emmanuel Venisse wrote:
> Hi,
>
> Now, we have only one issue to fix and all issues assigned to 1.0 will
> be fixed :)

When building the site I noticed that Maven SCM is using
modello-maven-plugin 1.0-alpha-6, which is quite old. It is used for the
settings in provider implementations. The latest version of
modello-maven-plugin is alpha-15. Should I update it?

>
> I added two development guide in the site, it would be cool if you can
> look at it.
>
> Emmanuel
>


--
Dennis Lundberg
Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

Emmanuel Venisse-2


Dennis Lundberg a écrit :

> Emmanuel Venisse wrote:
>> Hi,
>>
>> Now, we have only one issue to fix and all issues assigned to 1.0 will
>> be fixed :)
>
> When building the site I noticed that Maven SCM is using
> modello-maven-plugin 1.0-alpha-6, which is quite old. It is used for the
> settings in provider implementations. The latest version of
> modello-maven-plugin is alpha-15. Should I update it?

Go for it.

>
>>
>> I added two development guide in the site, it would be cool if you can
>> look at it.
>>
>> Emmanuel
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

brettporter
Administrator
In reply to this post by Emmanuel Venisse-2
I think it's definitely time for another beta ASAP.

For 1.0, I'd still like to review (if not include) the following JIRAs.

High priority:
- SCM-17: I think the test structure needs some review, and we need  
to ensure all unit tests run fast and without the software installed.  
The TCK should be used to execute as integration tests when the  
software is installed. I think this sets us in a good position for a  
more stable API and the ability to have quality providers (per the  
other discussion on the list)
- SCM-156, 157, 158: TCK tests for various providers. Ties in to the  
above.
- SCM-18: it seems some commands are not currently implemented in  
some providers?

Note: I'm happy to cut down the number of providers for the 1.0  
release (and version the others as beta or have a larger sandbox) if  
that's what it takes. That would be more around the model of  
separated releases though.

Medium priority (because they might change the API it could be better  
to do before 1.0):
- SCM-21: separate revision and tag handling
- SCM-133: API clean up around repositories

Low priority:
- SCM-243: 'X' is treated as unknown in SVN. Seems like a simple fix,  
might be worth doing.

I'll also review the docs.

I think it's critical we have the testing in order before doing the  
1.0 release - wdyt?

- Brett

On 28/03/2007, at 2:37 AM, Emmanuel Venisse wrote:

> Hi,
>
> Now, we have only one issue to fix and all issues assigned to 1.0  
> will be fixed :)
>
> I added two development guide in the site, it would be cool if you  
> can look at it.
>
> Emmanuel
Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

brettporter
Administrator
In reply to this post by Emmanuel Venisse-2

On 28/03/2007, at 2:37 AM, Emmanuel Venisse wrote:

> I added two development guide in the site, it would be cool if you  
> can look at it.

The docs look good - thanks for that.

I have some questions about the SCM manager part: it's unclear about  
how getScmManager is used. It looks like something you'd get all the  
time, but you wouldn't want to start a new plexus container, or  
construct and add all the time. Maybe this needs to be altered a bit  
to be clearer?

Also, can we add a basic SCM manager to the release? That looks  
pretty straight-forward and would take care of the JIRA issue about  
creating a POJO facade.

For the commands: might be good to break these out into individual  
documents? I imagine there are probable more commands to list and  
document too.

Finally, on the site structure:
- I think more detail on the front page, as well as links to the  
guides is needed.
- The guides index page is missing one of the links
- need breadcrumbs so that when you go into the plugin site, you can  
get back
- we should have the javadoc for the API on the site somewhere
- should we move the SCM space to cwiki since it can be autoexported?  
Then we can put the provider matrix and the provider details pages  
together and link them in to the site as static pages
- do we need small guides on each provider that outline the  
differences/quirks/specific configuration needed?

Just lots of thoughts... not sure how many we need to do for 1.0 :)

wdyt?

- Brett
Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

Emmanuel Venisse-2
In reply to this post by brettporter


Brett Porter a écrit :

> I think it's definitely time for another beta ASAP.
>
> For 1.0, I'd still like to review (if not include) the following JIRAs.
>
> High priority:
> - SCM-17: I think the test structure needs some review, and we need to
> ensure all unit tests run fast and without the software installed. The
> TCK should be used to execute as integration tests when the software is
> installed. I think this sets us in a good position for a more stable API
> and the ability to have quality providers (per the other discussion on
> the list)

agreed

> - SCM-156, 157, 158: TCK tests for various providers. Ties in to the above.

we can't implement TCK tests for all providers without access to all SCM tools.
And it seems that contributors on providers without TCK implementation doesn't want or don't find time to do it, maybe it will be different when the TCK will be documented (I don't know yet how to
document it)

> - SCM-18: it seems some commands are not currently implemented in some
> providers?

Yes. I don't think the implementation of all commands is a requirement for a release.
1. If we don't allow to release without all commands, I'm not sure contributor will contribute more and they probably keep their provider private with what they need.
2. it isn't possible to implement all commands in all providers because some command aren't supported by some SCM tool
3. without contribution or an access to a SCM tool, we can't implement missing commands

>
> Note: I'm happy to cut down the number of providers for the 1.0 release
> (and version the others as beta or have a larger sandbox) if that's what
> it takes. That would be more around the model of separated releases though.
>
> Medium priority (because they might change the API it could be better to
> do before 1.0):
> - SCM-21: separate revision and tag handling

if we want it before 1.0, it would be good to implement it in a beta, so it will can be tested before the 1.0 release
I'm not sure we'll can do it easily in all providers without contribution. Probably possible if we keep in API the current behaviour.

> - SCM-133: API clean up around repositories

same comment for a new beta, but I'm thinking to a big API change for Maven-SCM 2 that will simplify provider implementation and will allow specific SCM options (I'll write a design doc about that later)

>
> Low priority:
> - SCM-243: 'X' is treated as unknown in SVN. Seems like a simple fix,
> might be worth doing.

Yes it's a simple fix I can include in the release. I'll like to parse svn properties changes too, but probably later.

>
> I'll also review the docs.
>
> I think it's critical we have the testing in order before doing the 1.0
> release - wdyt?

I'll move all IT tests under a src/it directory in each provider and try to document the TCK ASAP.

Emmanuel

>
> - Brett
>
> On 28/03/2007, at 2:37 AM, Emmanuel Venisse wrote:
>
>> Hi,
>>
>> Now, we have only one issue to fix and all issues assigned to 1.0 will
>> be fixed :)
>>
>> I added two development guide in the site, it would be cool if you can
>> look at it.
>>
>> Emmanuel
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

Emmanuel Venisse-2
In reply to this post by brettporter


Brett Porter a écrit :
>
> On 28/03/2007, at 2:37 AM, Emmanuel Venisse wrote:
>
>> I added two development guide in the site, it would be cool if you can
>> look at it.
>
> The docs look good - thanks for that.

cool :)

>
> I have some questions about the SCM manager part: it's unclear about how
> getScmManager is used. It looks like something you'd get all the time,
> but you wouldn't want to start a new plexus container, or construct and
> add all the time. Maybe this needs to be altered a bit to be clearer?

Yes, I wanted to change it today, with an initialize method and the getter that will return the container.

>
> Also, can we add a basic SCM manager to the release? That looks pretty
> straight-forward and would take care of the JIRA issue about creating a
> POJO facade.

sure. I'll modify the doc with it.

>
> For the commands: might be good to break these out into individual
> documents? I imagine there are probable more commands to list and
> document too.

ok

>
> Finally, on the site structure:
> - I think more detail on the front page, as well as links to the guides
> is needed.

ok

> - The guides index page is missing one of the links

ok

> - need breadcrumbs so that when you go into the plugin site, you can get
> back

ok

> - we should have the javadoc for the API on the site somewhere

sure.

> - should we move the SCM space to cwiki since it can be autoexported?
> Then we can put the provider matrix and the provider details pages
> together and link them in to the site as static pages

cwiki? where is it?

> - do we need small guides on each provider that outline the
> differences/quirks/specific configuration needed?

we already have it, each provider page provide informations but maybe we need more information

>
> Just lots of thoughts... not sure how many we need to do for 1.0 :)

I'll see what I can do :)

Emmanuel
>
> wdyt?
>
> - Brett
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

Jason van Zyl
In reply to this post by brettporter

On 27 Mar 07, at 9:50 PM 27 Mar 07, Brett Porter wrote:

>
> On 28/03/2007, at 2:37 AM, Emmanuel Venisse wrote:
>
> - should we move the SCM space to cwiki since it can be  
> autoexported? Then we can put the provider matrix and the provider  
> details pages together and link them in to the site as static pages
>

No, please don't fragment even more our documentation situation. We  
have the stuff in SVN, Confluence users spaces and developer works  
spaces. The autoexport could easily be setup with the space we have  
if it isn't already.

Jason.
Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

brettporter
Administrator

On 28/03/2007, at 10:35 PM, Jason van Zyl wrote:

>
> No, please don't fragment even more our documentation situation. We  
> have the stuff in SVN, Confluence users spaces and developer works  
> spaces. The autoexport could easily be setup with the space we have  
> if it isn't already.

This documentation is already in its own space, so it's low impact. I  
believe it is not currently editable by users, and only a couple of  
pages. This does no harm to the current situation, and gives us the  
opportunity to try it out.

Reasons I believe cwiki is a better choice:
- autoexport is already configured. No work to do.
- We have a greater level of access than we do at codehaus.
- No banner ads.
- It's back on the apache.org domain.

I don't see any downside...

Cheers,
Brett
Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

Emmanuel Venisse-2


Brett Porter a écrit :

>
> On 28/03/2007, at 10:35 PM, Jason van Zyl wrote:
>
>>
>> No, please don't fragment even more our documentation situation. We
>> have the stuff in SVN, Confluence users spaces and developer works
>> spaces. The autoexport could easily be setup with the space we have if
>> it isn't already.
>
> This documentation is already in its own space, so it's low impact. I
> believe it is not currently editable by users, and only a couple of
> pages. This does no harm to the current situation, and gives us the
> opportunity to try it out.

We have actually only one page in the codehaus wiki (the provider matrix).

>
> Reasons I believe cwiki is a better choice:
> - autoexport is already configured. No work to do.
> - We have a greater level of access than we do at codehaus.
> - No banner ads.
> - It's back on the apache.org domain.
>
> I don't see any downside...

We'd can use the codehaus wiki for our dev/design pages and for users pages we'd can use the cwiki with the autoexport and the maven css to include the content in our site.
I think it would be good to do it for our other products, so we'd can create easily cookbooks, but this ML isn't the place to discuss it ;)

Emmanuel

Reply | Threaded
Open this post in threaded view
|

Re: We're near the release of 1.0 final

Jason van Zyl
In reply to this post by brettporter

On 28 Mar 07, at 9:03 AM 28 Mar 07, Brett Porter wrote:

>
> On 28/03/2007, at 10:35 PM, Jason van Zyl wrote:
>
>>
>> No, please don't fragment even more our documentation situation.  
>> We have the stuff in SVN, Confluence users spaces and developer  
>> works spaces. The autoexport could easily be setup with the space  
>> we have if it isn't already.
>
> This documentation is already in its own space, so it's low impact.  
> I believe it is not currently editable by users, and only a couple  
> of pages. This does no harm to the current situation, and gives us  
> the opportunity to try it out.
>
> Reasons I believe cwiki is a better choice:
> - autoexport is already configured. No work to do.
> - We have a greater level of access than we do at codehaus.
> - No banner ads.
> - It's back on the apache.org domain.
>
> I don't see any downside...
>

Other then the severe one one of fragmenting our documentation. Do  
what you like.

Jason.

> Cheers,
> Brett
>