[PATCH modular] Publish.sh: batch release and autotagging of modules

Gaetan Nadon memsize at videotron.ca
Fri Oct 7 18:34:07 PDT 2011


On Fri, 2011-10-07 at 13:28 -0700, Jeremy Huddleston wrote:

> >> 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?

Implemented in patch v2
Due to compiling, there is noise on stderr. I allowed stderr to display
in the user feddback in case make dist would fail.
I could change the code to ignore stderr.

Not terribly important, but note that in Makefile:

distcheck: dist

The tarballs you release always comes from 'make dist". The target
distcheck is executed after in an out-of-source tree and the tarballs it
creates are removed after the target is done.

Running distcheck provides an out-of-source tree build but does not
produce "better" tarballs. It's good to have as it is easy to forget
running it.

> 
> 
> > 
> >> 
> >>> 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

I get it. Should be doable. Scheduled for v3.

> 
> > 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.

When the script is invoked from a git module yes. However it needs some
user input (or make some assumptions) as to how to navigate the tree in
order to cd to the git modules. The more "arbitrary" the source tree is,
the more complex the navigation will be. You have provided a "source
tree structure" that is different (a single level subdir structure)
which I assume for now is workable. For v3. Others may have yet a
different source tree structure.

> 
> >> 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).

Ok. Probably patch v4.

> 
> >> 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 "."
> > 
> > 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
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20111007/ba78b9f4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20111007/ba78b9f4/attachment-0001.pgp>


More information about the xorg-devel mailing list