[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 7223 - trunk/packages/rpm/mandrake-9.1

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-09-29 03:58:25 CEST

Files <files@poetryunlimited.com> writes:

> Ok. Maybe someone needs to explain this to me once and for all.

I don't think that's possible, it's a learning process.

> I was backlogging the changes made over the course of 6982-current.

The log message for r7223 should describe the changes made in r7223.

> Was I supposed to go back and fix all the log messages that didn't
> contain enough information? OMG. You can't be serious.

Ideally, yes. Given that I don't really care about the Madrake build,
I'm not going to insist it is done. I'm not going to maintain the
Madrake build either.

> Second. I followed what was in the HACKING file. It said nothing about
> explaining anything except for individual files. Did I miss that too?

If you looked at past log messages, as suggested by the HACKING file
and by other people on this list, you would have seen that it is
common to do so. Is it so hard to understand that your log message
should have a format like all the other log messages? Have you ever
looked at other log messages?

[...]
>> > * 46_mod_dav_svn.conf
>>
>> * packages/rpm/mandrake-9.1/46_mod_dav_svn.conf
>>
>> The HACKING guidelines say to use full path names, the other log
>> messages use full path names, you should use full path names.
>
> It does not say anything about full path names. It only says something
> about path names when your changes are strewn about in all sorts of
> places.

There are three files called 46_mod_dav_svn.conf, your log message
doesn't tell me which one changed. (It also left me wondering why the
other two didn't change, but there is no real need for a log message
to document changes that are not made :-)

[...]
>> I'm not really interested in Mandrake or Java, I tend to ignore the
>> dev list emails about them. As far as I can tell you have added some
>> sort of Java patch (fairly large) to the Madrake build. What does it
>> do? Did you write it? Did someone else? I should be able to tell
>> from the log message, just a single sentence summary will do.
>>
>> I must admit I don't understand why you need to make such extensive
>> changes to the build system in order to build Mandrake packages.
>
> There is a patch that's been floating around in this discussion. It
> modifies the javahl directory in the subversion/bindings/java.
>
> Since *I* don't own the patch, I simply added it so that at least a
> Mandrake JAVAHL RPM could be built. I will be removing it as soon as the
> patch is finalized.

I don't know anything about the JAVAHL, but that sounds a bit
premature to me. Will the future main build be compatible with your
Madrake build? If the main build of JAVAHL doesn't work why is it so
important that the Mandrake build works? Perhaps you could simply
avoid building JAVAHL? Perhaps you would be better employed getting
the patch into the main build.

If you do include a patch the least you can do is to give credit in
you log message:

  Include JAVAHL patch from "Jack Daniels" <jd@100-proof.org> to
  frobnicate the foobar.

> As for the changes to the build system, explain to me:
>
> * Why I would have to go digging through the entire build process to
> make updates to names of RPMs and version numbers.

You must be refering to the Mandrake build process, the normal build
process doesn't involve RPM names or version numbers. The answer
would be that nobody added the support you are asking for.

> * Why I couldn't build at all in the first place.

I have no idea, perhaps the Madrake build process was out of date,
perhaps it never worked.

> * Why the documentation build process is not running and therefore does
> not create Mandrake doc RPMS.

Ditto.

> * Why the build process is so noisy especially during RPM compilation
> that I can't even see where the error occurred.

So when users post their build problems to the list there is some
chance of seeing what went wrong.

I can't be bothered answering any more of these stupid questions.

[...]

> I've created an RPM build process that can be run by anyone.
>
> I've created an RPM build process that allows you to configure what you
> want to happen at the command line intelligently, and your choices
> propagate through. I've allowed you to filter out the noise, as well as
> turn it back on. I've allowed you to specify where your java is, as well
> as if you want the java bindings built, whether you want documentation,
> or couldn't care less.

Sounds a bit like overkill to me.

> I've given sweat and blood to make this usable for just about anyone.
>
> And all I get is more and more and more problems and more and more nits,
> and more and more questions.

If your work doesn't "fit", if you do things differently from the rest
of us, then we will ask you to change. Would you prefer to be
ignored? Given my lack of interest in either Mandrake or Java,
ignoring you is looking more and more attractive.

> Maybe I should have just built it for myself and ignored everyone else.

Yes, perhaps that would have been better.

> At least I would have been happy. Stupid me decided he wanted to give
> back to the community and hopefully build or help build the stock
> Mandrake RPMs.
>
> ********************************************************************
>
> Will someone at least for once tell me what the membership of the Log
> Police is and who is in charge?

The "Log Police" consist of those people who can be bothered to read
and respond to the log messages. Nobody is "in charge", or if you
prefer, everybody is "in charge". Is this news to you?

> I can't keep changing things every time someone *else* thinks that the
> HACKING file needs to be interpreted yet another way.

That's the way open peer review works. We ask questions and make
suggestions and you justify what you do and/or make changes.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 29 03:59:04 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.