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

[Gaetan Nadon]

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?

Done.

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

Done.

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

Done.

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

Done. It can also be given any valid path, absolute or relative to the
script invocation directory.

> > 
> > 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/20111111/e7ceb777/attachment.htm>
-------------- 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/20111111/e7ceb777/attachment.pgp>