You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scm-dev@maven.apache.org by Emmanuel Venisse <em...@venisse.net> on 2007/03/27 18:37:47 UTC
We're near the release of 1.0 final
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
Re: We're near the release of 1.0 final
Posted by Emmanuel Venisse <em...@venisse.net>.
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
Re: We're near the release of 1.0 final
Posted by Dennis Lundberg <de...@apache.org>.
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
Re: We're near the release of 1.0 final
Posted by Emmanuel Venisse <em...@venisse.net>.
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
>
>
>
Re: We're near the release of 1.0 final
Posted by Brett Porter <br...@apache.org>.
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
Re: We're near the release of 1.0 final
Posted by Emmanuel Venisse <em...@venisse.net>.
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
>>
>
>
Re: We're near the release of 1.0 final
Posted by Dennis Lundberg <de...@apache.org>.
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
Re: We're near the release of 1.0 final
Posted by Emmanuel Venisse <em...@venisse.net>.
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
>
>
>
Re: confluence (was: We're near the release of 1.0 final)
Posted by David Blevins <da...@visi.com>.
On Mar 29, 2007, at 6:19 PM, Jeff Jensen wrote:
> Just not understanding yet the Maven
> plans for wiki/site usage. My fear, obviously, is continued
> "separate"
> works, as some people I helped with Maven have a "not happy-out-of-
> the-box
> experience", which includes scattered docs - I always have to give
> them
> multiple URLs for info and/or they keep Googling for answers.
>
> If you plan to integrate Maven site and the wiki so well like the
> examples
> you provided, then the user sees them as one source. Very nice.
Just a note on this aspect too. I have a confluence client library
which could be used in a plugin that automatically exports some or
all of the confluence content for inclusion in other works --
releases, etc. Might be some other fun things you with the ability
to easily read/write data from confluence.
Some javadoc here: http://swizzle.codehaus.org/swizzle-confluence/
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence (was: We're near the release of 1.0 final)
Posted by Brett Porter <br...@apache.org>.
On 30/03/2007, at 11:19 AM, Jeff Jensen wrote:
> So what are the plans for what each would contain - Maven site and
> wiki?
> Would Maven site contain only the generated tool docs (e.g. reports
> like
> Javadoc, PMD) and would the wiki contain only hand-written user docs?
I'd see the current site staying as it is (although we could work on
better provision of the tools stuff again).
We would have cookbook subsections of the site which would be the
MAVENUSER and similar spaces drawn in under the user guides section.
The MAVEN space would be arranged and brought under the developer
documentation section and used for design proposals.
>
> What I can't understand by just looking at those examples is how
> was all
> that content created? Did a "mvn site" run gen some and the hand
> created
> wiki pages link to it?
It's all created in confluence, and using the autoexport plugin it
regularly spits out static html. They use a template to produce the
look and feel. If you hit the edit links you can see the original
confluence system.
>
> No argument - those are nice sites. Just not understanding yet the
> Maven
> plans for wiki/site usage. My fear, obviously, is continued
> "separate"
> works, as some people I helped with Maven have a "not happy-out-of-
> the-box
> experience", which includes scattered docs - I always have to give
> them
> multiple URLs for info and/or they keep Googling for answers.
>
> If you plan to integrate Maven site and the wiki so well like the
> examples
> you provided, then the user sees them as one source. Very nice.
That's the theory :) Thanks for the feedback!
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: confluence (was: We're near the release of 1.0 final)
Posted by Jeff Jensen <je...@upstairstechnology.com>.
So what are the plans for what each would contain - Maven site and wiki?
Would Maven site contain only the generated tool docs (e.g. reports like
Javadoc, PMD) and would the wiki contain only hand-written user docs?
What I can't understand by just looking at those examples is how was all
that content created? Did a "mvn site" run gen some and the hand created
wiki pages link to it?
No argument - those are nice sites. Just not understanding yet the Maven
plans for wiki/site usage. My fear, obviously, is continued "separate"
works, as some people I helped with Maven have a "not happy-out-of-the-box
experience", which includes scattered docs - I always have to give them
multiple URLs for info and/or they keep Googling for answers.
If you plan to integrate Maven site and the wiki so well like the examples
you provided, then the user sees them as one source. Very nice.
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Thursday, March 29, 2007 7:34 PM
To: Maven Developers List
Subject: Re: confluence (was: We're near the release of 1.0 final)
That's exactly what this would provide.
While I don't propose moving the whole site to it, I think it makes sense as
an integrated subsite.
Take a look at these examples:
http://incubator.apache.org/openejb/
http://incubator.apache.org/openjpa/
http://geronimo.apache.org/
- Brett
On 30/03/2007, at 10:27 AM, Jeff Jensen wrote:
> I wish it was all in one place - Maven site.
>
> Too many don't know or don't go. If it must reside elsewhere, the
> link to external site docs must be very prominent.
>
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: Thursday, March 29, 2007 4:26 PM
> To: Maven Developers List
> Subject: Re: confluence (was: We're near the release of 1.0 final)
>
> [snip]
>
> Anyone else with 2 cents to spare?
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional
commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence (was: We're near the release of 1.0 final)
Posted by Jason Dillon <ja...@planet57.com>.
FYI, this is a better example of a sub-site:
http://geronimo.apache.org/xbean
This is from the XB space which we export into this directory under
our TLD. We used to do this before we had used the GMOxSITE space
for the site content, though now we use both. Soon we will be
stitching together a few spaces so that *most* content we have stored
in cwiki will be exported to a location under http://
geronimo.apache.org.
--jason
On Mar 29, 2007, at 5:33 PM, Brett Porter wrote:
> That's exactly what this would provide.
>
> While I don't propose moving the whole site to it, I think it makes
> sense as an integrated subsite.
>
> Take a look at these examples:
> http://incubator.apache.org/openejb/
> http://incubator.apache.org/openjpa/
> http://geronimo.apache.org/
>
> - Brett
>
> On 30/03/2007, at 10:27 AM, Jeff Jensen wrote:
>
>> I wish it was all in one place - Maven site.
>>
>> Too many don't know or don't go. If it must reside elsewhere, the
>> link to
>> external site docs must be very prominent.
>>
>>
>> -----Original Message-----
>> From: Brett Porter [mailto:brett@apache.org]
>> Sent: Thursday, March 29, 2007 4:26 PM
>> To: Maven Developers List
>> Subject: Re: confluence (was: We're near the release of 1.0 final)
>>
>> [snip]
>>
>> Anyone else with 2 cents to spare?
>>
>> - Brett
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence (was: We're near the release of 1.0 final)
Posted by Brett Porter <br...@apache.org>.
That's exactly what this would provide.
While I don't propose moving the whole site to it, I think it makes
sense as an integrated subsite.
Take a look at these examples:
http://incubator.apache.org/openejb/
http://incubator.apache.org/openjpa/
http://geronimo.apache.org/
- Brett
On 30/03/2007, at 10:27 AM, Jeff Jensen wrote:
> I wish it was all in one place - Maven site.
>
> Too many don't know or don't go. If it must reside elsewhere, the
> link to
> external site docs must be very prominent.
>
>
> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: Thursday, March 29, 2007 4:26 PM
> To: Maven Developers List
> Subject: Re: confluence (was: We're near the release of 1.0 final)
>
> [snip]
>
> Anyone else with 2 cents to spare?
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: confluence (was: We're near the release of 1.0 final)
Posted by Jeff Jensen <je...@upstairstechnology.com>.
I wish it was all in one place - Maven site.
Too many don't know or don't go. If it must reside elsewhere, the link to
external site docs must be very prominent.
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Thursday, March 29, 2007 4:26 PM
To: Maven Developers List
Subject: Re: confluence (was: We're near the release of 1.0 final)
[snip]
Anyone else with 2 cents to spare?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence (was: We're near the release of 1.0 final)
Posted by Brett Porter <br...@apache.org>.
On 29/03/2007, at 7:47 AM, John Casey wrote:
> I can't say that I care much one way or another, when it comes to
> moving all
> doco from the codehaus wiki to cwiki or leaving it as-is...provided
> the
> conversion is 100% successful, and cwiki is stable. The stability
> point is a
> concern for me, since I've seen some pretty ugly messes with ASF
> infra in
> the past.
I asked David Blevins and from a technical perspective he recommends
using cwiki. He has found it to be sufficiently stable and the
volunteers responsive.
>
> Of bigger concern to me is the fact that the MAVEN space is such a
> mess...
When we get to that point, I'd be happy to organise and document a
structure for it. It's not actually as messy as it looks.
>
> One thing that is interesting is that wiki content wouldn't be
> affected by
> confluence outages, since it's exported to the static pages...and
> I'm not
> sure it's a great idea to have something like setup that between
> ASF and
> codehaus...it's only adding moving parts that can fail.
Agreed.
>
> Is there a reason I should get fired up about either outcome?
Because you're fired up about documentation? :)
I think everyone agreed the cookbook idea was a good one before, I
think this is a concrete step towards making it happen.
Anyone else with 2 cents to spare?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence (was: We're near the release of 1.0 final)
Posted by John Casey <ca...@gmail.com>.
I can't say that I care much one way or another, when it comes to moving all
doco from the codehaus wiki to cwiki or leaving it as-is...provided the
conversion is 100% successful, and cwiki is stable. The stability point is a
concern for me, since I've seen some pretty ugly messes with ASF infra in
the past.
Of bigger concern to me is the fact that the MAVEN space is such a mess...
One thing that is interesting is that wiki content wouldn't be affected by
confluence outages, since it's exported to the static pages...and I'm not
sure it's a great idea to have something like setup that between ASF and
codehaus...it's only adding moving parts that can fail.
Is there a reason I should get fired up about either outcome?
-john
On 3/28/07, Brett Porter <br...@apache.org> wrote:
>
> (moving to main dev list as scope has increased)
>
> On 29/03/2007, at 12:28 AM, Jason van Zyl wrote:
>
> >
> > 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.
>
> On 28/03/2007, at 11:16 PM, Emmanuel Venisse wrote:
> > 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 ;)
>
> Similar to what Emmanuel suggested, how about we move *all* the
> current spaces to cwiki, avoiding any further fragmentation, and in
> fact removing the current fragmentation between the apache site and
> the codehaus confluence, as well as getting all of the above benefits?
>
> Before biting the bullet we can do a trial with this single SCM page.
>
> What do folks think?
>
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: confluence (was: We're near the release of 1.0 final)
Posted by Brett Porter <br...@apache.org>.
On 31/03/2007, at 2:21 AM, Jason van Zyl wrote:
>> We're better off on cwiki than where we are now. We have no admin
>> privileges (I'm currently locked out of editing the CONTINUUM space)
>
> Did you ask? I asked Ben for JIRA privs and that took 5 minutes.
Of course. It's now filed here: http://jira.codehaus.org/browse/
HAUS-1488
>
>> , and the setup is not conducive to deploying into the Apache
>> site. cwiki is already running the stuff we need. People I trust
>> recommend it.
>>
>
> The stuff is a plugin which can be installed in any Confluence
> instance. So that's not an onerous task.
>
>> We've wanted to do this for months, and this is an avenue that
>> actually makes it easier for us - I continue to suggest we take it.
>>
>
> I'm simply not in favour of moving anything away from Contegix.
> Taking the output from the export plugin and scp'ing it to people
> is not hard either.
Sure, it's not hard, but it's still less work to use cwiki. And
frankly, there's a difference between having admin access and admin
responsibility - the committers on this project are already
overcommitted without having to take on the project's infrastructure
responsibilities as well.
But, since there isn't consensus enough to move forward with even
trying it on that single SCM page, I'll revisit it later after you've
had a chance to try and set it up yourself.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence
Posted by Jason Dillon <ja...@planet57.com>.
There are some issues with autoexport, you guys might want to take a
peek at the HokeyPokey's exportspace command:
http://svn.apache.org/repos/asf/geronimo/sandbox/hokeypokey/trunk/
Its still a work in progress, but it basically exports a space via
xmlrpc and applies a velocity template and then does some massaging
of urls. Currently the massaging is hardcoded... the rules need to
be externalized. And the multi-space exporter needs to be hooked up
too.
But, the idea is to have a regular cron job execute the exporter
using templates and resources that are checked into svn, which makes
it easier to manage and allows for better oversight of template changes.
And by using this method pages with dynamic tags (like include or
jiraissues, etc) will also get refreshed.
Anyways... its a work in progress, but worth a look if you are just
getting started.
--jason
On Mar 30, 2007, at 12:19 PM, Jason van Zyl wrote:
>
> On 30 Mar 07, at 3:06 PM 30 Mar 07, Emmanuel Venisse wrote:
>
>>
>>
>> Jason van Zyl a écrit :
>>> On 30 Mar 07, at 10:49 AM 30 Mar 07, Brett Porter wrote:
>>>> While you make plenty of valid points about Contegix, it's
>>>> completely unrelated to what I'm arguing for.
>>> How is starting to move things away from Contegix, which is you
>>> suggestion, not related? The subsequent argument would then be
>>> made that we already started this process so why not move the
>>> rest. Of course it's related.
>>>> If you are successful in bringing them in to the ASF
>>>> infrastructure as you've proposed, it should be a no-brainer to
>>>> move a cwiki space to that infrastructure. So that's a non-issue
>>>> as far as this discussion is concerned.
>>>>
>>>> We're better off on cwiki than where we are now. We have no
>>>> admin privileges (I'm currently locked out of editing the
>>>> CONTINUUM space)
>>> Did you ask? I asked Ben for JIRA privs and that took 5 minutes.
>>>> , and the setup is not conducive to deploying into the Apache
>>>> site. cwiki is already running the stuff we need. People I trust
>>>> recommend it.
>>>>
>>> The stuff is a plugin which can be installed in any Confluence
>>> instance. So that's not an onerous task.
>>>> We've wanted to do this for months, and this is an avenue that
>>>> actually makes it easier for us - I continue to suggest we take it.
>>>>
>>> I'm simply not in favour of moving anything away from Contegix.
>>> Taking the output from the export plugin and scp'ing it to people
>>> is not hard either.
>>
>> If Ben is ok to install the plugin and if we can manage the scp to
>> people, it's ok for me. But I don't know how we'll can manage it,
>> we don't have shell access to codehaus.
>>
>
> The plugin will be installed and the PMC will have access:
>
> http://jira.codehaus.org/browse/HAUS-1489
>
> Jason.
>
>> Emmanuel
>>
>>> Jason.
>>>> - Brett
>>>>
>>>> On 31/03/2007, at 12:23 AM, Jason van Zyl wrote:
>>>>
>>>>> On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote:
>>>>>
>>>>>> (moving to main dev list as scope has increased)
>>>>>>
>>>>>> On 29/03/2007, at 12:28 AM, Jason van Zyl wrote:
>>>>>>
>>>>>> Similar to what Emmanuel suggested, how about we move *all*
>>>>>> the current spaces to cwiki, avoiding any further
>>>>>> fragmentation, and in fact removing the current fragmentation
>>>>>> between the apache site and the codehaus confluence, as well
>>>>>> as getting all of the above benefits?
>>>>>>
>>>>>> Before biting the bullet we can do a trial with this single
>>>>>> SCM page.
>>>>>>
>>>>>> What do folks think?
>>>>>>
>>>>>
>>>>> I think it's a bad idea to move from a stable setup we have
>>>>> with great support from people who have helped us at every
>>>>> turn. I would like to suggest we stay with Contegix wherever
>>>>> possible and this discussion is still ongoing with infra and
>>>>> they have yet to get back with SLA policies. I believe it is in
>>>>> the best interest of users and the community to provide the
>>>>> best infrastructure as possible and there is no doubt in my
>>>>> mind that is Contegix. For anything we have ever done for JIRA,
>>>>> Confluence or the Central Repository they have been there for
>>>>> us. We gain nothing by moving any of this to Apache.
>>>>>
>>>>> Contegix has run JIRA and Confluence for us when these services
>>>>> were not available at Apache and they have been more than
>>>>> accommodating when we needed a new repository infrastructure.
>>>>>
>>>>> I have been trying to incorporate Contegix officially into the
>>>>> infrastructure at Apache so that we can keep everyone happy. I
>>>>> am not willing, nor do I support any move to Apache without
>>>>> infra deciding their policies, nor am I overly excited about
>>>>> the possibility of any of our infrastructure being moved to a
>>>>> place where no one is really accountable. Contegix is
>>>>> responsible, accountable, a pleasure to work with and they have
>>>>> bent over backward to help us. We are relying on Jeff Turner
>>>>> who is already overworked in trying to manage our setup whereas
>>>>> at Contegix we have a team who are very knowledgeable about
>>>>> Atlassian products because they resell them. We also have
>>>>> people here who's first response is a derisive comment about
>>>>> the tools we use.
>>>>>
>>>>> My vote is for Contegix to continue the great job they have
>>>>> done and seeing as infra has not decided anything or contacted
>>>>> me after I attended the last board meeting, I am going to go
>>>>> ahead with an official proposal starting with our PMC to let
>>>>> each PMC decide on their infrastructure needs and use whomever
>>>>> they like working on the integration strategies and policies
>>>>> that will make everyone comfortable. Until that time I don't
>>>>> think it's prudent because you will potentially jeopardize the
>>>>> infrastructure used by everyone using Maven.
>>>>>
>>>>> Jason.
>>>>>
>>>>>> Cheers,
>>>>>> Brett
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> ----
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence
Posted by Jason van Zyl <ja...@maven.org>.
On 30 Mar 07, at 3:06 PM 30 Mar 07, Emmanuel Venisse wrote:
>
>
> Jason van Zyl a écrit :
>> On 30 Mar 07, at 10:49 AM 30 Mar 07, Brett Porter wrote:
>>> While you make plenty of valid points about Contegix, it's
>>> completely unrelated to what I'm arguing for.
>> How is starting to move things away from Contegix, which is you
>> suggestion, not related? The subsequent argument would then be
>> made that we already started this process so why not move the
>> rest. Of course it's related.
>>> If you are successful in bringing them in to the ASF
>>> infrastructure as you've proposed, it should be a no-brainer to
>>> move a cwiki space to that infrastructure. So that's a non-issue
>>> as far as this discussion is concerned.
>>>
>>> We're better off on cwiki than where we are now. We have no admin
>>> privileges (I'm currently locked out of editing the CONTINUUM space)
>> Did you ask? I asked Ben for JIRA privs and that took 5 minutes.
>>> , and the setup is not conducive to deploying into the Apache
>>> site. cwiki is already running the stuff we need. People I trust
>>> recommend it.
>>>
>> The stuff is a plugin which can be installed in any Confluence
>> instance. So that's not an onerous task.
>>> We've wanted to do this for months, and this is an avenue that
>>> actually makes it easier for us - I continue to suggest we take it.
>>>
>> I'm simply not in favour of moving anything away from Contegix.
>> Taking the output from the export plugin and scp'ing it to people
>> is not hard either.
>
> If Ben is ok to install the plugin and if we can manage the scp to
> people, it's ok for me. But I don't know how we'll can manage it,
> we don't have shell access to codehaus.
>
The plugin will be installed and the PMC will have access:
http://jira.codehaus.org/browse/HAUS-1489
Jason.
> Emmanuel
>
>> Jason.
>>> - Brett
>>>
>>> On 31/03/2007, at 12:23 AM, Jason van Zyl wrote:
>>>
>>>> On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote:
>>>>
>>>>> (moving to main dev list as scope has increased)
>>>>>
>>>>> On 29/03/2007, at 12:28 AM, Jason van Zyl wrote:
>>>>>
>>>>> Similar to what Emmanuel suggested, how about we move *all* the
>>>>> current spaces to cwiki, avoiding any further fragmentation,
>>>>> and in fact removing the current fragmentation between the
>>>>> apache site and the codehaus confluence, as well as getting all
>>>>> of the above benefits?
>>>>>
>>>>> Before biting the bullet we can do a trial with this single SCM
>>>>> page.
>>>>>
>>>>> What do folks think?
>>>>>
>>>>
>>>> I think it's a bad idea to move from a stable setup we have with
>>>> great support from people who have helped us at every turn. I
>>>> would like to suggest we stay with Contegix wherever possible
>>>> and this discussion is still ongoing with infra and they have
>>>> yet to get back with SLA policies. I believe it is in the best
>>>> interest of users and the community to provide the best
>>>> infrastructure as possible and there is no doubt in my mind that
>>>> is Contegix. For anything we have ever done for JIRA, Confluence
>>>> or the Central Repository they have been there for us. We gain
>>>> nothing by moving any of this to Apache.
>>>>
>>>> Contegix has run JIRA and Confluence for us when these services
>>>> were not available at Apache and they have been more than
>>>> accommodating when we needed a new repository infrastructure.
>>>>
>>>> I have been trying to incorporate Contegix officially into the
>>>> infrastructure at Apache so that we can keep everyone happy. I
>>>> am not willing, nor do I support any move to Apache without
>>>> infra deciding their policies, nor am I overly excited about the
>>>> possibility of any of our infrastructure being moved to a place
>>>> where no one is really accountable. Contegix is responsible,
>>>> accountable, a pleasure to work with and they have bent over
>>>> backward to help us. We are relying on Jeff Turner who is
>>>> already overworked in trying to manage our setup whereas at
>>>> Contegix we have a team who are very knowledgeable about
>>>> Atlassian products because they resell them. We also have people
>>>> here who's first response is a derisive comment about the tools
>>>> we use.
>>>>
>>>> My vote is for Contegix to continue the great job they have done
>>>> and seeing as infra has not decided anything or contacted me
>>>> after I attended the last board meeting, I am going to go ahead
>>>> with an official proposal starting with our PMC to let each PMC
>>>> decide on their infrastructure needs and use whomever they like
>>>> working on the integration strategies and policies that will
>>>> make everyone comfortable. Until that time I don't think it's
>>>> prudent because you will potentially jeopardize the
>>>> infrastructure used by everyone using Maven.
>>>>
>>>> Jason.
>>>>
>>>>> Cheers,
>>>>> Brett
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ---
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence
Posted by Emmanuel Venisse <em...@venisse.net>.
Jason van Zyl a écrit :
>
> On 30 Mar 07, at 10:49 AM 30 Mar 07, Brett Porter wrote:
>
>> While you make plenty of valid points about Contegix, it's completely
>> unrelated to what I'm arguing for.
>
> How is starting to move things away from Contegix, which is you
> suggestion, not related? The subsequent argument would then be made that
> we already started this process so why not move the rest. Of course it's
> related.
>
>> If you are successful in bringing them in to the ASF infrastructure as
>> you've proposed, it should be a no-brainer to move a cwiki space to
>> that infrastructure. So that's a non-issue as far as this discussion
>> is concerned.
>>
>> We're better off on cwiki than where we are now. We have no admin
>> privileges (I'm currently locked out of editing the CONTINUUM space)
>
> Did you ask? I asked Ben for JIRA privs and that took 5 minutes.
>
>> , and the setup is not conducive to deploying into the Apache site.
>> cwiki is already running the stuff we need. People I trust recommend it.
>>
>
> The stuff is a plugin which can be installed in any Confluence instance.
> So that's not an onerous task.
>
>> We've wanted to do this for months, and this is an avenue that
>> actually makes it easier for us - I continue to suggest we take it.
>>
>
> I'm simply not in favour of moving anything away from Contegix. Taking
> the output from the export plugin and scp'ing it to people is not hard
> either.
If Ben is ok to install the plugin and if we can manage the scp to people, it's ok for me. But I don't know how we'll can manage it, we don't have shell access to codehaus.
Emmanuel
>
> Jason.
>
>> - Brett
>>
>> On 31/03/2007, at 12:23 AM, Jason van Zyl wrote:
>>
>>> On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote:
>>>
>>>> (moving to main dev list as scope has increased)
>>>>
>>>> On 29/03/2007, at 12:28 AM, Jason van Zyl wrote:
>>>>
>>>> Similar to what Emmanuel suggested, how about we move *all* the
>>>> current spaces to cwiki, avoiding any further fragmentation, and in
>>>> fact removing the current fragmentation between the apache site and
>>>> the codehaus confluence, as well as getting all of the above benefits?
>>>>
>>>> Before biting the bullet we can do a trial with this single SCM page.
>>>>
>>>> What do folks think?
>>>>
>>>
>>> I think it's a bad idea to move from a stable setup we have with
>>> great support from people who have helped us at every turn. I would
>>> like to suggest we stay with Contegix wherever possible and this
>>> discussion is still ongoing with infra and they have yet to get back
>>> with SLA policies. I believe it is in the best interest of users and
>>> the community to provide the best infrastructure as possible and
>>> there is no doubt in my mind that is Contegix. For anything we have
>>> ever done for JIRA, Confluence or the Central Repository they have
>>> been there for us. We gain nothing by moving any of this to Apache.
>>>
>>> Contegix has run JIRA and Confluence for us when these services were
>>> not available at Apache and they have been more than accommodating
>>> when we needed a new repository infrastructure.
>>>
>>> I have been trying to incorporate Contegix officially into the
>>> infrastructure at Apache so that we can keep everyone happy. I am not
>>> willing, nor do I support any move to Apache without infra deciding
>>> their policies, nor am I overly excited about the possibility of any
>>> of our infrastructure being moved to a place where no one is really
>>> accountable. Contegix is responsible, accountable, a pleasure to work
>>> with and they have bent over backward to help us. We are relying on
>>> Jeff Turner who is already overworked in trying to manage our setup
>>> whereas at Contegix we have a team who are very knowledgeable about
>>> Atlassian products because they resell them. We also have people here
>>> who's first response is a derisive comment about the tools we use.
>>>
>>> My vote is for Contegix to continue the great job they have done and
>>> seeing as infra has not decided anything or contacted me after I
>>> attended the last board meeting, I am going to go ahead with an
>>> official proposal starting with our PMC to let each PMC decide on
>>> their infrastructure needs and use whomever they like working on the
>>> integration strategies and policies that will make everyone
>>> comfortable. Until that time I don't think it's prudent because you
>>> will potentially jeopardize the infrastructure used by everyone
>>> using Maven.
>>>
>>> Jason.
>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence (was: We're near the release of 1.0 final)
Posted by Jason van Zyl <ja...@maven.org>.
On 30 Mar 07, at 10:49 AM 30 Mar 07, Brett Porter wrote:
> While you make plenty of valid points about Contegix, it's
> completely unrelated to what I'm arguing for.
How is starting to move things away from Contegix, which is you
suggestion, not related? The subsequent argument would then be made
that we already started this process so why not move the rest. Of
course it's related.
> If you are successful in bringing them in to the ASF infrastructure
> as you've proposed, it should be a no-brainer to move a cwiki space
> to that infrastructure. So that's a non-issue as far as this
> discussion is concerned.
>
> We're better off on cwiki than where we are now. We have no admin
> privileges (I'm currently locked out of editing the CONTINUUM space)
Did you ask? I asked Ben for JIRA privs and that took 5 minutes.
> , and the setup is not conducive to deploying into the Apache site.
> cwiki is already running the stuff we need. People I trust
> recommend it.
>
The stuff is a plugin which can be installed in any Confluence
instance. So that's not an onerous task.
> We've wanted to do this for months, and this is an avenue that
> actually makes it easier for us - I continue to suggest we take it.
>
I'm simply not in favour of moving anything away from Contegix.
Taking the output from the export plugin and scp'ing it to people is
not hard either.
Jason.
> - Brett
>
> On 31/03/2007, at 12:23 AM, Jason van Zyl wrote:
>
>> On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote:
>>
>>> (moving to main dev list as scope has increased)
>>>
>>> On 29/03/2007, at 12:28 AM, Jason van Zyl wrote:
>>>
>>> Similar to what Emmanuel suggested, how about we move *all* the
>>> current spaces to cwiki, avoiding any further fragmentation, and
>>> in fact removing the current fragmentation between the apache
>>> site and the codehaus confluence, as well as getting all of the
>>> above benefits?
>>>
>>> Before biting the bullet we can do a trial with this single SCM
>>> page.
>>>
>>> What do folks think?
>>>
>>
>> I think it's a bad idea to move from a stable setup we have with
>> great support from people who have helped us at every turn. I
>> would like to suggest we stay with Contegix wherever possible and
>> this discussion is still ongoing with infra and they have yet to
>> get back with SLA policies. I believe it is in the best interest
>> of users and the community to provide the best infrastructure as
>> possible and there is no doubt in my mind that is Contegix. For
>> anything we have ever done for JIRA, Confluence or the Central
>> Repository they have been there for us. We gain nothing by moving
>> any of this to Apache.
>>
>> Contegix has run JIRA and Confluence for us when these services
>> were not available at Apache and they have been more than
>> accommodating when we needed a new repository infrastructure.
>>
>> I have been trying to incorporate Contegix officially into the
>> infrastructure at Apache so that we can keep everyone happy. I am
>> not willing, nor do I support any move to Apache without infra
>> deciding their policies, nor am I overly excited about the
>> possibility of any of our infrastructure being moved to a place
>> where no one is really accountable. Contegix is responsible,
>> accountable, a pleasure to work with and they have bent over
>> backward to help us. We are relying on Jeff Turner who is already
>> overworked in trying to manage our setup whereas at Contegix we
>> have a team who are very knowledgeable about Atlassian products
>> because they resell them. We also have people here who's first
>> response is a derisive comment about the tools we use.
>>
>> My vote is for Contegix to continue the great job they have done
>> and seeing as infra has not decided anything or contacted me after
>> I attended the last board meeting, I am going to go ahead with an
>> official proposal starting with our PMC to let each PMC decide on
>> their infrastructure needs and use whomever they like working on
>> the integration strategies and policies that will make everyone
>> comfortable. Until that time I don't think it's prudent because
>> you will potentially jeopardize the infrastructure used by
>> everyone using Maven.
>>
>> Jason.
>>
>>> Cheers,
>>> Brett
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence (was: We're near the release of 1.0 final)
Posted by Brett Porter <br...@apache.org>.
While you make plenty of valid points about Contegix, it's completely
unrelated to what I'm arguing for. If you are successful in bringing
them in to the ASF infrastructure as you've proposed, it should be a
no-brainer to move a cwiki space to that infrastructure. So that's a
non-issue as far as this discussion is concerned.
We're better off on cwiki than where we are now. We have no admin
privileges (I'm currently locked out of editing the CONTINUUM space),
and the setup is not conducive to deploying into the Apache site.
cwiki is already running the stuff we need. People I trust recommend it.
We've wanted to do this for months, and this is an avenue that
actually makes it easier for us - I continue to suggest we take it.
- Brett
On 31/03/2007, at 12:23 AM, Jason van Zyl wrote:
> On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote:
>
>> (moving to main dev list as scope has increased)
>>
>> On 29/03/2007, at 12:28 AM, Jason van Zyl wrote:
>>
>> Similar to what Emmanuel suggested, how about we move *all* the
>> current spaces to cwiki, avoiding any further fragmentation, and
>> in fact removing the current fragmentation between the apache site
>> and the codehaus confluence, as well as getting all of the above
>> benefits?
>>
>> Before biting the bullet we can do a trial with this single SCM page.
>>
>> What do folks think?
>>
>
> I think it's a bad idea to move from a stable setup we have with
> great support from people who have helped us at every turn. I would
> like to suggest we stay with Contegix wherever possible and this
> discussion is still ongoing with infra and they have yet to get
> back with SLA policies. I believe it is in the best interest of
> users and the community to provide the best infrastructure as
> possible and there is no doubt in my mind that is Contegix. For
> anything we have ever done for JIRA, Confluence or the Central
> Repository they have been there for us. We gain nothing by moving
> any of this to Apache.
>
> Contegix has run JIRA and Confluence for us when these services
> were not available at Apache and they have been more than
> accommodating when we needed a new repository infrastructure.
>
> I have been trying to incorporate Contegix officially into the
> infrastructure at Apache so that we can keep everyone happy. I am
> not willing, nor do I support any move to Apache without infra
> deciding their policies, nor am I overly excited about the
> possibility of any of our infrastructure being moved to a place
> where no one is really accountable. Contegix is responsible,
> accountable, a pleasure to work with and they have bent over
> backward to help us. We are relying on Jeff Turner who is already
> overworked in trying to manage our setup whereas at Contegix we
> have a team who are very knowledgeable about Atlassian products
> because they resell them. We also have people here who's first
> response is a derisive comment about the tools we use.
>
> My vote is for Contegix to continue the great job they have done
> and seeing as infra has not decided anything or contacted me after
> I attended the last board meeting, I am going to go ahead with an
> official proposal starting with our PMC to let each PMC decide on
> their infrastructure needs and use whomever they like working on
> the integration strategies and policies that will make everyone
> comfortable. Until that time I don't think it's prudent because you
> will potentially jeopardize the infrastructure used by everyone
> using Maven.
>
> Jason.
>
>> Cheers,
>> Brett
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence (was: We're near the release of 1.0 final)
Posted by Jason van Zyl <ja...@maven.org>.
On 28 Mar 07, at 5:22 PM 28 Mar 07, Brett Porter wrote:
> (moving to main dev list as scope has increased)
>
> On 29/03/2007, at 12:28 AM, Jason van Zyl wrote:
>
> Similar to what Emmanuel suggested, how about we move *all* the
> current spaces to cwiki, avoiding any further fragmentation, and in
> fact removing the current fragmentation between the apache site and
> the codehaus confluence, as well as getting all of the above benefits?
>
> Before biting the bullet we can do a trial with this single SCM page.
>
> What do folks think?
>
I think it's a bad idea to move from a stable setup we have with
great support from people who have helped us at every turn. I would
like to suggest we stay with Contegix wherever possible and this
discussion is still ongoing with infra and they have yet to get back
with SLA policies. I believe it is in the best interest of users and
the community to provide the best infrastructure as possible and
there is no doubt in my mind that is Contegix. For anything we have
ever done for JIRA, Confluence or the Central Repository they have
been there for us. We gain nothing by moving any of this to Apache.
Contegix has run JIRA and Confluence for us when these services were
not available at Apache and they have been more than accommodating
when we needed a new repository infrastructure.
I have been trying to incorporate Contegix officially into the
infrastructure at Apache so that we can keep everyone happy. I am not
willing, nor do I support any move to Apache without infra deciding
their policies, nor am I overly excited about the possibility of any
of our infrastructure being moved to a place where no one is really
accountable. Contegix is responsible, accountable, a pleasure to work
with and they have bent over backward to help us. We are relying on
Jeff Turner who is already overworked in trying to manage our setup
whereas at Contegix we have a team who are very knowledgeable about
Atlassian products because they resell them. We also have people here
who's first response is a derisive comment about the tools we use.
My vote is for Contegix to continue the great job they have done and
seeing as infra has not decided anything or contacted me after I
attended the last board meeting, I am going to go ahead with an
official proposal starting with our PMC to let each PMC decide on
their infrastructure needs and use whomever they like working on the
integration strategies and policies that will make everyone
comfortable. Until that time I don't think it's prudent because you
will potentially jeopardize the infrastructure used by everyone
using Maven.
Jason.
> Cheers,
> Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: confluence (was: We're near the release of 1.0 final)
Posted by Brett Porter <br...@apache.org>.
(moving to main dev list as scope has increased)
On 29/03/2007, at 12:28 AM, Jason van Zyl wrote:
>
> 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.
On 28/03/2007, at 11:16 PM, Emmanuel Venisse wrote:
> 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 ;)
Similar to what Emmanuel suggested, how about we move *all* the
current spaces to cwiki, avoiding any further fragmentation, and in
fact removing the current fragmentation between the apache site and
the codehaus confluence, as well as getting all of the above benefits?
Before biting the bullet we can do a trial with this single SCM page.
What do folks think?
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: We're near the release of 1.0 final
Posted by Jason van Zyl <ja...@maven.org>.
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
>
Re: We're near the release of 1.0 final
Posted by Emmanuel Venisse <em...@venisse.net>.
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
Re: We're near the release of 1.0 final
Posted by Brett Porter <br...@apache.org>.
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
Re: We're near the release of 1.0 final
Posted by Jason van Zyl <ja...@maven.org>.
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.
Re: We're near the release of 1.0 final
Posted by Brett Porter <br...@apache.org>.
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