On Thu, Mar 8, 2012 at 3:53 PM, Mark A. Matienzo <[log in to unmask]> wrote:

> On Thu, Mar 8, 2012 at 3:32 PM, Godmar Back <[log in to unmask]> wrote:
>
> > One side comment here; while smart handling/automatic detection of
> > encodings would be a nice feature to have, it would help if pymarc could
> > operate in an 'agnostic', or 'raw' mode where it would simply preserve
> the
> > encoding that's there after a record has been read when writing the
> record.
> >
> > [ Right now, pymarc does not have such a mode - if leader[9] == 'a', the
> > data is unconditionally utf8 encoded on output as per mbklein's patch. ]
>
> Please feel free to write a patch and submit a pull request if you're
> able to contribute code to do this.
>
>
Mark, while I would be able to contribute code to pymarc, I probably won't
(unless my collaborators' needs in respect to pymarc become urgent.)

I've been contributing to open source for over 15 years, my first major
contribution having been the ext2fs filesystem code in the FreeBSD kernel (
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/filesystems-linux.html
)
and I'm a bit confused by how the spirit in the community has changed.  The
phrase "patches welcome" used to be reserved for when there was a feature
request somebody wanted, but you (the owner/maintainer of the software)
didn't have the time or considered the problem not important.

Back then, it used to be that all suggestions were welcome. For instance,
if a user pointed out a typo, you'd fix it. Similarly, if a user or fellow
developer pointed out a potential design flaw, you'd understand that you
don't ask for patches, but that you go back to the drawing board and think
about your software's design. In pymarc's case, what's needed is not more
code (it already has a moderately confusing set of almost a dozen switches
for reading/writing), but a requirement analysis where you think about use
cases you want to support. For instance, whether you want to support
reading/writing real world records in batches (without touching them) even
if they have flaws or not. And/Or whether you insist on interpreting a
record's data in terms of encoding, always. That's something occasional
contributors cannot do, it requires work by the core team, in discussion
with frequent users. (I would have liked to take this discussion to a
pymarc-users list, but didn't find any.)

 - Godmar