You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by Deng Ching <oc...@apache.org> on 2010/09/10 07:35:40 UTC

Re: reviewing the staging branch

Sorry, I didn't notice this one. I'll review the branch this weekend
and will send a separate thread for merging it to trunk :) Once it's
been merged, I propose that we kick-off a milestone release.

Thanks,
Deng

On Wed, Aug 25, 2010 at 2:40 PM, Brett Porter <br...@apache.org> wrote:
>
> On 05/08/2010, at 11:29 AM, Deng Ching wrote:
>
>> For MRM-980 branch, the merging and resolving of conflicting versions are
>> already working. The artifacts merged are also being logged in the audit
>> logs now.
>>
>> Aside from the bugs that need to be fixed (see linked issues in MRM-980
>> jira), what's left to be done are the webapp tests and the documentation.
>> I think the webapp-tests might be broken on the branch as the layout and
>> data displayed in the repositories page were broken (MRM-1398). Once these
>> are fixed and the webapp tests and docs are written, we can already merge
>> the branch to trunk.
>>
>> As for a milestone release, I suggest we do one after the merge..
>
> Any further plans in this regard?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
>
>
>

Re: reviewing the staging branch

Posted by Deng Ching <oc...@apache.org>.
On Sun, Sep 12, 2010 at 4:07 AM, Wendy Smoak <ws...@gmail.com> wrote:
> On Fri, Sep 10, 2010 at 1:35 AM, Deng Ching <oc...@apache.org> wrote:
>> Sorry, I didn't notice this one. I'll review the branch this weekend
>> and will send a separate thread for merging it to trunk :) Once it's
>> been merged, I propose that we kick-off a milestone release.
>
> Should we do a release before the merge?  I think trunk already has
> some significant changes, but I'm also not sure how big this change
> (staging) is.
>

I'm fine if we do milestone releases of trunk before and after the merge :)

> I built the MRM-980 branch and tried it out.  My first impression is
> that it wandered well away from the feature described in the issue.
> All I wanted was to be able to merge two existing repositories!  I
> think that's in there somewhere though. :)  Still, the JIRA issue
> should be edited to describe what got implemented so the release notes
> are clear.
>
> I tried a couple of simple merges and it works fine, including warning
> about conflicts (duplicates.)
>
> A few things I jotted down:
>
> I couldn't find a link to the docs on the staging feature, though a
> text search did turn up adminguide/staging-repositories.html .

There should be a link in the left navigation: Runtime Configuration
>> Staging Repositories

>
> I tried adding a staging repository to the default "internal"
> repository, and it did not work.  Editing "internal" again shows the
> box is checked, but it will not display the location of the repo or
> show the 'Merge' button after saving.  However, I noticed that
> internal-stage was in the list when I went to upload an artifact.  The
> docs say, "The snapshots and internal repositories configured in
> Archiva by default, are not configured with attached staging
> repositories." which I take to mean the staging repo is not there by
> default but it _should_ be possible to add one.

This looks like a bug..

>
> Logging during the merge only shows the artifact filename.  (Needs to
> include the groupId to uniquely identify the artifact.)
>
> Overall I think the underlying merge feature is solid, (thanks Eshan!)
> but the UI feels a bit rough.  For example, un-checking a box to
> delete the staging repo is not intuitive, nor does it give you a
> chance to confirm this destructive action.  And the warning about not
> merging snapshots should probably only be displayed if there *are*
> snapshots in the staging repo that won't be merged, otherwise it just
> scares people unnecessarily.
>

+1

> I'm going to update the docs on the branch based on my user
> experience.  I'll ping the list for a review so someone can flag
> differences between what I say it does and what was intended. :)

Thanks Wendy!

-Deng

Re: reviewing the staging branch

Posted by Wendy Smoak <ws...@gmail.com>.
On Fri, Sep 10, 2010 at 1:35 AM, Deng Ching <oc...@apache.org> wrote:
> Sorry, I didn't notice this one. I'll review the branch this weekend
> and will send a separate thread for merging it to trunk :) Once it's
> been merged, I propose that we kick-off a milestone release.

Should we do a release before the merge?  I think trunk already has
some significant changes, but I'm also not sure how big this change
(staging) is.

I built the MRM-980 branch and tried it out.  My first impression is
that it wandered well away from the feature described in the issue.
All I wanted was to be able to merge two existing repositories!  I
think that's in there somewhere though. :)  Still, the JIRA issue
should be edited to describe what got implemented so the release notes
are clear.

I tried a couple of simple merges and it works fine, including warning
about conflicts (duplicates.)

A few things I jotted down:

I couldn't find a link to the docs on the staging feature, though a
text search did turn up adminguide/staging-repositories.html .

I tried adding a staging repository to the default "internal"
repository, and it did not work.  Editing "internal" again shows the
box is checked, but it will not display the location of the repo or
show the 'Merge' button after saving.  However, I noticed that
internal-stage was in the list when I went to upload an artifact.  The
docs say, "The snapshots and internal repositories configured in
Archiva by default, are not configured with attached staging
repositories." which I take to mean the staging repo is not there by
default but it _should_ be possible to add one.

Logging during the merge only shows the artifact filename.  (Needs to
include the groupId to uniquely identify the artifact.)

Overall I think the underlying merge feature is solid, (thanks Eshan!)
but the UI feels a bit rough.  For example, un-checking a box to
delete the staging repo is not intuitive, nor does it give you a
chance to confirm this destructive action.  And the warning about not
merging snapshots should probably only be displayed if there *are*
snapshots in the staging repo that won't be merged, otherwise it just
scares people unnecessarily.

I'm going to update the docs on the branch based on my user
experience.  I'll ping the list for a review so someone can flag
differences between what I say it does and what was intended. :)

Thanks,
-- 
Wendy