You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Aristedes Maniatis <ar...@ish.com.au> on 2008/11/08 01:32:49 UTC
Jira changes
If I go through and reassign Jira tasks to various milestones, it will
allow us to generate release notes from Jira and get a clearer
picture of what is planned for each release. But it seems that it also
generates lots of emails to the dev list.
1. Should we point Jira emails to the svn list instead just like
Confluence emails? I think that is better since it doesn't create so
much noise. I don't want to discourage potential contributors from
subscribing to this list. If so, I can't see where this setting lives
in Jira.
2. I've changed the default assignee from Andrus to 'unassigned' for
new tasks. Any objections? That might make it clearer what is being
worked on.
3. I'll go through and assign all the M5 tasks which have been done
and the ones I know are being worked on. If I feel like a mind-numbing
task one night I'll do a few more earlier milestones as well. Any
objections to this approach?
Regards
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Jira changes
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 8, 2008, at 2:26 PM, Aristedes Maniatis wrote:
> So we get something like this:
>
> https://issues.apache.org/cayenne/secure/ReleaseNote.jspa?projectId=10000&styleName=Html&version=10120
>
> We'll convert our release notes file to html I guess. We can even
> try again to do that thing with embedding Jira blocks inside
> Confluence although last time we tried that had some problems with
> the export plugin we use at Apache.
In fact a plain-text version is easily accessible over the same URL -
just copy/paste the top part of the page.
Also as a practical matter, please continue to update RELEASE-
NOTES.txt file for M5 for any new Jiras you might close, so that we
get a full picture (currently only 3 issues are showing as M5 in Jira,
while the release notes file is much longer).
Andrus
Re: CAY-1077
Posted by Kevin Menard <ni...@gmail.com>.
Andrey,
Thanks for spearheading this. I'll try out the new UI this evening
and give my opinion.
--
Kevin
On Wed, Nov 12, 2008 at 3:29 AM, Andrey Razumovsky
<ra...@gmail.com> wrote:
> I commited the new dialog. Please spend some time trying it out and tell me
> if you like it. Comments about its way of work is in JIRA
>
> 2008/11/9, Andrus Adamchik <an...@objectstyle.org>:
>>
>>
>> On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
>>
>> Fine, but as af as I remember, "Target" should be combobox because 1) There
>>> can be more than one ObjEntity for DbEntity
>>>
>>
>> Good point. Then I guess we need to limit combo choices only to those
>> entities that apply for a given path.
>>
>> 2) User can add new Db Rels in
>>> this dialog by clicking "New to-X relationship" (and target will be what
>>> was
>>> selected in combobox)
>>>
>>
>> I suggest we stop using the combo for targeting (except for the special
>> case above). This creates UI redundancy that can potentially be confusing.
>> So maybe we add a "target" combo to the DbRelationship mapping dialog
>> instead? (Maybe only shown when the dialog is opened from ObjRelationship
>> dialog; and hidden otherwise)?
>>
>> Andrus
>>
>>
>
Re: CAY-1077
Posted by Kevin Menard <ni...@gmail.com>.
I'm not against it the suggested change, other than I don't want to
introduce UI confusion. My feeling was that if someone wanted to go
above and beyond, he can modify the XML file directly.
--
Kevin
On Tue, Nov 18, 2008 at 9:21 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> While in reality flattened relationships would never span more than 2 db
> relationships, and loops like that are most likely be limited to something
> like many-to-many, there is no hard rules on what is allowed and what is
> not. So I'd like modeler to encourage best practices, but without limiting
> the possibilities for some crazy people :-)
>
> So maybe instead of "hard culling" we can do a "soft" version. E.g. grey out
> relationships in the browser that are more than 2 steps away from root or
> those that result in a to-one loop?
>
> Andrus
>
>
> On Nov 18, 2008, at 4:14 PM, Kevin Menard wrote:
>>
>> While Cayenne will traverse that path, it's unnecessary. I think
>> allowing such mapping introduces more confusion than anything else and
>> such mapped relationships are normally an error than anything else.
>> As such, I proposed not allowing the relationship path dialog to grow
>> unbounded with such loops.
>>
>> NB: this does not affect the general case of relationship mapping.
>>
>> --
>> Kevin
>>
>>
>>
>> On Tue, Nov 18, 2008 at 9:02 AM, Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>>
>>> Hmm... not that I ever mapped a flattened relationship like that myself,
>>> but
>>> technically this is totally valid:
>>>
>>> ObjRelationship: Painting.peerPaintings
>>>
>>> mapped as
>>>
>>> DbRelationship Path: PAINTING.toArtist.paintings
>>>
>>> Andrus
>>>
>>>
>>> On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
>>>
>>>> A -> B -> A is culled (B -> A will not be shown) when relationships are
>>>> reverse to each other & A -> B is to-one (e.g. paintings -> Artist ->
>>>> paintings)
>>>>
>>>> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>>>>
>>>>>
>>>>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>>>>
>>>>> I only was able to play with culling briefly, but it
>>>>>>
>>>>>> looks to be cutting down my choices considerably, which is good.
>>>>>>
>>>>>
>>>>> BTW, what's this about? Looks like I missed something.
>>>>>
>>>>> Andrus
>>>>>
>>>>>
>>>
>>>
>>
>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
While in reality flattened relationships would never span more than 2
db relationships, and loops like that are most likely be limited to
something like many-to-many, there is no hard rules on what is allowed
and what is not. So I'd like modeler to encourage best practices, but
without limiting the possibilities for some crazy people :-)
So maybe instead of "hard culling" we can do a "soft" version. E.g.
grey out relationships in the browser that are more than 2 steps away
from root or those that result in a to-one loop?
Andrus
On Nov 18, 2008, at 4:14 PM, Kevin Menard wrote:
> While Cayenne will traverse that path, it's unnecessary. I think
> allowing such mapping introduces more confusion than anything else and
> such mapped relationships are normally an error than anything else.
> As such, I proposed not allowing the relationship path dialog to grow
> unbounded with such loops.
>
> NB: this does not affect the general case of relationship mapping.
>
> --
> Kevin
>
>
>
> On Tue, Nov 18, 2008 at 9:02 AM, Andrus Adamchik <andrus@objectstyle.org
> > wrote:
>> Hmm... not that I ever mapped a flattened relationship like that
>> myself, but
>> technically this is totally valid:
>>
>> ObjRelationship: Painting.peerPaintings
>>
>> mapped as
>>
>> DbRelationship Path: PAINTING.toArtist.paintings
>>
>> Andrus
>>
>>
>> On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
>>
>>> A -> B -> A is culled (B -> A will not be shown) when
>>> relationships are
>>> reverse to each other & A -> B is to-one (e.g. paintings -> Artist
>>> ->
>>> paintings)
>>>
>>> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>>>
>>>>
>>>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>>>
>>>> I only was able to play with culling briefly, but it
>>>>>
>>>>> looks to be cutting down my choices considerably, which is good.
>>>>>
>>>>
>>>> BTW, what's this about? Looks like I missed something.
>>>>
>>>> Andrus
>>>>
>>>>
>>
>>
>
Re: CAY-1077
Posted by Kevin Menard <ni...@gmail.com>.
While Cayenne will traverse that path, it's unnecessary. I think
allowing such mapping introduces more confusion than anything else and
such mapped relationships are normally an error than anything else.
As such, I proposed not allowing the relationship path dialog to grow
unbounded with such loops.
NB: this does not affect the general case of relationship mapping.
--
Kevin
On Tue, Nov 18, 2008 at 9:02 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Hmm... not that I ever mapped a flattened relationship like that myself, but
> technically this is totally valid:
>
> ObjRelationship: Painting.peerPaintings
>
> mapped as
>
> DbRelationship Path: PAINTING.toArtist.paintings
>
> Andrus
>
>
> On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
>
>> A -> B -> A is culled (B -> A will not be shown) when relationships are
>> reverse to each other & A -> B is to-one (e.g. paintings -> Artist ->
>> paintings)
>>
>> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>>
>>>
>>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>>
>>> I only was able to play with culling briefly, but it
>>>>
>>>> looks to be cutting down my choices considerably, which is good.
>>>>
>>>
>>> BTW, what's this about? Looks like I missed something.
>>>
>>> Andrus
>>>
>>>
>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
Cool. If that's what culling is currently about, then I am +1.
So please treat the email that I sent on greying things out as an
optional nice-to-have feature suggestion for the future releases.
Andrus
On Nov 18, 2008, at 4:13 PM, Andrey Razumovsky wrote:
> You're right, B->A must be to-one, not A->B.
>
> ARTIST.paintings.artist is the same object.
>
> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>
>> Hmm... not that I ever mapped a flattened relationship like that
>> myself,
>> but technically this is totally valid:
>>
>> ObjRelationship: Painting.peerPaintings
>>
>> mapped as
>>
>> DbRelationship Path: PAINTING.toArtist.paintings
>>
>> Andrus
>>
>>
>> On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
>>
>> A -> B -> A is culled (B -> A will not be shown) when relationships
>> are
>>> reverse to each other & A -> B is to-one (e.g. paintings -> Artist
>>> ->
>>> paintings)
>>>
>>> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>>
>>>>
>>>>
>>>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>>>
>>>> I only was able to play with culling briefly, but it
>>>>
>>>>> looks to be cutting down my choices considerably, which is good.
>>>>>
>>>>>
>>>> BTW, what's this about? Looks like I missed something.
>>>>
>>>> Andrus
>>>>
>>>>
>>>>
>>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
You're right, B->A must be to-one, not A->B.
ARTIST.paintings.artist is the same object.
2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>
> Hmm... not that I ever mapped a flattened relationship like that myself,
> but technically this is totally valid:
>
> ObjRelationship: Painting.peerPaintings
>
> mapped as
>
> DbRelationship Path: PAINTING.toArtist.paintings
>
> Andrus
>
>
> On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
>
> A -> B -> A is culled (B -> A will not be shown) when relationships are
>> reverse to each other & A -> B is to-one (e.g. paintings -> Artist ->
>> paintings)
>>
>> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>
>>>
>>>
>>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>>
>>> I only was able to play with culling briefly, but it
>>>
>>>> looks to be cutting down my choices considerably, which is good.
>>>>
>>>>
>>> BTW, what's this about? Looks like I missed something.
>>>
>>> Andrus
>>>
>>>
>>>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hmm... not that I ever mapped a flattened relationship like that
myself, but technically this is totally valid:
ObjRelationship: Painting.peerPaintings
mapped as
DbRelationship Path: PAINTING.toArtist.paintings
Andrus
On Nov 18, 2008, at 3:49 PM, Andrey Razumovsky wrote:
> A -> B -> A is culled (B -> A will not be shown) when relationships
> are
> reverse to each other & A -> B is to-one (e.g. paintings -> Artist ->
> paintings)
>
> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>
>>
>> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>>
>> I only was able to play with culling briefly, but it
>>> looks to be cutting down my choices considerably, which is good.
>>>
>>
>> BTW, what's this about? Looks like I missed something.
>>
>> Andrus
>>
>>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
A -> B -> A is culled (B -> A will not be shown) when relationships are
reverse to each other & A -> B is to-one (e.g. paintings -> Artist ->
paintings)
2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>
>
> On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
>
> I only was able to play with culling briefly, but it
>> looks to be cutting down my choices considerably, which is good.
>>
>
> BTW, what's this about? Looks like I missed something.
>
> Andrus
>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 18, 2008, at 3:33 PM, Kevin Menard wrote:
> I only was able to play with culling briefly, but it
> looks to be cutting down my choices considerably, which is good.
BTW, what's this about? Looks like I missed something.
Andrus
Re: CAY-1077
Posted by Kevin Menard <ni...@gmail.com>.
Looks good. I only was able to play with culling briefly, but it
looks to be cutting down my choices considerably, which is good.
I'd say get it out there and let our users play with it. Invariably,
they will find something we missed.
--
Kevin
On Tue, Nov 18, 2008 at 3:58 AM, Andrey Razumovsky
<ra...@gmail.com> wrote:
> Great. Kevin, do you have something to add (I've done culling BTW).
> Otherwise I'll close the issue.
>
> 2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>>
>> Very nice.
>>
>> I guess there are still ways to arrange things a little different here and
>> there, but now the functionality is straightforward and there is little room
>> for confusion.
>>
>> One minor note - let's change "Done" button in the "New DbRelationship"
>> dialog to "Continue". Otherwise I think this is finished.
>>
>> Andrus
>>
>>
>> On Nov 17, 2008, at 7:47 PM, Andrey Razumovsky wrote:
>>
>> I've committed the dialog. Please have a look, and let's get over with it
>>>
>>> 2008/11/14, Kevin Menard <ni...@gmail.com>:
>>>
>>>>
>>>> Comments are in-line.
>>>>
>>>>
>>>> On Wed, Nov 12, 2008 at 4:38 AM, Andrus Adamchik <andrus@objectstyle.org
>>>> >
>>>> wrote:
>>>>
>>>>> Cool. I very much like the direction. Here is a few notes on the
>>>>> implementation:
>>>>>
>>>>> 1. I think "revert" and "clear" are redundant. They don't revert
>>>>> previous
>>>>> "save", but simply go back in the browser. It is just as easy to use the
>>>>> browser to achieve that. So I suggest we remove those buttons.
>>>>>
>>>>
>>>>
>>>> Are you seeing something different than me? If I modify an existing
>>>> relationship, revert takes me back to that mapped relationship. Clear
>>>> removes all selection.
>>>>
>>>>
>>>> 2. "Save Path" should probably be called "Select", as we are not really
>>>>> saving anything until "Done" is clicked. Also since we only have 1
>>>>> button
>>>>> now, maybe to make things more compact and consistent with other similar
>>>>> interfaces, implement it as a toolbar on top of the browser (see Select
>>>>> Query Ordering tab for an example).
>>>>>
>>>>
>>>>
>>>> +1.
>>>>
>>>>
>>>> 3. DbRelationships. There's a bit of a problem figuring context of the
>>>>>
>>>> new
>>>>
>>>>> relationship. It correctly uses a target of the currently selected
>>>>> DbRelationship path as its source, however its location is disjoint from
>>>>>
>>>> the
>>>>
>>>>> browser so it is not immediately clear. It also clutters the view a bit.
>>>>>
>>>> So
>>>>
>>>>> maybe we can add an extra dialog started with a "new relationship"
>>>>> button
>>>>> icon on the browser toolbar (see #2 - we will have a toolbar), that
>>>>>
>>>> allows
>>>>
>>>>> you to select target entity, cardinality (to-one, to-many) and continue
>>>>>
>>>> to
>>>>
>>>>> the joins mapping?
>>>>>
>>>>
>>>>
>>>> +1. The UI is a bit overloaded at the moment. Another option may be
>>>> to implement the dialog as a frame with tab panes.
>>>>
>>>> I'm still not a super huge fan of the constant expansion, but I think
>>>> the improvements made are making it less of an issue.
>>>>
>>>> I'd also like to see a bit more culling. Right now 1-1 are culled.
>>>> We could also cull 1 - m, m - 1, since the 1 is the same in each case.
>>>> I think that would cut down on confusion a bit more.
>>>>
>>>> --
>>>>
>>>> Kevin
>>>>
>>>>
>>
>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
Great. Kevin, do you have something to add (I've done culling BTW).
Otherwise I'll close the issue.
2008/11/18, Andrus Adamchik <an...@objectstyle.org>:
>
> Very nice.
>
> I guess there are still ways to arrange things a little different here and
> there, but now the functionality is straightforward and there is little room
> for confusion.
>
> One minor note - let's change "Done" button in the "New DbRelationship"
> dialog to "Continue". Otherwise I think this is finished.
>
> Andrus
>
>
> On Nov 17, 2008, at 7:47 PM, Andrey Razumovsky wrote:
>
> I've committed the dialog. Please have a look, and let's get over with it
>>
>> 2008/11/14, Kevin Menard <ni...@gmail.com>:
>>
>>>
>>> Comments are in-line.
>>>
>>>
>>> On Wed, Nov 12, 2008 at 4:38 AM, Andrus Adamchik <andrus@objectstyle.org
>>> >
>>> wrote:
>>>
>>>> Cool. I very much like the direction. Here is a few notes on the
>>>> implementation:
>>>>
>>>> 1. I think "revert" and "clear" are redundant. They don't revert
>>>> previous
>>>> "save", but simply go back in the browser. It is just as easy to use the
>>>> browser to achieve that. So I suggest we remove those buttons.
>>>>
>>>
>>>
>>> Are you seeing something different than me? If I modify an existing
>>> relationship, revert takes me back to that mapped relationship. Clear
>>> removes all selection.
>>>
>>>
>>> 2. "Save Path" should probably be called "Select", as we are not really
>>>> saving anything until "Done" is clicked. Also since we only have 1
>>>> button
>>>> now, maybe to make things more compact and consistent with other similar
>>>> interfaces, implement it as a toolbar on top of the browser (see Select
>>>> Query Ordering tab for an example).
>>>>
>>>
>>>
>>> +1.
>>>
>>>
>>> 3. DbRelationships. There's a bit of a problem figuring context of the
>>>>
>>> new
>>>
>>>> relationship. It correctly uses a target of the currently selected
>>>> DbRelationship path as its source, however its location is disjoint from
>>>>
>>> the
>>>
>>>> browser so it is not immediately clear. It also clutters the view a bit.
>>>>
>>> So
>>>
>>>> maybe we can add an extra dialog started with a "new relationship"
>>>> button
>>>> icon on the browser toolbar (see #2 - we will have a toolbar), that
>>>>
>>> allows
>>>
>>>> you to select target entity, cardinality (to-one, to-many) and continue
>>>>
>>> to
>>>
>>>> the joins mapping?
>>>>
>>>
>>>
>>> +1. The UI is a bit overloaded at the moment. Another option may be
>>> to implement the dialog as a frame with tab panes.
>>>
>>> I'm still not a super huge fan of the constant expansion, but I think
>>> the improvements made are making it less of an issue.
>>>
>>> I'd also like to see a bit more culling. Right now 1-1 are culled.
>>> We could also cull 1 - m, m - 1, since the 1 is the same in each case.
>>> I think that would cut down on confusion a bit more.
>>>
>>> --
>>>
>>> Kevin
>>>
>>>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
Good point... Maybe we can make it a function of the dialog per item
#3... Essentially we take a selected DbRelationship and offer user a
choice to make a new relationship either out of the source or the
target of that relationship, with radiobuttons:
Source: Artist <radio>
Source: Painting <radio>
Target: <Dropdown>
To Many: <checkbox>
Andrus
On Nov 12, 2008, at 11:56 AM, Andrey Razumovsky wrote:
> Well, I think at least we need 'Clear Path' button. Otherwise I
> won't be
> able to create new DbRelationship from ObjRelationship source (i.e.
> insert
> new relationship in first column).
>
> 2008/11/12, Andrus Adamchik <an...@objectstyle.org>:
>>
>> Cool. I very much like the direction. Here is a few notes on the
>> implementation:
>>
>> 1. I think "revert" and "clear" are redundant. They don't revert
>> previous
>> "save", but simply go back in the browser. It is just as easy to
>> use the
>> browser to achieve that. So I suggest we remove those buttons.
>>
>> 2. "Save Path" should probably be called "Select", as we are not
>> really
>> saving anything until "Done" is clicked. Also since we only have 1
>> button
>> now, maybe to make things more compact and consistent with other
>> similar
>> interfaces, implement it as a toolbar on top of the browser (see
>> Select
>> Query Ordering tab for an example).
>>
>> 3. DbRelationships. There's a bit of a problem figuring context of
>> the new
>> relationship. It correctly uses a target of the currently selected
>> DbRelationship path as its source, however its location is disjoint
>> from the
>> browser so it is not immediately clear. It also clutters the view a
>> bit. So
>> maybe we can add an extra dialog started with a "new relationship"
>> button
>> icon on the browser toolbar (see #2 - we will have a toolbar), that
>> allows
>> you to select target entity, cardinality (to-one, to-many) and
>> continue to
>> the joins mapping?
>>
>> Thanks,
>> Andrus
>>
>>
>> On Nov 12, 2008, at 10:29 AM, Andrey Razumovsky wrote:
>>
>> I commited the new dialog. Please spend some time trying it out and
>> tell me
>>> if you like it. Comments about its way of work is in JIRA
>>>
>>> 2008/11/9, Andrus Adamchik <an...@objectstyle.org>:
>>>
>>>>
>>>>
>>>> On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
>>>>
>>>> Fine, but as af as I remember, "Target" should be combobox
>>>> because 1)
>>>> There
>>>>
>>>>> can be more than one ObjEntity for DbEntity
>>>>>
>>>>>
>>>> Good point. Then I guess we need to limit combo choices only to
>>>> those
>>>> entities that apply for a given path.
>>>>
>>>> 2) User can add new Db Rels in
>>>>
>>>>> this dialog by clicking "New to-X relationship" (and target will
>>>>> be what
>>>>> was
>>>>> selected in combobox)
>>>>>
>>>>>
>>>> I suggest we stop using the combo for targeting (except for the
>>>> special
>>>> case above). This creates UI redundancy that can potentially be
>>>> confusing.
>>>> So maybe we add a "target" combo to the DbRelationship mapping
>>>> dialog
>>>> instead? (Maybe only shown when the dialog is opened from
>>>> ObjRelationship
>>>> dialog; and hidden otherwise)?
>>>>
>>>> Andrus
>>>>
>>>>
>>>>
>>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
Well, I think at least we need 'Clear Path' button. Otherwise I won't be
able to create new DbRelationship from ObjRelationship source (i.e. insert
new relationship in first column).
2008/11/12, Andrus Adamchik <an...@objectstyle.org>:
>
> Cool. I very much like the direction. Here is a few notes on the
> implementation:
>
> 1. I think "revert" and "clear" are redundant. They don't revert previous
> "save", but simply go back in the browser. It is just as easy to use the
> browser to achieve that. So I suggest we remove those buttons.
>
> 2. "Save Path" should probably be called "Select", as we are not really
> saving anything until "Done" is clicked. Also since we only have 1 button
> now, maybe to make things more compact and consistent with other similar
> interfaces, implement it as a toolbar on top of the browser (see Select
> Query Ordering tab for an example).
>
> 3. DbRelationships. There's a bit of a problem figuring context of the new
> relationship. It correctly uses a target of the currently selected
> DbRelationship path as its source, however its location is disjoint from the
> browser so it is not immediately clear. It also clutters the view a bit. So
> maybe we can add an extra dialog started with a "new relationship" button
> icon on the browser toolbar (see #2 - we will have a toolbar), that allows
> you to select target entity, cardinality (to-one, to-many) and continue to
> the joins mapping?
>
> Thanks,
> Andrus
>
>
> On Nov 12, 2008, at 10:29 AM, Andrey Razumovsky wrote:
>
> I commited the new dialog. Please spend some time trying it out and tell me
>> if you like it. Comments about its way of work is in JIRA
>>
>> 2008/11/9, Andrus Adamchik <an...@objectstyle.org>:
>>
>>>
>>>
>>> On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
>>>
>>> Fine, but as af as I remember, "Target" should be combobox because 1)
>>> There
>>>
>>>> can be more than one ObjEntity for DbEntity
>>>>
>>>>
>>> Good point. Then I guess we need to limit combo choices only to those
>>> entities that apply for a given path.
>>>
>>> 2) User can add new Db Rels in
>>>
>>>> this dialog by clicking "New to-X relationship" (and target will be what
>>>> was
>>>> selected in combobox)
>>>>
>>>>
>>> I suggest we stop using the combo for targeting (except for the special
>>> case above). This creates UI redundancy that can potentially be
>>> confusing.
>>> So maybe we add a "target" combo to the DbRelationship mapping dialog
>>> instead? (Maybe only shown when the dialog is opened from ObjRelationship
>>> dialog; and hidden otherwise)?
>>>
>>> Andrus
>>>
>>>
>>>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
Very nice.
I guess there are still ways to arrange things a little different here
and there, but now the functionality is straightforward and there is
little room for confusion.
One minor note - let's change "Done" button in the "New
DbRelationship" dialog to "Continue". Otherwise I think this is
finished.
Andrus
On Nov 17, 2008, at 7:47 PM, Andrey Razumovsky wrote:
> I've committed the dialog. Please have a look, and let's get over
> with it
>
> 2008/11/14, Kevin Menard <ni...@gmail.com>:
>>
>> Comments are in-line.
>>
>>
>> On Wed, Nov 12, 2008 at 4:38 AM, Andrus Adamchik <andrus@objectstyle.org
>> >
>> wrote:
>>> Cool. I very much like the direction. Here is a few notes on the
>>> implementation:
>>>
>>> 1. I think "revert" and "clear" are redundant. They don't revert
>>> previous
>>> "save", but simply go back in the browser. It is just as easy to
>>> use the
>>> browser to achieve that. So I suggest we remove those buttons.
>>
>>
>> Are you seeing something different than me? If I modify an existing
>> relationship, revert takes me back to that mapped relationship.
>> Clear
>> removes all selection.
>>
>>
>>> 2. "Save Path" should probably be called "Select", as we are not
>>> really
>>> saving anything until "Done" is clicked. Also since we only have 1
>>> button
>>> now, maybe to make things more compact and consistent with other
>>> similar
>>> interfaces, implement it as a toolbar on top of the browser (see
>>> Select
>>> Query Ordering tab for an example).
>>
>>
>> +1.
>>
>>
>>> 3. DbRelationships. There's a bit of a problem figuring context of
>>> the
>> new
>>> relationship. It correctly uses a target of the currently selected
>>> DbRelationship path as its source, however its location is
>>> disjoint from
>> the
>>> browser so it is not immediately clear. It also clutters the view
>>> a bit.
>> So
>>> maybe we can add an extra dialog started with a "new relationship"
>>> button
>>> icon on the browser toolbar (see #2 - we will have a toolbar), that
>> allows
>>> you to select target entity, cardinality (to-one, to-many) and
>>> continue
>> to
>>> the joins mapping?
>>
>>
>> +1. The UI is a bit overloaded at the moment. Another option may be
>> to implement the dialog as a frame with tab panes.
>>
>> I'm still not a super huge fan of the constant expansion, but I think
>> the improvements made are making it less of an issue.
>>
>> I'd also like to see a bit more culling. Right now 1-1 are culled.
>> We could also cull 1 - m, m - 1, since the 1 is the same in each
>> case.
>> I think that would cut down on confusion a bit more.
>>
>> --
>>
>> Kevin
>>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
I've committed the dialog. Please have a look, and let's get over with it
2008/11/14, Kevin Menard <ni...@gmail.com>:
>
> Comments are in-line.
>
>
> On Wed, Nov 12, 2008 at 4:38 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
> > Cool. I very much like the direction. Here is a few notes on the
> > implementation:
> >
> > 1. I think "revert" and "clear" are redundant. They don't revert previous
> > "save", but simply go back in the browser. It is just as easy to use the
> > browser to achieve that. So I suggest we remove those buttons.
>
>
> Are you seeing something different than me? If I modify an existing
> relationship, revert takes me back to that mapped relationship. Clear
> removes all selection.
>
>
> > 2. "Save Path" should probably be called "Select", as we are not really
> > saving anything until "Done" is clicked. Also since we only have 1 button
> > now, maybe to make things more compact and consistent with other similar
> > interfaces, implement it as a toolbar on top of the browser (see Select
> > Query Ordering tab for an example).
>
>
> +1.
>
>
> > 3. DbRelationships. There's a bit of a problem figuring context of the
> new
> > relationship. It correctly uses a target of the currently selected
> > DbRelationship path as its source, however its location is disjoint from
> the
> > browser so it is not immediately clear. It also clutters the view a bit.
> So
> > maybe we can add an extra dialog started with a "new relationship" button
> > icon on the browser toolbar (see #2 - we will have a toolbar), that
> allows
> > you to select target entity, cardinality (to-one, to-many) and continue
> to
> > the joins mapping?
>
>
> +1. The UI is a bit overloaded at the moment. Another option may be
> to implement the dialog as a frame with tab panes.
>
> I'm still not a super huge fan of the constant expansion, but I think
> the improvements made are making it less of an issue.
>
> I'd also like to see a bit more culling. Right now 1-1 are culled.
> We could also cull 1 - m, m - 1, since the 1 is the same in each case.
> I think that would cut down on confusion a bit more.
>
> --
>
> Kevin
>
Re: CAY-1077
Posted by Kevin Menard <ni...@gmail.com>.
Comments are in-line.
On Wed, Nov 12, 2008 at 4:38 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Cool. I very much like the direction. Here is a few notes on the
> implementation:
>
> 1. I think "revert" and "clear" are redundant. They don't revert previous
> "save", but simply go back in the browser. It is just as easy to use the
> browser to achieve that. So I suggest we remove those buttons.
Are you seeing something different than me? If I modify an existing
relationship, revert takes me back to that mapped relationship. Clear
removes all selection.
> 2. "Save Path" should probably be called "Select", as we are not really
> saving anything until "Done" is clicked. Also since we only have 1 button
> now, maybe to make things more compact and consistent with other similar
> interfaces, implement it as a toolbar on top of the browser (see Select
> Query Ordering tab for an example).
+1.
> 3. DbRelationships. There's a bit of a problem figuring context of the new
> relationship. It correctly uses a target of the currently selected
> DbRelationship path as its source, however its location is disjoint from the
> browser so it is not immediately clear. It also clutters the view a bit. So
> maybe we can add an extra dialog started with a "new relationship" button
> icon on the browser toolbar (see #2 - we will have a toolbar), that allows
> you to select target entity, cardinality (to-one, to-many) and continue to
> the joins mapping?
+1. The UI is a bit overloaded at the moment. Another option may be
to implement the dialog as a frame with tab panes.
I'm still not a super huge fan of the constant expansion, but I think
the improvements made are making it less of an issue.
I'd also like to see a bit more culling. Right now 1-1 are culled.
We could also cull 1 - m, m - 1, since the 1 is the same in each case.
I think that would cut down on confusion a bit more.
--
Kevin
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
Cool. I very much like the direction. Here is a few notes on the
implementation:
1. I think "revert" and "clear" are redundant. They don't revert
previous "save", but simply go back in the browser. It is just as easy
to use the browser to achieve that. So I suggest we remove those
buttons.
2. "Save Path" should probably be called "Select", as we are not
really saving anything until "Done" is clicked. Also since we only
have 1 button now, maybe to make things more compact and consistent
with other similar interfaces, implement it as a toolbar on top of the
browser (see Select Query Ordering tab for an example).
3. DbRelationships. There's a bit of a problem figuring context of the
new relationship. It correctly uses a target of the currently selected
DbRelationship path as its source, however its location is disjoint
from the browser so it is not immediately clear. It also clutters the
view a bit. So maybe we can add an extra dialog started with a "new
relationship" button icon on the browser toolbar (see #2 - we will
have a toolbar), that allows you to select target entity, cardinality
(to-one, to-many) and continue to the joins mapping?
Thanks,
Andrus
On Nov 12, 2008, at 10:29 AM, Andrey Razumovsky wrote:
> I commited the new dialog. Please spend some time trying it out and
> tell me
> if you like it. Comments about its way of work is in JIRA
>
> 2008/11/9, Andrus Adamchik <an...@objectstyle.org>:
>>
>>
>> On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
>>
>> Fine, but as af as I remember, "Target" should be combobox because
>> 1) There
>>> can be more than one ObjEntity for DbEntity
>>>
>>
>> Good point. Then I guess we need to limit combo choices only to those
>> entities that apply for a given path.
>>
>> 2) User can add new Db Rels in
>>> this dialog by clicking "New to-X relationship" (and target will
>>> be what
>>> was
>>> selected in combobox)
>>>
>>
>> I suggest we stop using the combo for targeting (except for the
>> special
>> case above). This creates UI redundancy that can potentially be
>> confusing.
>> So maybe we add a "target" combo to the DbRelationship mapping dialog
>> instead? (Maybe only shown when the dialog is opened from
>> ObjRelationship
>> dialog; and hidden otherwise)?
>>
>> Andrus
>>
>>
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
I commited the new dialog. Please spend some time trying it out and tell me
if you like it. Comments about its way of work is in JIRA
2008/11/9, Andrus Adamchik <an...@objectstyle.org>:
>
>
> On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
>
> Fine, but as af as I remember, "Target" should be combobox because 1) There
>> can be more than one ObjEntity for DbEntity
>>
>
> Good point. Then I guess we need to limit combo choices only to those
> entities that apply for a given path.
>
> 2) User can add new Db Rels in
>> this dialog by clicking "New to-X relationship" (and target will be what
>> was
>> selected in combobox)
>>
>
> I suggest we stop using the combo for targeting (except for the special
> case above). This creates UI redundancy that can potentially be confusing.
> So maybe we add a "target" combo to the DbRelationship mapping dialog
> instead? (Maybe only shown when the dialog is opened from ObjRelationship
> dialog; and hidden otherwise)?
>
> Andrus
>
>
Re: CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 9, 2008, at 12:15 PM, Andrey Razumovsky wrote:
> Fine, but as af as I remember, "Target" should be combobox because
> 1) There
> can be more than one ObjEntity for DbEntity
Good point. Then I guess we need to limit combo choices only to those
entities that apply for a given path.
> 2) User can add new Db Rels in
> this dialog by clicking "New to-X relationship" (and target will be
> what was
> selected in combobox)
I suggest we stop using the combo for targeting (except for the
special case above). This creates UI redundancy that can potentially
be confusing. So maybe we add a "target" combo to the DbRelationship
mapping dialog instead? (Maybe only shown when the dialog is opened
from ObjRelationship dialog; and hidden otherwise)?
Andrus
Re: CAY-1077
Posted by Andrey Razumovsky <ra...@gmail.com>.
Fine, but as af as I remember, "Target" should be combobox because 1) There
can be more than one ObjEntity for DbEntity 2) User can add new Db Rels in
this dialog by clicking "New to-X relationship" (and target will be what was
selected in combobox)
2008/11/8, Andrus Adamchik <an...@objectstyle.org>:
>
>
> On Nov 8, 2008, at 8:52 PM, Andrey Razumovsky wrote:
>
> About M5, I'm still not sure what should we do with CAY-1077. Switching
>> between single and double click is a minute work and I'd prefer we close
>> it
>> and release M5 as fast as possible.
>>
>
> Sorry, I kept postponing replying to this. Let me give it a shot now... I
> stand by my earlier assessment - the browser has to expand on a single
> click... looking at the comment in Jira by Kevin, "the behavior of the
> column selector should be the same for the relationship dialog and the
> prefetch dialog.", I think I am totally in favor of following this approach.
> Here is what it means IMO:
>
> 1. The browser should expand on single click
> 2. "Target" should be a text label, not a dropdown.
>
> 3. (??) How do we allow a user to navigate through relationships without
> dirtying the selection... It is probably evil to make a single click
> selection as it is unclear to the users that they've just changed something,
> when they simply wanted to browse around, so let's make selection a separate
> step following prefetch/ordering selection process for queries. So let's add
> a "select path" button, similar to "Add Ordering" button for select queries
> (there won't be a "remove" I guess, as we are only selecting 1 path). Maybe
> we can also improve on the browser - a relationship target entity can be
> shown as a column header of the browser panel on the right of the
> relationship.
>
> Does this sound reasonable?
>
> Andrus
>
>
>
CAY-1077
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 8, 2008, at 8:52 PM, Andrey Razumovsky wrote:
> About M5, I'm still not sure what should we do with CAY-1077.
> Switching
> between single and double click is a minute work and I'd prefer we
> close it
> and release M5 as fast as possible.
Sorry, I kept postponing replying to this. Let me give it a shot
now... I stand by my earlier assessment - the browser has to expand on
a single click... looking at the comment in Jira by Kevin, "the
behavior of the column selector should be the same for the
relationship dialog and the prefetch dialog.", I think I am totally in
favor of following this approach. Here is what it means IMO:
1. The browser should expand on single click
2. "Target" should be a text label, not a dropdown.
3. (??) How do we allow a user to navigate through relationships
without dirtying the selection... It is probably evil to make a single
click selection as it is unclear to the users that they've just
changed something, when they simply wanted to browse around, so let's
make selection a separate step following prefetch/ordering selection
process for queries. So let's add a "select path" button, similar to
"Add Ordering" button for select queries (there won't be a "remove" I
guess, as we are only selecting 1 path). Maybe we can also improve on
the browser - a relationship target entity can be shown as a column
header of the browser panel on the right of the relationship.
Does this sound reasonable?
Andrus
Re: Jira changes
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 9, 2008, at 12:21 AM, Aristedes Maniatis wrote:
> And also CAYDOC12 and CAYDOC20 for the older documentation (which
> are largely abandoned). For the future I'm in favour of putting
> inline notes in the docs to state: 'this feature available from 4.0'
> rather than trying to maintain a 3.0 branch.
Inline notes on when a given feature got introduced are fine, still
they do not solve the problem we are trying to solve with doc branches
- giving end users a precise view of the documentation matching an SVN
code branch, and giving developers the freedom to change and rearrange
the docs on "trunk" (i.e. CAYDOC).
So as long as we support a release and feature docs for such release
on a web site, we need a Confluence docs branch for it. Otherwise
things will become a mess quickly.
One example of mixing releases in a single document gone wrong was
MySQL 3-4 years ago. They got away from it now in favor of per major
version docs.
Andrus
Re: Jira changes
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 09/11/2008, at 6:13 AM, Andrus Adamchik wrote:
> 2. Confluence. I also added you to the Confluence "cayenne-users"
> and "cayenne-admins" groups. You may have noticed that we have a few
> Confluence spaces for different purposes, most notably:
>
> CAY - a wiki
> CAYDOC - a documentation exported to SVN and bundled with the release
> CAYSITE - a CMS replacement for the live site editing.
And also CAYDOC12 and CAYDOC20 for the older documentation (which are
largely abandoned). For the future I'm in favour of putting inline
notes in the docs to state: 'this feature available from 4.0' rather
than trying to maintain a 3.0 branch.
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Jira changes
Posted by Andrus Adamchik <an...@objectstyle.org>.
Ok, after some back and force with the infra team, it turns out that
all commits@ lists only accept mail from apache.org, but not the
Apache subdomains. So dev@cayenne.a.o as a From address resulted in
message being dev'nulled. Infra wasn't receptive to the idea of
allowing subdomains, so I changed the from address to the standard jira@a.o
. Now the messages are going through. Since "Reply-To" is set to "dev@cayenne.a.o
", you can still hit reply and redirect discussion to the dev list.
The only caveat is that authors and assignees of the issues will
receive two copies of each message, and only the one received via
commits@ list will have the correct Reply-To.
Anyways, it "works".
Andrus
On Nov 12, 2008, at 9:57 PM, Andrus Adamchik wrote:
> Hmm... wonder if it is still broken. I am receiving emails from Jira
> on the tasks that I am either a reporter or an assignee (so this is
> sent directly to my email). Don't see any commits@ list emails either.
>
> Let me check with the infrastructure. Commits lists are setup
> differently from other lists, so they may be filtering bulk emails
> or something.
>
> Andrus
>
>
> On Nov 12, 2008, at 9:35 PM, Andrey Razumovsky wrote:
>
>> Seems I stopped getting emails from JIRA. What list do I need to
>> subscribe
>> to?
>>
>> 2008/11/10, Andrus Adamchik <an...@objectstyle.org>:
>>>
>>> Fixed.
>>>
>>>
>>> On Nov 10, 2008, at 10:21 AM, Andrus Adamchik wrote:
>>>
>>> Maybe that's a good outcome after all :-)
>>>>
>>>> Anyways, I suspect the moderation is not set for the commit list,
>>>> and
>>>> messages from non-subscriber get bounced. Let me investigate how
>>>> the
>>>> moderation is setup.
>>>>
>>>> Andrus
>>>>
>>>> On Nov 10, 2008, at 10:16 AM, Aristedes Maniatis wrote:
>>>>
>>>>>
>>>>> On 09/11/2008, at 6:13 AM, Andrus Adamchik wrote:
>>>>>
>>>>> 3. Jira notifications. I just redirected all of them to commits@c.a.o
>>>>>>
>>>>>
>>>>> Doesn't seem to be working. There should have been, oh, about
>>>>> 1200 emails
>>>>> to that list over the weekend.
>>>>>
>>>>> Ari
>>>>>
>>>>>
>>>>> -------------------------->
>>>>> ish
>>>>> http://www.ish.com.au
>>>>> Level 1, 30 Wilson Street Newtown 2042 Australia
>>>>> phone +61 2 9550 5001 fax +61 2 9550 4001
>>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
Re: Jira changes
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hmm... wonder if it is still broken. I am receiving emails from Jira
on the tasks that I am either a reporter or an assignee (so this is
sent directly to my email). Don't see any commits@ list emails either.
Let me check with the infrastructure. Commits lists are setup
differently from other lists, so they may be filtering bulk emails or
something.
Andrus
On Nov 12, 2008, at 9:35 PM, Andrey Razumovsky wrote:
> Seems I stopped getting emails from JIRA. What list do I need to
> subscribe
> to?
>
> 2008/11/10, Andrus Adamchik <an...@objectstyle.org>:
>>
>> Fixed.
>>
>>
>> On Nov 10, 2008, at 10:21 AM, Andrus Adamchik wrote:
>>
>> Maybe that's a good outcome after all :-)
>>>
>>> Anyways, I suspect the moderation is not set for the commit list,
>>> and
>>> messages from non-subscriber get bounced. Let me investigate how the
>>> moderation is setup.
>>>
>>> Andrus
>>>
>>> On Nov 10, 2008, at 10:16 AM, Aristedes Maniatis wrote:
>>>
>>>>
>>>> On 09/11/2008, at 6:13 AM, Andrus Adamchik wrote:
>>>>
>>>> 3. Jira notifications. I just redirected all of them to commits@c.a.o
>>>>>
>>>>
>>>> Doesn't seem to be working. There should have been, oh, about
>>>> 1200 emails
>>>> to that list over the weekend.
>>>>
>>>> Ari
>>>>
>>>>
>>>> -------------------------->
>>>> ish
>>>> http://www.ish.com.au
>>>> Level 1, 30 Wilson Street Newtown 2042 Australia
>>>> phone +61 2 9550 5001 fax +61 2 9550 4001
>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
Re: Jira changes
Posted by Andrey Razumovsky <ra...@gmail.com>.
Seems I stopped getting emails from JIRA. What list do I need to subscribe
to?
2008/11/10, Andrus Adamchik <an...@objectstyle.org>:
>
> Fixed.
>
>
> On Nov 10, 2008, at 10:21 AM, Andrus Adamchik wrote:
>
> Maybe that's a good outcome after all :-)
>>
>> Anyways, I suspect the moderation is not set for the commit list, and
>> messages from non-subscriber get bounced. Let me investigate how the
>> moderation is setup.
>>
>> Andrus
>>
>> On Nov 10, 2008, at 10:16 AM, Aristedes Maniatis wrote:
>>
>>>
>>> On 09/11/2008, at 6:13 AM, Andrus Adamchik wrote:
>>>
>>> 3. Jira notifications. I just redirected all of them to commits@c.a.o
>>>>
>>>
>>> Doesn't seem to be working. There should have been, oh, about 1200 emails
>>> to that list over the weekend.
>>>
>>> Ari
>>>
>>>
>>> -------------------------->
>>> ish
>>> http://www.ish.com.au
>>> Level 1, 30 Wilson Street Newtown 2042 Australia
>>> phone +61 2 9550 5001 fax +61 2 9550 4001
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>
>>>
>>>
>>>
>>
>>
>
Re: Jira changes
Posted by Andrus Adamchik <an...@objectstyle.org>.
Fixed.
On Nov 10, 2008, at 10:21 AM, Andrus Adamchik wrote:
> Maybe that's a good outcome after all :-)
>
> Anyways, I suspect the moderation is not set for the commit list,
> and messages from non-subscriber get bounced. Let me investigate how
> the moderation is setup.
>
> Andrus
>
> On Nov 10, 2008, at 10:16 AM, Aristedes Maniatis wrote:
>>
>> On 09/11/2008, at 6:13 AM, Andrus Adamchik wrote:
>>
>>> 3. Jira notifications. I just redirected all of them to
>>> commits@c.a.o
>>
>> Doesn't seem to be working. There should have been, oh, about 1200
>> emails to that list over the weekend.
>>
>> Ari
>>
>>
>> -------------------------->
>> ish
>> http://www.ish.com.au
>> Level 1, 30 Wilson Street Newtown 2042 Australia
>> phone +61 2 9550 5001 fax +61 2 9550 4001
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>>
>>
>
>
Re: Jira changes
Posted by Andrus Adamchik <an...@objectstyle.org>.
Maybe that's a good outcome after all :-)
Anyways, I suspect the moderation is not set for the commit list, and
messages from non-subscriber get bounced. Let me investigate how the
moderation is setup.
Andrus
On Nov 10, 2008, at 10:16 AM, Aristedes Maniatis wrote:
>
> On 09/11/2008, at 6:13 AM, Andrus Adamchik wrote:
>
>> 3. Jira notifications. I just redirected all of them to commits@c.a.o
>
> Doesn't seem to be working. There should have been, oh, about 1200
> emails to that list over the weekend.
>
> Ari
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
Re: Jira changes
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 09/11/2008, at 6:13 AM, Andrus Adamchik wrote:
> 3. Jira notifications. I just redirected all of them to commits@c.a.o
Doesn't seem to be working. There should have been, oh, about 1200
emails to that list over the weekend.
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Jira changes
Posted by Andrus Adamchik <an...@objectstyle.org>.
1. Dead issues. Good catch. I closed CAY-1036 and CAY-708. Let me know
if you think some other issues are also obsolete.
2. Confluence. I also added you to the Confluence "cayenne-users" and
"cayenne-admins" groups. You may have noticed that we have a few
Confluence spaces for different purposes, most notably:
CAY - a wiki
CAYDOC - a documentation exported to SVN and bundled with the release
CAYSITE - a CMS replacement for the live site editing.
Both CAYDOC and CAYSITE are automatically rsynced with
cayenne.apache.org.
3. Jira notifications. I just redirected all of them to commits@c.a.o
Andrus
On Nov 8, 2008, at 8:52 PM, Andrey Razumovsky wrote:
> I've seen some obviously obsolete and dead issues in Jira, like
> CAY-1036 or
> CAY-708. It'll be great to clean out those issues and assign among
> us bunch
> of the most important opened ones.
> As of the versions, detail version number is great.
>
> About M5, I'm still not sure what should we do with CAY-1077.
> Switching
> between single and double click is a minute work and I'd prefer we
> close it
> and release M5 as fast as possible.
>
> About Confluence, could someone give me permission rights to edit
> pages?
> Username is "andrey".
>
> 2008/11/8, Aristedes Maniatis <ar...@ish.com.au>:
>>
>>
>> On 08/11/2008, at 11:08 PM, Andrus Adamchik wrote:
>>
>> On Nov 8, 2008, at 2:32 AM, Aristedes Maniatis wrote:
>>>
>>> 1. Should we point Jira emails to the svn list instead just like
>>>> Confluence emails? I think that is better since it doesn't create
>>>> so much
>>>> noise. I don't want to discourage potential contributors from
>>>> subscribing to
>>>> this list. If so, I can't see where this setting lives in Jira.
>>>>
>>>
>>> +0. Either list is fine with me. It should be under "notification
>>> schemes"
>>>
>>
>> I'm not seeing that. Perhaps an access rights thing. Personally,
>> I'd love
>> to get them onto the svn list so that it is easier to track
>> conversations.
>>
>>
>> 3. I'll go through and assign all the M5 tasks which have been done
>> and the
>>>> ones I know are being worked on. If I feel like a mind-numbing
>>>> task one
>>>> night I'll do a few more earlier milestones as well. Any
>>>> objections to this
>>>> approach?
>>>>
>>>
>>> +1. A comments on the details: From experience using Jira as a
>>> release
>>> management tool on a commercial project, I'd suggest setting "Fix
>>> version"
>>> to the target milestone. Among other things this allows auto-
>>> generation of
>>> the release notes. "Affects Version/s" on the other hand should be
>>> the
>>> version <= "fix version" or null. For bugs, affected version is
>>> usually a
>>> version where a bug was discovered. For the new features it is
>>> more vague,
>>> and may even be left empty.
>>>
>>
>> Yes, that's what I've done so far. So we get something like this:
>>
>>
>> https://issues.apache.org/cayenne/secure/ReleaseNote.jspa?projectId=10000&styleName=Html&version=10120
>>
>> We'll convert our release notes file to html I guess. We can even
>> try again
>> to do that thing with embedding Jira blocks inside Confluence
>> although last
>> time we tried that had some problems with the export plugin we use at
>> Apache.
>>
>> Ari
>>
>>
>>
>>
>>
>> -------------------------->
>> ish
>> http://www.ish.com.au
>> Level 1, 30 Wilson Street Newtown 2042 Australia
>> phone +61 2 9550 5001 fax +61 2 9550 4001
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>>
>>
Re: Jira changes
Posted by Andrey Razumovsky <ra...@gmail.com>.
I've seen some obviously obsolete and dead issues in Jira, like CAY-1036 or
CAY-708. It'll be great to clean out those issues and assign among us bunch
of the most important opened ones.
As of the versions, detail version number is great.
About M5, I'm still not sure what should we do with CAY-1077. Switching
between single and double click is a minute work and I'd prefer we close it
and release M5 as fast as possible.
About Confluence, could someone give me permission rights to edit pages?
Username is "andrey".
2008/11/8, Aristedes Maniatis <ar...@ish.com.au>:
>
>
> On 08/11/2008, at 11:08 PM, Andrus Adamchik wrote:
>
> On Nov 8, 2008, at 2:32 AM, Aristedes Maniatis wrote:
>>
>> 1. Should we point Jira emails to the svn list instead just like
>>> Confluence emails? I think that is better since it doesn't create so much
>>> noise. I don't want to discourage potential contributors from subscribing to
>>> this list. If so, I can't see where this setting lives in Jira.
>>>
>>
>> +0. Either list is fine with me. It should be under "notification schemes"
>>
>
> I'm not seeing that. Perhaps an access rights thing. Personally, I'd love
> to get them onto the svn list so that it is easier to track conversations.
>
>
> 3. I'll go through and assign all the M5 tasks which have been done and the
>>> ones I know are being worked on. If I feel like a mind-numbing task one
>>> night I'll do a few more earlier milestones as well. Any objections to this
>>> approach?
>>>
>>
>> +1. A comments on the details: From experience using Jira as a release
>> management tool on a commercial project, I'd suggest setting "Fix version"
>> to the target milestone. Among other things this allows auto-generation of
>> the release notes. "Affects Version/s" on the other hand should be the
>> version <= "fix version" or null. For bugs, affected version is usually a
>> version where a bug was discovered. For the new features it is more vague,
>> and may even be left empty.
>>
>
> Yes, that's what I've done so far. So we get something like this:
>
>
> https://issues.apache.org/cayenne/secure/ReleaseNote.jspa?projectId=10000&styleName=Html&version=10120
>
> We'll convert our release notes file to html I guess. We can even try again
> to do that thing with embedding Jira blocks inside Confluence although last
> time we tried that had some problems with the export plugin we use at
> Apache.
>
> Ari
>
>
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
Re: Jira changes
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 08/11/2008, at 11:08 PM, Andrus Adamchik wrote:
> On Nov 8, 2008, at 2:32 AM, Aristedes Maniatis wrote:
>
>> 1. Should we point Jira emails to the svn list instead just like
>> Confluence emails? I think that is better since it doesn't create
>> so much noise. I don't want to discourage potential contributors
>> from subscribing to this list. If so, I can't see where this
>> setting lives in Jira.
>
> +0. Either list is fine with me. It should be under "notification
> schemes"
I'm not seeing that. Perhaps an access rights thing. Personally, I'd
love to get them onto the svn list so that it is easier to track
conversations.
>> 3. I'll go through and assign all the M5 tasks which have been done
>> and the ones I know are being worked on. If I feel like a mind-
>> numbing task one night I'll do a few more earlier milestones as
>> well. Any objections to this approach?
>
> +1. A comments on the details: From experience using Jira as a
> release management tool on a commercial project, I'd suggest setting
> "Fix version" to the target milestone. Among other things this
> allows auto-generation of the release notes. "Affects Version/s" on
> the other hand should be the version <= "fix version" or null. For
> bugs, affected version is usually a version where a bug was
> discovered. For the new features it is more vague, and may even be
> left empty.
Yes, that's what I've done so far. So we get something like this:
https://issues.apache.org/cayenne/secure/ReleaseNote.jspa?projectId=10000&styleName=Html&version=10120
We'll convert our release notes file to html I guess. We can even try
again to do that thing with embedding Jira blocks inside Confluence
although last time we tried that had some problems with the export
plugin we use at Apache.
Ari
-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Jira changes
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 8, 2008, at 2:32 AM, Aristedes Maniatis wrote:
> 1. Should we point Jira emails to the svn list instead just like
> Confluence emails? I think that is better since it doesn't create so
> much noise. I don't want to discourage potential contributors from
> subscribing to this list. If so, I can't see where this setting
> lives in Jira.
+0. Either list is fine with me. It should be under "notification
schemes"
> 2. I've changed the default assignee from Andrus to 'unassigned' for
> new tasks. Any objections? That might make it clearer what is being
> worked on.
No objections.
> 3. I'll go through and assign all the M5 tasks which have been done
> and the ones I know are being worked on. If I feel like a mind-
> numbing task one night I'll do a few more earlier milestones as
> well. Any objections to this approach?
+1. A comments on the details: From experience using Jira as a release
management tool on a commercial project, I'd suggest setting "Fix
version" to the target milestone. Among other things this allows auto-
generation of the release notes. "Affects Version/s" on the other hand
should be the version <= "fix version" or null. For bugs, affected
version is usually a version where a bug was discovered. For the new
features it is more vague, and may even be left empty.
Andrus