thinking about process, wondering if we can easily do better

[Bill Barry]

Matt Mackall wrote:
> On Tue, 2009-01-06 at 10:10 -0700, Bill Barry wrote:
>   
>> so... I was thinking about the way we are doing things in house here and 
>> I was wondering if there would be a better way to do this. Currently we 
>> have a process for getting our skin packages (zip files) for our 
>> application up to date in our working copies. That is to say currently 
>> we are versioning the zip files themselves. Currently we do the following:
>> "Programmer 1" - let's call her Sally
>>
>> Sally would not consider herself a programmer; she would call herself a 
>> skin designer. Mostly her work is:
>> create a skin by manually creating .css files and html template files 
>> with the occasional jpg, etc
>> package up the skin into a zip file so that it can be used by the installer
>> make sure the skin installs (a special file called the manifest needs to 
>> be correct)
>> put the skin zip file in a special folder, possibly overwritting 
>> pre-existing skin
>> remove old skins
>> call hg addremove, hg commit, and hg push (possibly hg pull, hg update, 
>> and maybe hg merge somewhere)
>>
>> on the other side:
>> "Programmer 2" - let's call him Bill
>> "Programmer 3" - let's call him Fred
>>
>> Bill and Fred make actual code changes to the application and store the 
>> source for it in their repositories. All 3 pull and push to the same 
>> central repository location and see Sally's changes as opaque zip files. 
>> Every once in a while Bill or Fred need to see the actual change made in 
>> Sally's zip files; to do so they need to get both versions, extract them 
>> and then manually compare them.
>>     
>
> If you're going to fiddle with your process, why not make the zip files
> build products and check in the -actual source- instead? Sally would
> probably be just as happy to type 'make' as 'zip', which might build a
> manifest for her too.
>   
The zip files are created by the application. Sally starts with a copy 
of the application itself and builds the skin using it. When complete 
she uses an option we have built into the application to export the 
skin. Sally never individually knowingly works with the actual source 
files (and frankly doesn't care). Convincing her to manually extract the 
files so that we can build them on the other side isn't worth the effort.
> ps: Your example is a little too real. Sally might have considered a
> career in programming if there wasn't a pervasive gender bias in the
> field held over from the 50s. The very least we can do is apply some
> affirmative action to our examples.
>   
To think I changed this person's name and gender (and Fred's actually) 
in order to make the process less about the people and more about the 
actions. The point was that by my standards, Sally is a programmer 
because she is changing stuff and committing to our codebase. Sally went 
to school to be a graphic designer and never wants to be called a 
programmer.


We also have a different group of developers who are working with 
PowerBuilder in a different repository where they commit the actual 
powerbuilder object files (which fundamentally are the same things as 
zip files). One additional frustration there is that these pbo files 
actually take considerable time to generate from the textfiles-in-folder 
versions of themselves (in addition to its source code, a pbo contains 
compiled java bytecode for all source).

In the zip file situation, it would be nice for the repos that have the 
encode/decode filter enabled to work with zip files, but not required 
(just not worth the effort of getting people to change from just storing 
the zip files there). In the pbo situation it is absolutely a 
requirement to be able to work with the pbo files instead of the text 
files (altogether it takes over an hour to generate them all and that 
would be done every build if they were just using the text files). In 
order to get them to switch, we would need to ensure that the filters 
don't rebuild the pbo files unless the contents changed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090106/f984d09f/attachment.htm