Title: Message Title
Mark H. Wood updated an issue
Title: Message Title
Mark H. Wood updated an issue
Title: Message Title
Mark H. Wood assigned an issue to Mark H. Wood
Title: Message Title
Mark H. Wood updated an issue
Title: Message Title
Mark H. Wood created an issue
++1
On 24 January 2014 21:53, Pottinger, Hardy J. wrote:
> +1
>
> --Hardy
>
>
>
>
> On 1/24/14 3:50 PM, "Tim Donohue" wrote:
>
> >+1
> >
> >IMHO it really shouldn't be deprecated as we never have had a formal
> >plan to replace it. Once a formal plan is in place, and we've taken
> >steps toward
Title: Message Title
Humberto Blanco created an issue
+1
--Hardy
On 1/24/14 3:50 PM, "Tim Donohue" wrote:
>+1
>
>IMHO it really shouldn't be deprecated as we never have had a formal
>plan to replace it. Once a formal plan is in place, and we've taken
>steps towards implementing that plan, we can re-deprecate it if needed.
>
>On 1/24/2014 2:58 P
+1
IMHO it really shouldn't be deprecated as we never have had a formal
plan to replace it. Once a formal plan is in place, and we've taken
steps towards implementing that plan, we can re-deprecate it if needed.
On 1/24/2014 2:58 PM, Mark H. Wood wrote:
> Continuing in the "things that bug Mark
Continuing in the "things that bug Mark no end" vein
DCValue has been @Deprecated for ages, but it's still used all over
and I don't readily see why it is deprecated. The class was created
in 2002, gained a 'schema' member in 2005, and then was deprecated in
2007. Why?
We seem to have a bun
Title: Message Title
Mark H. Wood commented on an issue
(This is independent of Metadata for All, which is needed anyway.)
I want to attach to Collections lists of operational data, with
multiple values per Collection. I immediately thought of overloading
"metadata" for this purpose, given that we want to extend metadata
operations to all DSpaceObject
Title: Message Title
Tim Donohue commented on an issue
On Thu, Jan 23, 2014 at 11:42:09AM -0600, Tim Donohue wrote:
> Yes, the logic is a little bit confusing, but I've finally figured it out.
>
> Here's what's going on (sorry for the tons of detail, but writing this
> out actually helped me figure out *why* this works):
>
> (1) When Item class is l
Title: Message Title
Tim Donohue closed an issue as Duplicate
Title: Message Title
Tim Donohue updated an issue
Title: Message Title
Ivan Masár updated an issue
Title: Message Title
Ivan Masár updated an issue
Title: Message Title
Ivan Masár updated an issue
Title: Message Title
Ivan Masár updated an issue
Title: Message Title
Ivan Masár closed an issue as Fixed
Title: Message Title
Ivan Masár commented on an issue
Title: Message Title
Ivan Masár updated an issue
Title: Message Title
Ivan Masár updated an issue
Title: Message Title
Adan Roman commented on an issue
Title: Message Title
Adan Roman updated an issue
Title: Message Title
Ivan Masár commented on an issue
Title: Message Title
Àlex Magaz Graça commented on an issue
Title: Message Title
Adan Roman commented on an issue
Title: Message Title
Adan Roman created an issue
Title: Message Title
Jordan Piščanc commented on an issue
Title: Message Title
Panagiotis Koutsourakis commented on an issue
Title: Message Title
Jordan Piščanc created an issue
I see. We were starting with different assumptions. I assumed most
people develop on master, even bugfixes.
Anyway, I think I made all my points. Let's see what others think. I'm
still not strongly convinced, but I'm not opposed to your proposal, I
was just trying to find out the benefits.
Off-t
The real point here is not against what the PR is fired but from which
branch contributors start to work.
We cannot change a PR but we can open a PR from a third repository vs
our repository but this doesn't matter as if the contributor start to
work on the bug fix from the master we will get al
Those are finally some good arguments :)
I imagine merging from release to master brach only at the time of
feature freeze is too late. I'd definitely favour continuous porting
as soon as the fixes appear (before the branches diverge which means
conflicts).
But even though I like the idea of doin
Yes, it is.
We have the same requirements for ETD and I expect that similar
requirements will arise for DataSet collection at some point.
Our solution, actually part of our enterprise version and not released
as open source, is much different than the new infrastructure to mint
identifiers so I
Il 23/01/2014 15.10, helix84 ha scritto:
> On Thu, Jan 23, 2014 at 2:41 PM, Andrea Bollini wrote:
>> According to this workflow it looks better manage bugs as PR against 4.x
>> than as PR against the master. In this way if we miss to merge something to
>> the master we can do it later also in one
38 matches
Mail list logo
