[
http://jira.codehaus.org/browse/SUREFIRE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=267444#action_267444
]
Chad Wilson commented on SUREFIRE-704:
--
(Possibly not, re: 2nd question - as mvn -q test still
[
http://jira.codehaus.org/browse/SUREFIRE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=267495#action_267495
]
Chad Wilson commented on SUREFIRE-704:
--
Excellent - thanks Kristian. I'll add a dummy ticket
Issue Type: Bug
Components: Maven Failsafe Plugin, Maven Surefire Plugin
Affects Versions: 2.8.1, 2.8
Reporter: Chad Wilson
In Surefire 2.8 and 2.8.1 there is no std-out and std-err being included in
test reports for either the Surefire or Failsafe plugins
[
http://jira.codehaus.org/browse/SUREFIRE-741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chad Wilson closed SUREFIRE-741.
Resolution: Fixed
Fix Version/s: 2.9
I have tested this in 2.8.2-SNAPSHOT (now 2.9-SNAPSHOT
[
http://jira.codehaus.org/browse/SUREFIRE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263809#action_263809
]
Chad Wilson commented on SUREFIRE-704:
--
Alas, I spoke too soon. Getting random failures again
[
http://jira.codehaus.org/browse/SUREFIRE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=263648#action_263648
]
Chad Wilson commented on SUREFIRE-704:
--
Apologies Kristian, I missed your reply earlier
[
http://jira.codehaus.org/browse/SUREFIRE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=258150#action_258150
]
Chad Wilson commented on SUREFIRE-704:
--
It's possible that this is spurious (and it certainly
[
http://jira.codehaus.org/browse/SUREFIRE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=258150#action_258150
]
Chad Wilson edited comment on SUREFIRE-704 at 3/2/11 12:28 AM:
---
It's
Hi Martin
Thanks - yes, that's what we are thinking of doing as a workaround slightly
easier than a code change. I'll give it a go and see if it does as expected.
I guess it depends whether Camel goes back to the factory for each message
or whether the bean is cached somewhere. Conversely, I
Thanks Claus.
Do you think this issue might affect BeanInfo use elsewhere in Camel, e.g.
in bean/simple expressions, or is the BeanInfo introspection repeated
separately for each exchange in those cases, thus not shared between
threads?
--
View this message in context:
Hi guys
An issue occurred today which surprised me - Camel 2.4.0 threw a
ConcurrentModificationException and caused a message to be lost on a route.
We have a route that essentially simplifies down to
from(jms:queue:myQueue?concurrentConsumers=3)
.unmarshal()
.to(bean:mySpringBean);
Affects Versions: 2.5.0
Reporter: Chad Wilson
Priority: Minor
I think it'd be worth clarifying in the documentation for showStackTrace at
http://camel.apache.org/log.html that you must have one of showAll,
showException or showCaughtException defined
Claus Ibsen-2 wrote:
So where does your exception occur?
And where do you expect Camel to react?
The exception is engineered by the test to occur inside the JMS Component
when trying to establish a connection to an invalid host. While my test case
uses the TIBCO connection factory, the
On 8/04/2010 9:39 a.m., Brian Schweitzer wrote:
On Wed, Apr 7, 2010 at 8:33 PM, Chad Wilson chad.wil...@gmx.net
mailto:chad.wil...@gmx.net wrote:
On 8/04/2010 2:15 a.m., Brian Schweitzer wrote:
Track titles would not, however, and the principle's page is quite
clear
On 8/04/2010 2:15 a.m., Brian Schweitzer wrote:
Track titles would not, however, and the principle's page is quite
clear that it is solely about track titles:
This is the Style Principle used for ambiguous track titles, where
there are multiple track titles (sometimes with different
On 31/03/2010 6:10 a.m., Brian Schweitzer wrote:
Veto as well. I'm not going to argue and argue ad nauseum about
each sentence in the earlier thread, deconstructed sentence by
sentence and quibbling about definitions of deleting as was your
last reply to mine.
I don't know
On 24/03/2010 8:53 a.m., Brian Schweitzer wrote:
On Tue, Mar 23, 2010 at 8:34 PM, Chad Wilson chad.wil...@gmx.net
mailto:chad.wil...@gmx.net wrote:
On 24/03/2010 8:12 a.m., SwissChris wrote:
On Tue, Mar 23, 2010 at 8:55 PM, Per Øyvind Øygard
pero...@stud.ntnu.no mailto:pero
On 25/03/2010 1:51 a.m., Brian Schweitzer wrote:
On Wed, Mar 24, 2010 at 12:06 PM, Chad Wilson chad.wil...@gmx.net
mailto:chad.wil...@gmx.net wrote:
On 24/03/2010 8:53 a.m., Brian Schweitzer wrote:
On Tue, Mar 23, 2010 at 8:34 PM, Chad Wilson chad.wil...@gmx.net
On 20/03/2010 6:43 p.m., Brian Schweitzer wrote:
Remix Relationship Type is both track-track and release-release.
Remixer Relationship Type is both release-artist and track-artist.
But while examples are provided, neither actually defines the case
where the release version would be valid.
On 18/03/2010 3:43 a.m., Brian Schweitzer wrote:
On Wed, Mar 17, 2010 at 3:29 PM, Frederic Da Vitoria
davito...@gmail.com mailto:davito...@gmail.com wrote:
2010/3/17 Brian Schweitzer brian.brianschweit...@gmail.com
mailto:brian.brianschweit...@gmail.com
Going through the
On 15/03/2010 8:40 p.m., Brian Schweitzer wrote:
Does anyone know anything about Band With Main Performer Name? Band
With Main Performer Name also is odd, in that it seems to define a
case where we would actually invent an artist. Supporting Musician
Relationship Type formerly had this
On 12/03/2010 8:17 a.m., Brian Schweitzer wrote:
This indicates that the person collaborated in their engineering
duties, with another engineer or with the performing artist
This relationship attribute exists for the Engineer Relationship Type,
and should exist (but hasn't been implemented
On 17/03/2010 12:00 a.m., Brian Schweitzer wrote:
On Tue, Mar 16, 2010 at 10:33 AM, Chad Wilson chad.wil...@gmx.net
mailto:chad.wil...@gmx.net wrote:
On 16/03/2010 7:10 a.m., Brian Schweitzer wrote:
Are all these changes enough to make the AR both seem useful and
non
On 18/03/2010 1:09 a.m., Brian Schweitzer wrote:
This is RFC-251. Assuming a seconder, and without objections, this
proposal will move to RFV on 2010-03-24. :)
This proposal would change how we handle Engineers. It would keep the
current level of detail, but make engineer ARs more
On 16/03/2010 1:51 a.m., Brian Schweitzer wrote:
I agree that eventually a Series or Box entity would be most
desirable, but until then, there's no other way that would allow
linking together Series. For a multi-volume classical set of a single
composer, that's an annoyance, but not a real
On 10/03/2010 5:27 p.m., jacobbrett wrote:
I'm championing a new version of this guideline here (haven't yet
edited/reviewed it):
http://wiki.musicbrainz.org/User:Jacobbrett/Release_Groups
There appears to be no history for the user page to show what has
changed from the version that was
On 17/03/2010 9:30 a.m., Brian Schweitzer wrote:
On Tue, Mar 16, 2010 at 9:19 PM, drsaunde drsau...@hotmail.com
mailto:drsau...@hotmail.com wrote:
Brian Schweitzer wrote:
(I wish I had've noticed that all traditional compositions would
become
unknown before it
On 16/03/2010 9:18 p.m., drsaunde wrote:
Veto. No time to provide reasons but they will be with the original
proposal.
There is a reason many proposals stalled, because they are crap.
Are you even dealing with original concerns issues with proposals before
ramming all this crap through (I
On 16/03/2010 7:10 a.m., Brian Schweitzer wrote:
Are all these changes enough to make the AR both seem useful and
non-problematic? :)
This remains RFC-68. Without continued objection/debate, this new RFC
will move to RFV status on 2010-03-22.
Thanks!
Brian
Not really, no. I don't
That's just silly talk. No-one is complaining that raw # emails is the
issue. It's the amount of thinking required content that causes the
issue, and evidence that others have actually looked at and considered a
proposal is a good thing. If 3 or 4 people I trust have already said +1
to a
On 17/03/2010 7:34 a.m., SwissChris wrote:
On Mon, Mar 15, 2010 at 3:46 PM, Brian Schweitzer
brian.brianschweit...@gmail.com
mailto:brian.brianschweit...@gmail.com wrote:
I've run into another 2 ARs with open issues and suggestions
dating back anywhere from 1 to 4 years, without
On 11/03/2010 7:59 a.m., Brian Schweitzer wrote:
To be honest, I don't understand the complaint.
You guys are complaining about a flood, talking about a mailing list
where there has been an average of... only 15 emails a day (including
all the emails complaining about this 'flood'). Also
I personally think the list is being flooded with far too much
content/blah to be reviewed in the amounts of time the current RFC/V
process allows.
This isn't fair. It risks things being swept through the system without
proper care and oversight which is the opposite of what the process is
On 9/03/2010 9:57 p.m., Chris B wrote:
Trac: http://bugs.musicbrainz.org/ticket/3032#comment:20
Proposal: http://wiki.musicbrainz.org/Samples_From_Relationship_Type
which is similar to http://wiki.musicbrainz.org/IMDb_Relationship_Type
(not sure that they could be consolidated, though!)
Sorry
On 7/03/2010 2:56 p.m., Brian Schweitzer wrote:
I think the fear is there'd be tons of URLs linked, but without
any context, those URLs don't give much, other than that you know
there's some news article about the artist on the other end.
However, if the AR description field
On 2/03/2010 11:16 a.m., jacobbrett wrote:
neothe0ne wrote:
Even for English/Latin releases, guess case, and English
capitalization
standard is destructive. Japanese releases consistently use
capitalization
for something other than language (ever heard of style?), yet according to
MB
at 2:33 AM, Chad Wilson chad.wil...@gmx.net
mailto:chad.wil...@gmx.net wrote:
I think this needs to be properly clarified as to its intention.
People will start adding links to individual articles about
artists or releases which /surely/ cannot be the goal of this
proposal
I think this needs to be properly clarified as to its intention. People
will start adding links to individual articles about artists or releases
which /surely/ cannot be the goal of this proposal? If that were it
happen it seems to me that it will create an absolute mess of links of
dubious
On 27/02/2010 12:30 a.m., Brian Schweitzer wrote:
On Fri, Feb 26, 2010 at 12:43 AM, Kuno Woudt k...@frob.nl
mailto:k...@frob.nl wrote:
On Thu, Feb 25, 2010 at 08:07:24PM +0800, Chad Wilson wrote:
My own apprehension was caused by a couple of factors:
1 - IIRC (and I
pages that have been created so
far, and it seems to be pretty well thought out and documented. What
information needs to be added (if any), for this to be appropriate for
the RFC stage?
On 23/02/2010 4:35 a.m., Chad Wilson wrote:
My apologies; I didn't see this message before replying
On 25/02/2010 11:04 p.m., Nikki wrote:
I'd much rather see all entries in a release group linked to the same
entry (typically earliest). It makes it a lot easier for someone to see
which releases belong to the series (and we have release events if
people want to generate lists sorted by
My apologies; I didn't see this message before replying to your other
thread on mb-users. Kinda cross posting here.
The follow-up to the below was the writing of
http://wiki.musicbrainz.org/Part_Of_Series_Relationship_Type and
associated terminology page http://wiki.musicbrainz.org/Series
On 18/02/2010 11:50 p.m., Brian Schweitzer wrote:
Personally, I don't think groups should have genders. Would simply a
group, like New Kids on the Block, being known as a boy band then
make it a male group, rather than simply a group - and if so,
wouldn't whatever special meaning is being
[
http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=208161#action_208161
]
Chad Wilson commented on MECLIPSE-262:
--
The core issue here still happens with maven-eclipse
On 23/01/2010 4:20 p.m., Frederic Da Vitoria wrote:
2010/1/23 Chad Wilson chad.wil...@gmx.net mailto:chad.wil...@gmx.net
On 23/01/2010 6:04 a.m., Paul C. Bryan wrote:
I'd like to see if people's views on the Miscellaneous Guideline
[http://wiki.musicbrainz.org
On 23/01/2010 6:04 a.m., Paul C. Bryan wrote:
I'd like to see if people's views on the Miscellaneous Guideline
[http://wiki.musicbrainz.org/Miscellaneous_Guideline] has changed since
it was incepted, specifically regarding the use of ASCII for
compatibility.
I'm in favor of removing these
I like the general idea of this, but I don't understand parts of it.
While I'm not an audiobook fanatic, I think that's a problem. I'm mainly
talking about the track title section.
For point 1 - is this only valid if the release only has a single track?
It doesn't read correctly to me if I am
On 13/12/2009 9:59 p.m., Brian Schweitzer wrote:
Renames:
* Rename [data track] to [data].
Sorry to be very late on this one, but I just noticed the data track
rename. Note that this artist is actually referred to in the Official
Guideline at http://musicbrainz.org/doc/DataTrackStyle
Andrew Conkling wrote:
On Oct 29, 2009, at 22:20, Chad Wilson wrote:
For anyone who wants to help me confirm, the notable samples are at
A) 0:00-0:12
B) 0:50-0:59 (and looping every 11-12 seconds or so)
http://www.youtube.com/watch?v=Yu1eDW8iS8I
I believe sample A comes from 1:42 - 1
Thanks a lot for your replies guys.
The sample is credited as:
Contains samples from Requiem K 626, Rex Tremendae Majestatis
Requiem K 626 Confutatis (Motzart). Performed by Wolfgang Amadeus Motzart.
Used courtesy of Fantasy Records. UBP. ARR.
- can one infer anything from Fantasy
Pavan Chander wrote:
On Fri, Jul 31, 2009 at 6:38 PM, Aurélien Mino a.m...@free.fr
mailto:a.m...@free.fr wrote:
In the last section of the page, we have:
The title of a release group should usually be the title of its
individual releases, removing Extra Title Information
Brian Schweitzer wrote:
Honestly, since when did we ever decide to actually change data, the
meaning of entity types, or decide to make an objective field into a
subjective field simple because it made one view of the data look
cleaner? If people want session entities, to group all
Brian Schweitzer wrote:
Secondly, we're not changing the meaning of anything. The feature is
new; we're defining it for the first time. So don't paint it as if
someone is skewing the original developer intention of the concept -
that's not the case, and you're weasel wording.
Edward J. Shornock wrote:
* Toni Panadès ton...@gmail.com [16-07-2009 21:11 EEST]:
I agree completely with pbryan, should not be complex to check
periodically and automatically for invalid URL's.
Agreed as well. Any site's page can disappear at any time; fear of
future 404s
If money is the issue, then why don't we just put targeted Amazon or
Google Ads all over the site rather than corrupting the dataset?
I'm being facetious, but it's a serious point - moving into something
that looks like selling ARs doesn't feel like the MB way to me. More
careful consideration
Completely agreed with Brian. There is no need for a guideline here
which would merely conflict with the (admittedly vague, but only
workable) principle of ConsistentOriginalData.
I'm not even sure what problem this is trying to solve.
Chad
Brian Schweitzer wrote:
(Clarification note to the
Kuno Woudt wrote:
On Tue, May 26, 2009 at 10:47:45AM -0400, Pavan Chander wrote:
Yes you can merge/move a release group from VA to a single artist. You
pointed out it would be lost, what I would like to point out is that it is
already lost, and moving it to an artist (other than Various
Gioele wrote:
So, I vote for scenario 1.
That is the only scenario that does not exploit the fact that we have
release groups, and is, in fact, what we did before we had release groups :)
This is entirely expected, since WhatDefinesAUniqueRelease and the
philosophy underlying it
Bram van Dijk wrote:
Please correct me if I didn;t understand this right.
But I thought the release groups were supposed to make things cleaner.
So if we have an original release and a re-release, they can go into the
same release group.
Now you are proposing to not merge them (if the
Brian Schweitzer wrote:
The several different threads running at the moment all seem, to me,
to be pointing to the fact that we have not actually defined what a
release group is.
The soundtracks case has the problem of increasing scope; the more we
expand what we would or wouldn't group,
+1
Thanks a lot, Kuno!
Kuno Woudt wrote:
Hello,
On Fri, May 22, 2009 at 08:44:41AM +0800, Chad Wilson wrote:
While I realise that it will be reasonably straightforward in this case,
I'd rather see the documentation page beforehand, as a matter of
principle. Since documentation
Hi all
As you most know, very soon Release Groups will be live. Style is
obviously a work in progress as we're not sure how it's all going to
work out across the variations in the real world but the basic cases are
reasonably well known. Pronik, prodoc, gioele, navap, ruaok and I have
put
Yeah, it's certainly worth discussing this. You'll note that the page as
it currently stands says to merge transliterations/translations, but not
alternate-language releases. Maybe this is confusing. I fear there may
be many variations I'm not aware of as well.
The main issue I could thinking
While I realise that it will be reasonably straightforward in this case,
I'd rather see the documentation page beforehand, as a matter of
principle. Since documentation == guideline I think we need to
vote/withold veto/comment on the basis of the advice rather than just
the idea?
Chad
Kuno
On 13/05/2009 7:44 p.m., Age Bosma wrote:
Hi,
I'm not sure if this has been discussed before but:
Now that we have the new wiki up and running, are there any objections
again moving the discussion chapters on the article pages itself to
the discussion section for each article? The same would
to Talk:Foo and Talk:Bar
respectively, so I don't think there are any separate discussion pages
still left to deal with.
Pavan Chander // navap
On Wed, May 13, 2009 at 9:23 AM, Age Bosma agebo...@gmail.com
mailto:agebo...@gmail.com wrote:
2009/5/13 Chad Wilson chad.wil...@gmx.net
On 4/05/2009 7:51 p.m., Aurélien Mino wrote:
Hi,
As some of you already know, Discogs has recently introduced ([1]) the
concept of 'master release' which corresponds to what we name 'release-group'.
Since we don't yet have release-group, and since our first implementation of
release-group
On 5/05/2009 5:45 a.m., Fred Marchee wrote:
My thoughts exactly, the links to Discogs doesn't add any info to me
other than pictures so why bother?
Fred (fred576)
Age Bosma wrote:
Aurélien Mino wrote:
Should we accept links from our current releases to both Discogs masters
On 1/05/2009 12:44 p.m., Brian Schweitzer wrote:
Completely agreed, 100%. In the current lack-of-debate situation
we have, I think I would personally veto any RFV that recommends
use of obscure typography for normal situations, including the
en-dash. Brian, people are so burnt
On 25/04/2009 8:15 p.m., Brian Schweitzer wrote:
On Sat, Apr 25, 2009 at 6:17 AM, Kuno Woudt k...@frob.nl
mailto:k...@frob.nl wrote:
On Sat, Apr 25, 2009 at 10:55:47AM +0800, Chad Wilson wrote:
On 24/04/2009 10:29 p.m., Chris B wrote:
2009/4/24 Brian Schweitzerbrian.brianschweit
On 24/04/2009 10:29 p.m., Chris B wrote:
2009/4/24 Brian Schweitzerbrian.brianschweit...@gmail.com:
This was my point before; this is the whole point of transclusion, that the
wiki version can be edited for various reasons. There shouldn't be a reason
we need to have both versions on the
On 24/04/2009 7:38 a.m., Brian Schweitzer wrote:
so revert your change, do an RFC like the rest of us have to, and we
can all get on with our lives.
Please, stop the condesension. Example != guideline. There is no
need, nor reason, to revert. The example, as I have pointed out
On 22/04/2009 12:28 a.m., Brian Schweitzer wrote:
* Is there a good reason to have spaces? Yes.
But no-one agrees with you as far as I can see, so the example should be
reverted and this should stop here.
And yes, examples are supporting text as part of a guideline; and thus
part of the
On 22/04/2009 4:25 a.m., Paul C. Bryan wrote:
Proposal:
Change item #5 in the SortNameSytle to read as follows:
If an ArtistName consists of two or more collaborating artists, each
individual name is sorted separately according to the rules below. The
separator between artists (e.g. and,
On 19/04/2009 10:57 p.m., Jan van Thiel wrote:
2009/4/18 Bogdan Butnarubogd...@gmail.com:
By the way, this disambiguates numbering schemes with sub-parts, e.g.
“Parts 1-3–3-7”, or “Parts twenty-two–seventy-nine”.
On the other hand, I see no reason why we wouldn't simply have as a
rule
+1 for no spaces as well. GC can't fix everything.
On 17/04/2009 12:25 a.m., Paul C. Bryan wrote:
P.S. I didn't think we had transclusion from MB to docs yet. Do we? So,
if it got to docs, then someone changed it there too?
The page was changed prior to the Wiki migration; and since the
The same judgment has to be made all the time on samples vs. remix,
mashup vs remix, remix vs later version etc etc. It is nothing new for
MusicBrainz to require subjective consideration of the musical content
of a track/song.
Almost exactly the same text is used at
On 28/03/2009 9:49 a.m., Chris B wrote:
2009/3/28 Jacob Brettjacobbr...@hotmail.com:
I'm not sure that this is the direction MusicBrainz wants to take, but say
for example that a promo version of an album is released and listed in
MusicBrainz with 'Release Status' as promo, then later the
On 24/03/2009 10:15 p.m., Paul C. Bryan wrote:
Okay. So, trying again, with new information, I'd propose:
1. Sort name: always use ampersand as an artist delimiter.
2. Artist name: prefer the use of ampersand over and where there is no
artist intent or consistent original data. Leave other
+1 too.
Yes, we must standardise for use in DISCNUMBER and, as luks says, to
preserve the workaround's integrity.
In the A-F case, I have always edited the discs like (disc 1) - ignoring
and A -F. Although I have seen cases like (disc 1: X), (disc 2: Y). Not
the best, but it preserves the
On 4/02/2009 10:47 p.m., Bogdan Butnaru wrote:
Hello!
I've come over edit http://musicbrainz.org/show/edit/?editid=10059397
earlier and I'm not sure how to interpret the guidelines at
http://musicbrainz.org/doc/SoundtrackTitleStyle
The guideline says « The title should exclude secondary
Uh-huh, most of us agree on that much. Same could be said of pretty much
every guideline at MB.
The page does specifically say Secondary information that is to be
excluded will mostly look like a sub-title as per SubTitleStyle
http://wiki.musicbrainz.org/SubTitleStyle., however this line could
On 28/01/2009 9:43 p.m., Gioele wrote:
Brian Schweitzer wrote:
I for one would like to keep the dates real, not interpreted. However,
I have wished in the past for a founded attribute for the member of AR,
to allow this info to be captured in a different way.
I would prefer
On 28/01/2009 6:01 a.m., Philip Jägenstedt wrote:
On Tue, Jan 27, 2009 at 6:37 PM, Gioelegio...@svario.it wrote:
Aaron Cooper wrote:
Can't we just give the member the same start date as the band?
It leads to unnecessary duplication of data. Also it is more difficult to
I presume the *RelationshipType documentation pages will be written
along with actual implementation.
Same for I(O)BDb.
On 20/01/2009 1:53 p.m., Brian Schweitzer wrote:
The original proposal having long since passed 7 days, and the renewed
deadline for this RFC having just passed without
On 13/01/2009 5:50 p.m., Chris B wrote:
2009/1/13 Brian Schweitzerbrian.brianschweit...@gmail.com:
Welcome back Jim!
Ok, just for the record, in a discussion on how we can fix the RFC/RFV
process, and clean up old proposals, etc, Robert made the decision in IRC
the other day that all
I don't think we'd duplicate, but you could add both relationships to
disc 1, even though the text currently doesn't make much sense in English.
On 11/01/2009 11:17 p.m., SwissChris wrote:
I'm working right now on artist Renaud Papillon Paravels release
Subliminable
On 12/01/2009 3:03 a.m., Bogdan Butnaru wrote:
On Sun, Jan 11, 2009 at 5:37 PM, Chad Wilsonchad.wil...@gmx.net wrote:
disc 1, even though the text currently doesn't make much sense in English.
I don't think we'd duplicate, but you could add both relationships to
It makes perfect
+1
This is sorely needed in order to point editors to - thanks Brian for
bringing it back up again.
There are still AutoEditors (and other experienced editors) editing in
opposition to that earlier discussion due to the lack of formalisation
in the guidelines.
Chad / voiceinsideyou
On
On 8/01/2009 6:36 a.m., Chris B wrote:
i don't see what difference this is to the RFC? we're discussing what
ARs and usages of those ARs need to go in what case. how can you
separate the cases from the useage?
I think we can. Examples and general principle should be enough to guide
the
I don't think that in the general case we should stop the name being
overloaded, as it kinda is in the case you mention (ignoring merits of
individual case).
If this is how an artist is generally referred to, this is how we should
credit them IMO; which is the best we can do with our current
On 23/12/2008 5:05 a.m., Chris B wrote:
perhaps this has already come up, but is there any particular reason
why i can't see CD-ID additions in a release's edit history? only i
think if we had access to that things would be a lot easier - eg a
dodgy looking CD-ID addition could be
Kuno Woudt wrote:
On Fri, Oct 17, 2008 at 09:22:15AM +0800, Chad Wilson wrote:
Sidenote: but does anyone actually know who is still around/active and
actually has the authority to veto an RFV (other than luks, rob)?
Anyone can veto an RFV.
(whoever does so will have to defend his
ijabz wrote:
Chris B wrote:
Hi Paul,
well, there is no real need to 'drop' the use of any particular cat#s.
in time we will probably go as far including matrix codes or LP run
out groove codes, as once you start getting into the meat of cat#s and
label organisation (as i've found at
Steve Wyles wrote:
On Thu, 18 Sep 2008, Toni Panadès wrote:
The problem begins for me when I add a new artist: Love Song
Surprise artist
(http://musicbrainz.org/artist/553a3f2c-2600-46ce-8f60-24e6ee6f13c6.html).
LSS it's a group where the main artist is Dennis White (AKA Static
Revenger),
OK, can we please get some clarity about how migration will be handled,
if/when we decide?
To be clear, I am under the impression that edits to the current
MediaWiki will be lost prior to any actual migration date due to the
need to stay up to date with respect to what's in MoinMoin now.
How
Unleash the de-la-hunt-in-ator!
Robert Kaye wrote:
I just posted this to the blog:
http://blog.musicbrainz.org/?p=339
Congratulations Jim!
--
--ruaok Somewhere in Texas a village is *still* missing its idiot.
Robert Kaye -- [EMAIL PROTECTED] --
I agree with everything you've said -- I think you're certainly on the
right track. I'm ready to declare Jim as the new style leader? Does
anyone have any objections? If so, speak up now!
I also completely agree with most of Jim's points as well; well thought out,
well written and even
Hi all
As mentioned in the other thread, I've spent some time cleaning the information
in the wiki surrounding Release Terminology and the ReleaseNavigation card.
This includes:
- adding card navigation headers
- moving discussions off page
- adding basic definitions where missing
- partly
From previous experience with this sort of thing (the expansion of
usage for a list(s)), I am thinking you guys have entered a territory
better served by a forum. One subscription gets you access to the
cafe, announcements, n00b section, teachers, core functions, etc.
While a forum lacks the
301 - 400 of 427 matches
Mail list logo
