On Mon, Aug 7, 2017 at 3:17 AM, Ben Coman <b...@openinworld.com> wrote:
>
>
> On Mon, Aug 7, 2017 at 12:25 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>>
>> On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <b...@openinworld.com> wrote:
>>
>>> On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito <
>>> guillermopol...@gmail.com> wrote:
>>>
>>>> About tagging... It looks super ackward to me to tag EVERY commit with
>>>> "build information".
>>>>
>>>
>>> I'm not sure which comment your responding to,
>>>
>>
>> yours :P. Yes, too early, I did not want to properly quote...
>>
>>
>>> and not sure what you mean by "build information",
>>>
>>
>> In this particular case I mean build number.
>>
>> but obviously someone may do several commits before doing a pull request,
>>> as they work through developing and testing a fix for an Issue. Its only
>>> the successful builds that are uploaded to files.pharo.org that are
>>> important to tag.
>>>
>>
>> But then, why not just going through the files in files.pharo.org and
>> get the corresponding hash from there (since they have the hash they
>> correspond to)? I do not see the practical usecase. It's just redundance,
>> no?
>>
>>
>>> Building does not mean releasing... I prefer the other way around: we
>>>> tag builds with commit information. Like that we know how to reproduce the
>>>> build.
>>>>
>>>> I'm ok with tagging build artifacts by explicitly saying "this is BUILD
>>>> #X", which is ~= from "this is RELEASE #X".
>>>>
>>>
>>> I'd imagine that tagging a commit as BUILD#X would be done as part of
>>> the CI immediately before the upload to files.pharo.org.
>>>
>>
>> That's what I wanto to avoid. Why is that required? The generated file
>> already has a pointer to the git commit it was generated from. Why do we
>> need the backpointer from git to the build?
>>
>
> So should PharoLauncher attach a datestamp to each entity?
> There needs to be something visible that a human can sort by.
> I guess this is an interim solution until PharoLauncher is made to work
> with Iceberg, but we need something working until then.
>
But PharoLauncher does not access commits. It never did. I think it gets
all information from the file server and the naming schema of files...
>
>
>>
>>
>>>
>>>
>>>> Moreover, before we needed to store ALL versions of the image because
>>>> that was the way we versionned the system. Now, every commit in the
>>>> #development branch should be buildable (delta some bugs of course ;)).
>>>> This means that we can rebuild all images by just iterating the git history
>>>> and building from scratch.
>>>>
>>>
>>> I don't understand why you'd need to iterate git history.
>>> Shouldn't you be able to rebuild an image from a single git commit?
>>>
>>
>> Yes you are. I meant in here that "if you want to rebuild all images from
>> files.pharo.org" you can walk all commits.
>>
>
> got it.
>
>
>>
>>
>>>
>>>
>>>> No need to store all images.
>>>>
>>>
>>> Do you mean on files.pharo.com?
>>> That might be a good later goal, but for now these resultant images are
>>> useful to work with PharoLauncher without expending effort on redeveloping
>>> that to also rebuild images on the fly.
>>>
>>>
>>
>> Yeah, I did not mean that we have to change it. But we have to keep in
>> mind that before files.pharo.org was used for versioning purposes but in
>> a process where we are bootstrapping from sources, the intermediate
>> generated images are build artifacts and are just a "cache".
>>
>> I know the launcher depends on it right now, but does it make sense that
>> it provides access to every alpha image
>>
>
> It may make sense when someone wants to bisect an Issue to determine when
> a defect was introduced.
> How does the time downloading ten images compare to bootstrapping ten
> images?
>
True true. That's why I say it's a cache :). While this is cheap enough to
have all builds stored, I'm ok with it.
>
>
>
>>
>>
>>> Pharo${IMAGE_KIND}-7.0.0-arch.32bit.sha.${HASH}.build.${BUIL
>>>>> D_NUMBER}.zip
>>>>>
>>>>
>>> +1 to Torsten's suggestion to put the BUILD_NUMBER first, since it is
>>> more sortable than HASH.
>>>
>>
>> Ok, that's easily doable :)
>>
>> https://github.com/pharo-project/pharo/pull/185/files#diff-b
>> f8112f4242808a7d70517e28088f72b
>>
>>
>>> By "arch", do you mean Win/Linux/Mac? Or were labelling the bit-ness
>>> field?
>>>
>>
>> bitness. Images are portable between operating systems but not between
>> 32&64 bit vms.
>>
>>
>>> Also, is it important to prepend these with the numbers with "build."
>>> and "sha." fieldname strings? This bulks out the name increases the chance
>>> some interface needs to mangle the name to fit into a thin column.
>>>
>>
>> I like that they make the metadata more explicit. Otherwise we will start
>> having strange scripts that have magic numbers here and there. At least
>> like this we can read the file name and identify what is each field. I
>> prefer to pay some extra bytes in filenames...
>>
>> About column names in UIs.... That's a UI problem. I'd not design the
>> filename of our build artifacts because of a UI...
>>
>
> fair enough.
>
>
>>
>>
>>>
>>>
>>> While we are discussion version naming (and I ask this from a position
>>> of ignorance)
>>> could you discuss with your team, without insider knowledge, how do we
>>> distinguish between the released 7.0.0 and all the 7.0.0 development builds
>>> heading towards that release?
>>> Can we add something to distinguish the development phase
>>> i.e. alpha/beta/rc/release (which coincidentally sort well with build
>>> numbers.)
>>>
>>> Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-alpha.${BUILD_NUMBER}.${HASH}.zip
>>> Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-beta.${BUILD_NUMBER}.${HASH}.zip
>>> Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-rc.${BUILD_NUMBER}.${HASH}.zip
>>> Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-release.${BUILD_NUMBER}.${HASH}.
>>> zip
>>>
>>> beta might be the defined point to ask applications to test-port to the
>>> new version, this perhaps being the optimum point to get fixes into the the
>>> next release.
>>>
>>
>>> or if you don't want to be that sophisticated, maybe just phases dev/rel
>>>
>>
>> I like that. The only thing is that right now what is "alpha" version is
>> managed in the file server as "latest". That will otherwise break zeroconf
>> scripts that depend on that.
>>
>> I'd say every build in development is alpha so far. At some point we will
>> move to beta. Releases and release candidates should be managed explicitly
>> (like there is someone that will decide "this is a release and I'll tag it
>> explicitly like it").
>>
>>
>>>
>>> or for a more continuous release process, maybe '#' for the patch
>>> number...
>>> Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-${BUILD_NUMBER}.${HASH}.zip
>>> (since '#' sorts before '0')
>>>
>>
>> I did not get this one.
>>
>
> I was thinking something like below, but perhaps it gets too awkward after
> 7.0.0.
>
> Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70001.sha.${HASH}.zip
> Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70002.sha.${HASH}.zip
> ...
> Pharo-${IMAGE_KIND}${BITNESS}-7.0.#-.build.70639.sha.${HASH}.zip
> Pharo-${IMAGE_KIND}${BITNESS}-7.0.0-.build.70640.sha.${HASH}.zip
> Pharo-${IMAGE_KIND}${BITNESS}-7.0.1-.build.70641.sha.${HASH}.zip
> Pharo-${IMAGE_KIND}${BITNESS}-7.0.2-.build.70642.sha.${HASH}.zip
>
Ah! I understand now. You want to tag with a # the latest build.
>
>
> cheers -ben
>
--
Guille Polito
Research Engineer
French National Center for Scientific Research - *http://www.cnrs.fr*
<http://www.cnrs.fr>
*Web:* *http://guillep.github.io* <http://guillep.github.io>
*Phone: *+33 06 52 70 66 13
