<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
On Fri, 2011-10-07 at 13:28 -0700, Jeremy Huddleston wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
>> On Oct 6, 2011, at 1:09 PM, Gaetan Nadon wrote:
>>> The srcipt runs 'make dist' to create the tarball. We don't have to prompt
>>> the user for the tar name, the version number or the section name.
>>
>> Should we 'make distcheck' instead?
>
> Excellent question. I have considered that. My reasons were not very
> strong:
> ...
> Let's see how it goes with other. I have never tried it. I am not really
> against it. It could be optional too.
Yeah, your reasons above are valid. How about a --distcheck option to toggle on this behavior?
</PRE>
</BLOCKQUOTE>
Done.
<BLOCKQUOTE TYPE=CITE>
<PRE>
>
>>
>>> Interface
>>> ---------
>>> Usage: publish.sh [options] section[/module]...
>>>
>>> Section:
>>> app|data|doc|driver|font|lib|mesa|proto|util|xcb|
>>> xkeyboard-config|xserver
>>
>> I would prefer passing in paths to my local git checkouts over section/module.
>> You should still be able to do the same -<version> foo by checking if the argument
>> is a dir, if not, chop off the -* and check again.
>
> Sorry I don't get it. Can you give me an example?
$ git clone ssh://git.freedesktop.org/git/xorg/app/xedit
$ git clone ssh://git.freedesktop.org/git/xorg/lib/libX11
do some stuff in both
publish.sh libX11 xedit
or
publish.sh libX11-1.10.0 libX11-1.9.4 libX11-1.8.8 xedit
> An entry such as lib/private_libX11 will work. I just need "lib" to get
> the section and there should be
> either no subdir or only one subdir. I am basically following the module
> url:
>
> git://anongit.freedesktop.org/xorg/ ==> lib/libX11
> or git://anongit.freedesktop.org/xorg/ ==> xserver
>
> What would be the structure of your "local git checkouts"?
As above. I just dump them all into one directory. I rename font/util to font-util and util/macros to util-macros to avoid confusion. I also have multiple xserver-*/ dirs at common checkouts to avoid rebuilding when going between versions.
> Also keep in mind the section[/module] is a format used by build.sh and
> it follows the module url
You can get the module URL from git, so I don't think it's necessary to mirror that layout on the FS.
</PRE>
</BLOCKQUOTE>
Done.
<BLOCKQUOTE TYPE=CITE>
<PRE>
>> Why are we duplicating code between release.sh and publish.sh?
>
> That is something to decide. I aimed to have publish.sh be a superset of
> release.sh in order to have only a single release script.
>
>> Can we instead have publish.sh be a smart wrapper around release.sh.
>
> I used release.sh as a functional spec and used some of the code.
> Calling a script within a script introduces multiple points of failure
> and a lot of additional tests. The odds of a change done in release.sh
> and be tested from publish.sh are next to nil.
> Returning information, sharing variables, error checking, user messages
> style and consistency are all more difficult.
> With the assumption that we have a single script (need to revamp the
> wiki), the internal implementation does not matter much, so as long as
> it is maintainable.
>
> I also copied the structure of build.sh (which early on I thought I
> could call). The only script being called is update_moduleset.sh which
> has already given trouble with the readlink issue (still to be solved).
Ok, if this is the case, I'd like to see this new script replace release.sh so we don't have duplicated functionality. It seems like this should be able to completely replace release.sh with some minor tweaks (like this following one).
</PRE>
</BLOCKQUOTE>
Done.
<BLOCKQUOTE TYPE=CITE>
<PRE>
>> Alan also sent out a release.sh patch (which I reviewed and provided a followup for)
>> which does some of the same "intelligent" aspects but for the current module.
>> I would like to either see both of these exist together or update publish.sh to support "."
</PRE>
</BLOCKQUOTE>
Done. It can also be given any valid path, absolute or relative to the script invocation directory.
<BLOCKQUOTE TYPE=CITE>
<PRE>
>
> The thought had crossed my mind, given the existing working habits. I
> was waiting for comments on that.
> I don't have any objection.
Thanks,
Jeremy
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>