Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Jed Brown]

I would prefer this mailing list or GitLab issues because they are

1. genuinely open to external participants,
2. more async-friendly for those in different timezones and folks with young 
kids, and
3. searchable and externally linkable (e.g., from merge requests and issues)

If we need synchronous breakouts, we could do so, but there should be a summary 
back for those who couldn't participate synchronously.

Barry Smith  writes:

>I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization 
> but to have that discussion we need to discuss what tool to use for that 
> discussion. 
>
>So this discussion is not about PETSc 4.0, please don't discuss it here.
>
>What do people recommend to use for the discussion
>
>   * dedicated mailing list
>   * slack channel(s)
>   * zulip channel(s)
>   * something else?
>
>   I'd like a single tool that anyone can join at any time, see the full 
> history, can attach files, search, not cost more money the we are already 
> paying, etc.
>
>   I expect this discussion to take maybe a week and then the actual 
> discussion to take on the order of two months.
>
>Thanks
>
>  Barry
>
>   

Re: [petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Junchao Zhang]

A dedicated mailing list has all these functionalities and is easier to see
discussion threads.
--Junchao Zhang


On Thu, Jun 18, 2020 at 9:27 PM Barry Smith  wrote:

>
>I'd like to start a discussion of PETSc 4.0 aka the Grand
> Refactorization but to have that discussion we need to discuss what tool to
> use for that discussion.
>
>So this discussion is not about PETSc 4.0, please don't discuss it here.
>
>What do people recommend to use for the discussion
>
>   * dedicated mailing list
>   * slack channel(s)
>   * zulip channel(s)
>   * something else?
>
>   I'd like a single tool that anyone can join at any time, see the full
> history, can attach files, search, not cost more money the we are already
> paying, etc.
>
>   I expect this discussion to take maybe a week and then the actual
> discussion to take on the order of two months.
>
>Thanks
>
>  Barry
>
>

Re: [petsc-dev] bash scripts to make PETSc development easier, less recompiles, less cut and pastes

[Jed Brown]

Barry Smith  writes:

>   Nice, I didn't know about that alternative, I'll check it out. 

AFAIK, there is still no push option to run a pipeline.  There's an
option ci.skip if you're configured to run by default.  If developers
set ci.skip as a default push option, we could re-enable the default
case.

>> On Jun 18, 2020, at 9:21 PM, Jed Brown  wrote:
>> 
>> Cool!  Note that you can do things like this without going through the API
>> 
>>  git push -o merge_request.create -o merge_request.target=maint

Re: [petsc-dev] bash scripts to make PETSc development easier, less recompiles, less cut and pastes

[Barry Smith]

  Nice, I didn't know about that alternative, I'll check it out. 

> On Jun 18, 2020, at 9:21 PM, Jed Brown  wrote:
> 
> Cool!  Note that you can do things like this without going through the API
> 
>  git push -o merge_request.create -o merge_request.target=maint
> 
> https://docs.gitlab.com/ce/user/project/push_options.html#push-options-for-merge-requests
>  
> 
> 
> Barry Smith mailto:bsm...@petsc.dev>> writes:
> 
>>   A long time ago Oana asked me how come when you switched back to a 
>> previously built branch it sometimes had to recompile the libraries and 
>> could it be smart enough to use touch in some way to not have to recompile. 
>> So I made a bash script that automatically changed PETSC_ARCH with branch 
>> changes and recovered the built libraries; thus making changing branches 
>> become much less painful, took at long time to get it right :(
>> 
>>   Then I went a bit crazy and added support for submitting pipelines without 
>> cut and pasting and going to GitLab, checking on pipelines without going to 
>> Gitlab, start MR without cut and paste or manually going to Gitlab and 
>> automatically using the maint branch when the submitted branch was off maint 
>> instead of master (a mistake I make all the time). Plus a bunch of other 
>> things. 
>> 
>>   One benefit of this is I now do all my initial testing BEFORE making a MR. 
>> 
>>   Anyways the scripts are horribly crude, but functional, with even a little 
>> error checking. Even if you don't like the scripts you might take parts of 
>> them that run pipelines without going to Gitlab etc, modify them and use 
>> them standalone. Feel free to MR alternative scripts in the repository that 
>> we also share.
>> 
>>   The software can be downloaded with 
>> 
>>   git clone gitlab.com :petsc/petscgitbash 
>> >
>> 
>>  Barry

[petsc-dev] Prediscusion of appropriate communication tool for discussion of PETSc 4 aka the Grand Refactorization

[Barry Smith]

   I'd like to start a discussion of PETSc 4.0 aka the Grand Refactorization 
but to have that discussion we need to discuss what tool to use for that 
discussion. 

   So this discussion is not about PETSc 4.0, please don't discuss it here.

   What do people recommend to use for the discussion

  * dedicated mailing list
  * slack channel(s)
  * zulip channel(s)
  * something else?

  I'd like a single tool that anyone can join at any time, see the full 
history, can attach files, search, not cost more money the we are already 
paying, etc.

  I expect this discussion to take maybe a week and then the actual discussion 
to take on the order of two months.

   Thanks

 Barry

  

Re: [petsc-dev] bash scripts to make PETSc development easier, less recompiles, less cut and pastes

[Jed Brown]

Cool!  Note that you can do things like this without going through the API

  git push -o merge_request.create -o merge_request.target=maint

https://docs.gitlab.com/ce/user/project/push_options.html#push-options-for-merge-requests

Barry Smith  writes:

>A long time ago Oana asked me how come when you switched back to a 
> previously built branch it sometimes had to recompile the libraries and could 
> it be smart enough to use touch in some way to not have to recompile. So I 
> made a bash script that automatically changed PETSC_ARCH with branch changes 
> and recovered the built libraries; thus making changing branches become much 
> less painful, took at long time to get it right :(
>
>Then I went a bit crazy and added support for submitting pipelines without 
> cut and pasting and going to GitLab, checking on pipelines without going to 
> Gitlab, start MR without cut and paste or manually going to Gitlab and 
> automatically using the maint branch when the submitted branch was off maint 
> instead of master (a mistake I make all the time). Plus a bunch of other 
> things. 
>
>One benefit of this is I now do all my initial testing BEFORE making a MR. 
>
>Anyways the scripts are horribly crude, but functional, with even a little 
> error checking. Even if you don't like the scripts you might take parts of 
> them that run pipelines without going to Gitlab etc, modify them and use them 
> standalone. Feel free to MR alternative scripts in the repository that we 
> also share.
>
>The software can be downloaded with 
>
>git clone gitlab.com:petsc/petscgitbash 
>
>   Barry

[petsc-dev] bash scripts to make PETSc development easier, less recompiles, less cut and pastes

[Barry Smith]

   A long time ago Oana asked me how come when you switched back to a 
previously built branch it sometimes had to recompile the libraries and could 
it be smart enough to use touch in some way to not have to recompile. So I made 
a bash script that automatically changed PETSC_ARCH with branch changes and 
recovered the built libraries; thus making changing branches become much less 
painful, took at long time to get it right :(

   Then I went a bit crazy and added support for submitting pipelines without 
cut and pasting and going to GitLab, checking on pipelines without going to 
Gitlab, start MR without cut and paste or manually going to Gitlab and 
automatically using the maint branch when the submitted branch was off maint 
instead of master (a mistake I make all the time). Plus a bunch of other 
things. 

   One benefit of this is I now do all my initial testing BEFORE making a MR. 

   Anyways the scripts are horribly crude, but functional, with even a little 
error checking. Even if you don't like the scripts you might take parts of them 
that run pipelines without going to Gitlab etc, modify them and use them 
standalone. Feel free to MR alternative scripts in the repository that we also 
share.

   The software can be downloaded with 

   git clone gitlab.com:petsc/petscgitbash 

  Barry