[Pharo-dev] PharoLauncher - uninformative Pharo7 template names

Ben Coman btc at openinworld.com
Mon Aug 7 20:34:50 EDT 2017


On Mon, Aug 7, 2017 at 7:32 PM, Guillermo Polito <guillermopolito at gmail.com>
wrote:

>
>
> On Mon, Aug 7, 2017 at 3:17 AM, Ben Coman <btc at openinworld.com> wrote:
>
>>
>>
>> On Mon, Aug 7, 2017 at 12:25 AM, Guillermo Polito <
>> guillermopolito at gmail.com> wrote:
>>
>>>
>>> On Sun, Aug 6, 2017 at 5:46 PM, Ben Coman <btc at openinworld.com> wrote:
>>>
>>>> On Sun, Aug 6, 2017 at 3:45 PM, Guillermo Polito <
>>>> guillermopolito at 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...
>

Yes. Which is why we need either:
* the filenames on the file server to include a build number or date
* PharoLauncher modified to get the date from the directory info to mix
into its displayed name

which is preferable?

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170808/f65d0311/attachment.html>


More information about the Pharo-dev mailing list