[csw-pkgsubmissions] newpkgs cswutils

[Philip Brown]

On 1/12/11, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
> No dia 12 de Janeiro de 2011 18:26, Philip Brown <phil at bolthole.com>
> escreveu:
>>...
>> Also not nice:  there are 6 different versions of them floating around?!!
>>
>> $ find . -name 'submitpkg'
>> ./v2-uwatch2/bin/submitpkg
>> ./v2-noexternals/bin/submitpkg
>> ./v2-bwalton/bin/submitpkg
>> ./v2-sqlite/bin/submitpkg
>> ./v2/bin/submitpkg
>> ./v2-fortran/bin/submitpkg
>>
>>
>> Let's clean up this mess, please?
>
> Please do not use loaded language such as 'mess' without understanding
> the workflow.
>

fair enough... Although I think that that "messy" is "messy", whether
or not one understands the workflow or not. A "valid, useful
workflow", can still be a "messy" workflow :D




> The reason why you see different versions of the same file is because
> you're looking at a number of branches of gar code, with which
> submitpkg shares the code repository.  The package build downloads
> files from a specific place in a specific subversion repository, and
> that place is one specific branch in subversion, namely v2.
>
> If you have a specific workflow/code reorganization in mind, please describe
> it.


well, something that I think would be "cleaner", if you'll pardon the
term :) would be that by default, people who check out the source
tree, only see one thing for gar.
There are multiple reasons why I think this would be good. One of
which being, that
it makes things way too confusing for people who are trying to
understand what current gar does.

I guess part of the problem is that gar does not follow the standards
of "the rest of our repository".
There is no "main" or "trunk" directory. (and so, similarly, there is
no "braches" dir)
Everything is just dumped into
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/gar

It would also be nice, if, when people are playing with their own
experimental versions.. they work with it, and then *remove* it when
done?
Isnt that supposed to be the final goal?
Play with something, experiment.. and then merge back in?


There are multiple ways that this MIGHT be handled. Unfortunately, the
little I know about svn, hints that svn makes this difficult. no
"private" branches, etc.

Which also suggests that 'best" method may be to push for the once
discussed proper standalone implementation.
Turn $SVNROOT/gar/mgar/FOO, into a properly released set of files under
(  ?  /opt/csw/libexec/gar ? )

>From what I have picked up reading the lists, seems like "the current
gar maintainers" have resisted this, because it's easier to just run
things from the source tree, rather than make proper "releases".
Certainly it's easier for them. But it makes things more difficult for
"the customers" -- ie: other maintainers.

There are benefits to people who are not gar-maintainers, to having
software with proper releases.

For one thing, we could install a fixed version package on the build
machines, and there would be no more of this,

"why doesnt my package build???"
"Oh, you need to svn update, in this part of our tree that has nothing
to do with your own area of SVN, so you can catch up with 'the latest
official version'".

If regular maintainers need to stay with 'the latest official
version', then lets have 'the official version' of the scripts, etc.
always properly installed on the build machines, in a single standard
location, rather than making people have to locally update their own
tree at random times?