Hi!
Kyle Meyer writes:
> Hi Maxim,
>
> Maxim Cournoyer writes:
>
>> Another easy option is to retrieve the Message-ID of any message in the
>> series (via the source HTML of the mail archives, or directly from the
>> mail headers if you have the mail locally), and then use B4, Linux
>> style
Hi Maxim,
Maxim Cournoyer writes:
> Another easy option is to retrieve the Message-ID of any message in the
> series (via the source HTML of the mail archives, or directly from the
> mail headers if you have the mail locally), and then use B4, Linux
> style [0]. Example: suppose I wanted to
Hi Oleg,
On Thu, 11 Jan 2024 at 19:56, Sharlatan Hellseher wrote:
> I am happy to have been granted commit access
Cool! Welcome.
> If anyone has a good patch review workflow using Emacs, Gnus, and Magit,
> I would appreciate it ;-)
Well, nothing more than what had been already
Hi,
Efraim Flashner writes:
> On Fri, Jan 12, 2024 at 05:21:51PM +0100, Clément Lassieur wrote:
>> On Thu, Jan 11 2024, Sharlatan Hellseher wrote:
>>
>> > Hi Guix!
>> >
>> > I am happy to have been granted commit access and I am ready to help
>
> Just my 2 cents, I imagine every person here has their own workflow.
I personally don't have any yet (and I assume I'm not the only one) so
I'm really thankful for your snippet.
Cheers Bost
On Thu, Jan 11, 2024 at 07:56 PM, Sharlatan Hellseher wrote:
>
> Hi Guix!
>
> I am happy to have been granted commit access and I am ready to help
> review pending issues and prepare queued packages for GNU packages in
> astronomy. I would like to concentrate on the packages c
On Fri, Jan 12, 2024 at 05:21:51PM +0100, Clément Lassieur wrote:
> On Thu, Jan 11 2024, Sharlatan Hellseher wrote:
>
> > Hi Guix!
> >
> > I am happy to have been granted commit access and I am ready to help
> > review pending issues and prepare queued packages for
On Thu, Jan 11 2024, Sharlatan Hellseher wrote:
> Hi Guix!
>
> I am happy to have been granted commit access and I am ready to help
> review pending issues and prepare queued packages for GNU packages in
> astronomy. I would like to concentrate on the packages covered by the
>
Hi Guix!
I am happy to have been granted commit access and I am ready to help
review pending issues and prepare queued packages for GNU packages in
astronomy. I would like to concentrate on the packages covered by the
Go, Lisp, Python, and Science teams.
I would like to thank the Guix team
good usertag for the guix
> user.
>
> Once QA has picked up that the reviewed-looks-good usertag is present,
> it'll display a dark green status and the issue will appear at the top
> of the /patches page. My hope here is that people with commit access can
> prioritise merging p
Christopher Baines writes:
> I've been reviewing the list of ideas on and around QA ([1]) recently,
> and got thinking again about how to support people without commit access
> reviewing patches. Obviously you don't need commit access to review
> patches, but where I think we need
Hi,
There are only two hard things in Computer Science…
On Thu, 07 Sep 2023 at 09:19, Vagrant Cascadian wrote:
>>> Discussing about idea, would it be possible that the QA infrastructure
>>> automatically send a message to Debbugs for tagging? For example, the
>>> usertag ’qa-ok’ or whatever
On 2023-09-06, Maxim Cournoyer wrote:
> Simon Tournier writes:
>> On Wed, 06 Sep 2023 at 16:55, Christopher Baines wrote:
>>
>>> Once we know what tags to use, I can have the QA frontpage do something
>>> similar to the "Mark as moreinfo" links, so it's easy to just click a
>>> button then send
Hi,
On Wed, 06 Sep 2023 at 22:47, Maxim Cournoyer wrote:
>> Well, using emacs-debbugs and then
>>
>> C-u M-x debbugs-gnu-usertags guix-patches RET
>>
>> the list of usertags is:
>>
>> guix-patches for-core-updates
>> guix-patches reviewed-looks-good
>>
>> And if instead of
Hi Simon, Chris,
Simon Tournier writes:
> Hi Chris, all,
>
> On Wed, 06 Sep 2023 at 16:55, Christopher Baines wrote:
>
>> Once we know what tags to use, I can have the QA frontpage do something
>> similar to the "Mark as moreinfo" links, so it's easy to just click a
>> button then send the
Hi Chris, all,
On Wed, 06 Sep 2023 at 16:55, Christopher Baines wrote:
> Once we know what tags to use, I can have the QA frontpage do something
> similar to the "Mark as moreinfo" links, so it's easy to just click a
> button then send the email to change the state of a issue.
That’s cool!
.
Well, I think we are not there. Maybe I am missing the proposal about
levels. Somehow, I think there is not enough regular contributors for
having kind of levels. Well, that’s not Debian. ;-)
Aside that considering how Savannah is configured today, commit access
are all or nothing.
Cheers,
simon
Hi Chris,
On Wed, Sep 6, 2023 at 11:39 AM Christopher Baines wrote:
>
> I don't want to make reviewing changes more difficult, and I think
> setting up more people with commit access and continuing the trend that
> it's mostly people with commit access that review changes wo
ributors
> commit rights but require that they obtain approval for some steps. It
> can be done on a trust basis.
It's an idea, although one I'd discount based on how many breaking
changes (including ones with wide impact like breaking guix pull) happen
with the current criteria for granting commit
Hi Chris,
On Wed, Sep 6, 2023 at 9:47 AM Christopher Baines wrote:
>
> Maybe we can use debbugs tags for this?
Instead of pushing people into reviews and then again making the same
committers a bottleneck, I would offer some entry-level contributors
commit rights but require that they obtain
Hey!
I've been reviewing the list of ideas on and around QA ([1]) recently,
and got thinking again about how to support people without commit access
reviewing patches. Obviously you don't need commit access to review
patches, but where I think we need some process is how to expedite
someone
nks for granting me commit access. I'm looking forward to
> helping out with patch review, with a particular focus on moving patches
> along for the Python team. I also intend to continue contributing more
> packages, updates, and improvements. Thanks again for granting me the
> priv
Felicidades!
--- Original Message ---
On Tuesday, May 16th, 2023 at 2:28 AM, jgart wrote:
> Hi Guixers,
>
> Thanks for granting me commit access. I'm looking forward to helping out with
> patch review, with a
> particular focus on moving patches along for the Pyth
"jgart" writes:
> Hi Guixers,
>
> Thanks for granting me commit access. I'm looking forward to helping out with
> patch review, with a
> particular focus on moving patches along for the Python team.
>
> I also intend to continue contributing more package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Guixers,
Thanks for granting me commit access. I'm looking forward to helping out with
patch review, with a
particular focus on moving patches along for the Python team.
I also intend to continue contributing more packages, updates
Heya,
On Tue Nov 15, 2022 at 8:23 PM GMT, wrote:
> There must be very strict trust requirements for commit access
> or FLOSS will become vulnerable to "mistakes" with plausible denial,
> like over-eagerness to help, oops, introduced by anti-FLOSS grinches.
There are defin
aren'. I
> thoroughly appreciated their advice, both on the technical as well as
> on the human level.
>
> Now I learned that 'unmatched-paren' would like to request commit
> access to the Guix repository, but they were humbled by their own
> uncertainty on how to illustrate their value
Hi,
TL;DR: IMO commit access is too dangerous to grant on the basis of
appreciating help, and/or workflow convenience.
Trusted committers are defenders of FLOSS.
There must be very strict trust requirements for commit access
or FLOSS will become vulnerable to "mistakes" with plausi
as
on the human level.
Now I learned that 'unmatched-paren' would like to request commit
access to the Guix repository, but they were humbled by their own
uncertainty on how to illustrate their value. I then offered to write
this letter.
Please consider 'unmatched-paren' for commit access. Thank you
zimoun writes:
[...]
>> * Over all for me debbugs.el needs a much more "noops"-friendly
>> interface
>
> Well, I think ’public-inbox’ could help. An instance is:
>
> https://yhetil.org/guix-patches/
>
> where using lei, you can filter and receive to your inbox the patches.
> For
Hi Hartmut,
On Mon, 20 Jun 2022 at 14:53, Hartmut Goebel
wrote:
> my system is set up to emacs could send out mails.
Well, if you are already using Emacs, the Emacs front-end is not the
nicest interface but does part of the job. I have this:
--8<---cut
Hi,
here are my reasons for reviewing patches very very rarely-
Basically I share Brian Cully's experiences. I'm using Thunderbird for
mail and my system is set up to emacs could send out mails.
I tried debbugs from time to time and for me it is disgusting:
* too complicated to get to the
>> Also, should we remove old/broken/unused/rarely-used packages from Guix?
>> In the past, I have packaged and contributed very niche packages which
>> probably no one else uses, and sometimes even I don't use anymore. But,
>> these packages continue to stay in Guix and add to the maintenance
> On 15 Jun 2022, at 09:15, Arun Isaac wrote:
>
> I would also like to raise a couple of more controversial suggestions:
>
> Should we restrict the set of packages that will be accepted into Guix?
> Currently, we accept practically any free software package into
> Guix. Should we limit the
Hi Simon,
zimoun writes:
> On Wed, 08 Jun 2022 at 11:30, Giovanni Biscuolo wrote:
>
>>> It reduces a bit the pressure on the committers, IMHO.
>>
>> It raises a bit the pressure on the maintainers, IMHO :-)
>
> What does it mean “maintainer” here?
Guix maintainers
> Maybe I miss something
Hi,
Arun Isaac skribis:
>> That’s why, I think the project should:
>>
>> 1. change the default branch of “git push” vs the default branch of
>> “guix pull”.
>>
>> 2. add a bit more of checkers on patch submission easing patch
>> review.
>
> I like and support both these ideas. Maybe, they
Hi,
> That’s why, I think the project should:
>
> 1. change the default branch of “git push” vs the default branch of
> “guix pull”.
>
> 2. add a bit more of checkers on patch submission easing patch
> review.
I like and support both these ideas. Maybe, they are even long overdue!
;-)
I
>>> Personally, I think nowadays this purpose is better fulfilled by
>>> good commit messages and git blame. Especially with an editor that makes
>>> it easy to use them to navigate through history (such as Emacs, but
>>> certainly others as well).
>>
>> Because these standards, it is easy to
Hello,
zimoun writes:
> Hi,
>
> On Sat, 11 Jun 2022 at 01:13, Thiago Jung Bauermann
> wrote:
>
>> But I do think it's one more source of “friction” for new contributors,
>> and one more thing for us to require that they get right.
>
> [...]
>
>> There's one in the GNU Coding Standards¹:
>
>
Hi,
On Wed, 08 Jun 2022 at 11:30, Giovanni Biscuolo wrote:
>> It reduces a bit the pressure on the committers, IMHO.
>
> It raises a bit the pressure on the maintainers, IMHO :-)
What does it mean “maintainer” here?
Maybe I miss something but I do not think the Guix maintainers play a
special
Hi,
On Sat, 11 Jun 2022 at 01:13, Thiago Jung Bauermann
wrote:
> But I do think it's one more source of “friction” for new contributors,
> and one more thing for us to require that they get right.
[...]
> There's one in the GNU Coding Standards¹:
[...]
> Personally, I think nowadays this
Hi Maxime
Maxime Devos writes:
> Giovanni Biscuolo schreef op ma 13-06-2022 om 11:34 [+0200]:
>> Maxime I have a question for you please: do you really think that in
>> the NixOS community
>
> Going by the Java example, yes, at least for some of the NixOS
> community. I've also seen this
Hi Giovanni,
Rather than any specific criticism of our workflow, my point was that
there are many little things to keep in mind when reviewing patches, and
this makes it demanding. I am pretty happy with Guix's rigorous coding
standards, and am not suggesting we abandon them.
Cheers! :-)
Arun
Giovanni Biscuolo schreef op ma 13-06-2022 om 11:34 [+0200]:
> Maxime I have a question for you please: do you really think that in
> the NixOS community
Going by the Java example, yes, at least for some of the NixOS
community. I've also seen this interpretation of reproducibility in
Clojure
Hi Maxime and all,
I'm so sorry this discussion is shifting to the actual meaning of
reproducible... especially since Maxime and many of us know it very well
I'm sure 95% of people I know would not understand me if I tell them
that their software should be reproducible, they should study a
Giovanni Biscuolo schreef op zo 12-06-2022 om 11:42 [+0200]:
> > or have packages with bundled dependencies (e.g. vendored jars).
>
> bundling binaries it's (is it?) for sure against the definition of a
> reproducible build, but what about bundling (source) dependencies?
>
> AFAIU not to bundle
Hi Ricardo and all,
following this discussion, it came to my mind a great presentation made
by Prot:
https://protesilaos.com/codelog/2021-12-21-emacsconf2021-freedom/
«How Emacs made me appreciate software freedom»
especially the "You can't be an Emacs tourist" part; I think that
similar
>> - We have strict conventions for commit messages. Our commit message
>> Changelog is a strange dated practice from the time before good
>> version control systems. I can live with it, but not everyone likes
>> it. Let's just say I've heard complaints about it offlist.
>
> AFAIU this is
> Date: Fri, 10 Jun 2022 14:27:44 +0200
> From: Giovanni Biscuolo
> To: Arun Isaac , Guix Devel
>
> Cc: GNU Guix maintainers
> Subject: Re: On commit access, patch review, and remaining healthy
> Message-ID: <87o7z0itz3@xelera.eu>
> Content-Ty
Hi,
Thiago Jung Bauermann skribis:
> The binutils-gdb repo has a Python script to generate a skeleton
> ChangeLog. I don't know how well it would work for Scheme patches:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=contrib/mklog.py;hb=HEAD
I believe the ‘etc/committer.scm’
Hello,
Giovanni Biscuolo writes:
> Arun Isaac writes:
>
>> - We have strict conventions for commit messages. Our commit message
>> Changelog is a strange dated practice from the time before good
>> version control systems. I can live with it, but not everyone likes
>> it. Let's just
Efraim Flashner writes:
[...]
> I'm not using emacs but I've found etc/committer.scm to be quite
> helpful, and I'll often rework parts of my workflow so that I can run
> :!etc/committer.scm from within vim.
uh thanks! I didn't know about committer.scm
please is there some documentation about
Efraim Flashner writes:
> On Fri, Jun 10, 2022 at 02:27:44PM +0200, Giovanni Biscuolo wrote:
[...]
>> I just hope this requirement is refraining people to contribute and to
>> review patches.
>
> I'll reword this as "I just hope this requirement isn't preventing
> people from contributing and
On Fri, Jun 10, 2022 at 02:27:44PM +0200, Giovanni Biscuolo wrote:
> Hi Arun,
>
> thank you for your detailed analysis!
>
<..snip..>
> I just hope this requirement is refraining people to contribute and to
> review patches.
I'll reword this as "I just hope this requirement isn't preventing
Giovanni Biscuolo schreef op vr 10-06-2022 om 14:27 [+0200]:
> > - Our synopses and descriptions are not casually copy-pasted from
> the
> > project website. We try to rewrite and improve on them if
> necessary.
>
> AFAIK similar requirements are "enforced" by all other distributions
They
Hi Arun,
thank you for your detailed analysis!
Arun Isaac writes:
[...]
> I meant that Guix has very high coding/packaging standards in the
> following senses:
>
> - We prefer to not bundle dependencies. Tracking out bundled
> dependencies, git submodules, etc. and figuring out how to
Hi Ludo,
> I can think of two ways to reassure committers:
>
> 1. By having clear reviewer check lists (you’d do that if you tick all
> the boxes, you’re fine);
>
> 2. By improving automation—nothing new here: if there was a tick that
> says “applies without merge conflicts” and
Hi Giovanni,
>> Guix has very high coding standards
>
> Do you think other software distribution do have less high coding
> standards?
I meant that Guix has very high coding/packaging standards in the
following senses:
- We prefer to not bundle dependencies. Tracking out bundled
Efraim Flashner skribis:
> On Tue, Jun 07, 2022 at 05:11:48PM +0200, Ludovic Courtès wrote:
[...]
>> The manual mentions the two web interfaces in addition to Emacs:
>>
>> https://guix.gnu.org/manual/devel/en/html_node/Debbugs-User-Interfaces.html
>>
>> Do you or would you use them to keep
On Tue, Jun 07, 2022 at 05:11:48PM +0200, Ludovic Courtès wrote:
> Hi Efraim,
>
> Efraim Flashner skribis:
>
> > As someone who has never used debbugs or emacs I find it daunting to try
> > to add it into my workflow. Currently I am subscribed to guix-patches
> > and I dump it into my
Hi Ludo'
Ludovic Courtès writes:
[...]
> OK, understood.
>
> I can think of two ways to reassure committers:
>
> 1. By having clear reviewer check lists (you’d do that if you tick all
> the boxes, you’re fine);
also a description of the review process used by you and other
experienced
Hi Arun,
Arun Isaac writes:
> Tooling aside, at least for me, I think there is an important emotional
> and psychological aspect to patch review. Maybe others share it too. So,
> I'll speak up.
Thanks a lot for your speak up!
> Guix has very high coding standards
Do you think other software
Hi Simon and all,
just a quick note about myself: I'm (still) not contributing with patch
reviews (and in general contributing too little) because in this period
of my "work life" I have little time, but things will hopefully
change...
IMHO the curent tooling is helpful and usable with a little
Hi Efraim,
Efraim Flashner skribis:
> As someone who has never used debbugs or emacs I find it daunting to try
> to add it into my workflow. Currently I am subscribed to guix-patches
> and I dump it into my guix-devel mailing list. I read my mail using mutt
> and will just pipe the patches to
On Fri, Jun 03, 2022 at 09:37:36PM +0200, Ludovic Courtès wrote:
> Hi,
>
> Brian Cully skribis:
>
> > Ludovic Courtès writes:
> >
> >> If you are using Emacs, does debbugs.el have
> >> shortcomings that make it a problem to review patches?
>
> To be clear, the question was directed
Hi,
On Mon, 06 Jun 2022 at 23:43, Ludovic Courtès wrote:
> I can think of two ways to reassure committers:
>
> 1. By having clear reviewer check lists (you’d do that if you tick all
> the boxes, you’re fine);
As pointed earlier by Arun in «Public guix offload server» [1], this
check
Hi Arun,
Arun Isaac skribis:
> Tooling aside, at least for me, I think there is an important emotional
> and psychological aspect to patch review. Maybe others share it too. So,
> I'll speak up.
Thanks a lot for speaking up, your feedback is invaluable.
I did consider that the whole process
Hi all,
Tooling aside, at least for me, I think there is an important emotional
and psychological aspect to patch review. Maybe others share it too. So,
I'll speak up.
Sometimes, I don't review and commit patches because I feel like I am
not qualified to review them, and am afraid of pushing a
Hi Ludo,
> Interesting. Since I already used Gnus before, I didn’t have much to
> learn when I started using debbugs.el.
>
> I know some people here use debbugs.el with other email clients like
> mu4e, so perhaps they can comment? We could add guidance in the
> manual.
Since some time mu4e
Hi,
Pier-Hugues Pellerin skribis:
> As a new-new Guix user, I did find the review process or the time it
> takes really long.
> Maybe I've tackle too complex updates[0], I don't know but I don't
> have a clear path how to push it.
Yeah. :-/
The long delays are mostly due to the lack of
Hi,
Brian Cully skribis:
> Ludovic Courtès writes:
>
>> If you are using Emacs, does debbugs.el have
>> shortcomings that make it a problem to review patches?
To be clear, the question was directed primarily at current committers.
> 1) It’d be nice if ‘M-x debbug-guix’ existed. I
o leadership positions to they can become committers
> and take part into this whole process.
I used to have commit access a long time ago, but I eventually gave it up. I
think the main reason was that I felt unconfortable having commit access to all
Guix repositories (I only wanted access
(info
"(guix)
Commit Access"):
[…] the project keeps moving forward because committers
not only push
their own awesome changes, but also offer some of their
time
_reviewing_ and pushing other people’s changes. As a
committer,
you’re welc
Ludovic Courtès writes:
If you are using Emacs, does debbugs.el have
shortcomings that make it a problem to review patches?
I’m new to debbugs in general, and Emacs’ debbugs mode in
particular. However, I have been using it to track the status on
some of my patches, or to just
where drive-by contributions are common
and long-term commitment is rare.)
• Review work is severely lacking. The manual reads (info "(guix)
Commit Access"):
[…] the project keeps moving forward because committers not only push
their own awesome changes, but also
Hi Vinicius,
Vinicius Monego 写道：
I was granted commit access to the repository [1] one hour
ago. I am
signing this mail with the key that will be used to sign
commits. My
public key can be found at [2] and [3].
Thanks, and welcome aboard! :-)
Toot,
T G-R
signature.asc
Description: PGP
Hi Vinicius,
Vinicius Monego writes:
> Hi everyone,
>
> I was granted commit access to the repository [1] one hour ago. I am
> signing this mail with the key that will be used to sign commits. My
> public key can be found at [2] and [3].
>
> Looking forward to wo
Hi everyone,
I was granted commit access to the repository [1] one hour ago. I am
signing this mail with the key that will be used to sign commits. My
public key can be found at [2] and [3].
Looking forward to working with all of you.
Vinicius
[1]
https://git.savannah.gnu.org/cgit/guix.git
Hi Raghav,
Raghav Gururajan skribis:
> I am happy to say that, I have been granted commit access. I would
> like to convey my thanks; to Tobias, Maxim, and Danny for vouching for
> me; and to guix maintainers for approving my application.
As I said on IRC: congrats, and welcome aboa
Happy to see a committer with this goal for a ubiquitous operating system. I
share the same goal, so I'm always thinking of how we can make everything Just
Work by default.
On Tuesday, April 13, 2021 9:28 AM, Raghav Gururajan
wrote:
> Hello Guix!
>
> I am happy to say that, I have been granted commit access. I would like to
> convey my thanks; to Tobias, Maxim, and Danny for vouching for me; and to
> guix maintainers for approving my application
Hello Guix!
I am happy to say that, I have been granted commit access. I would like
to convey my thanks; to Tobias, Maxim, and Danny for vouching for me;
and to guix maintainers for approving my application.
My long-term vision for guix is to make it an ubiquitous operating
system. I would
t;Hi,
>
>Peng Mei Yu skribis:
>
>> Can I apply for commit access to guix-artwork.git? I may make
>changes
>> to the Chinese translation and fix small bugs like this one:
>> https://issues.guix.gnu.org/45416.
>
>My understanding is that translations will now b
Hi,
Peng Mei Yu skribis:
> Can I apply for commit access to guix-artwork.git? I may make changes
> to the Chinese translation and fix small bugs like this one:
> https://issues.guix.gnu.org/45416.
My understanding is that translations will now be hosted elsewhere, with
the on-going
That's great news?
Do you have a link to the project?
How do you intend to receive contributions? Via a mailing list?
Cheers!
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Hello Guix,
I have taken up maintainership of the new home of Emacs-Guix on
Savannah. This message is signed with the key I will be using to sign
commits on Emacs-Guix.
Thank you!
John
signature.asc
Description: PGP signature
Hello,
Leo Prikler writes:
> Hello everyone,
>
> earlier today, I was granted commit access to the repository [1].
[...]
Welcome, Leo!
signature.asc
Description: PGP signature
Leo,
Leo Prikler 写道：
earlier today, I was granted commit access to the repository
[1]. This
message is signed with the key I will use for signing my
commits. It
should have the following info:
Excellent news. Welcome!
Kind regards,
T G-R
signature.asc
Description: PGP signature
Hello everyone,
earlier today, I was granted commit access to the repository [1]. This
message is signed with the key I will use for signing my commits. It
should have the following info:
pub rsa4096 2020-12-16 [SC]
ACC23BA059F7CCF408F043AD442A84B8C70E2F87
uid [ultimate] Leo
Hi,
Can I apply for commit access to guix-artwork.git? I may make changes
to the Chinese translation and fix small bugs like this one:
https://issues.guix.gnu.org/45416. Additional access to guix.git will
also be great. I won't make frequent commits.
My login name on Savannah is pmy. A PGP
Hi!
Miguel Ángel Arruga Vivas skribis:
> I'm happy to announce with this message my access to the repository and
> the key I'll use to sign the commits. This text has been signed with
> it, which has the following information and fingerprint:
>
> pub rsa3072 2020-09-09 [SC] [expires:
Miguel Ángel Arruga Vivas writes:
> Hello, everybody!
>
> I'm happy to announce with this message my access to the repository and
> the key I'll use to sign the commits. This text has been signed with
> it, which has the following information and fingerprint:
>
> pub rsa3072 2020-09-09 [SC]
On Sat, Oct 17, 2020 at 03:57:19PM +0200, Miguel Ángel Arruga Vivas wrote:
> Hello, everybody!
>
> I'm happy to announce with this message my access to the repository and
> the key I'll use to sign the commits. This text has been signed with
> it, which has the following information and
Miguel Ángel Arruga Vivas writes:
> Hello, everybody!
>
> I'm happy to announce with this message my access to the repository and
> the key I'll use to sign the commits. This text has been signed with
> it, which has the following information and fingerprint:
>
> pub rsa3072 2020-09-09 [SC]
Miguel,
Miguel Ángel Arruga Vivas 写道：
I'm happy to announce with this message my access to the
repository and
the key I'll use to sign the commits.
Welcome aboard! \o/
I downloaded your key from Savannah[0] and it all checks out.
Don't forget to update it next year :-)
Kind regards,
T
Hello, everybody!
I'm happy to announce with this message my access to the repository and
the key I'll use to sign the commits. This text has been signed with
it, which has the following information and fingerprint:
pub rsa3072 2020-09-09 [SC] [expires: 2022-01-01]
Hi Guix,
as some of you might know, I have been granted commit access to the
repository. I will be signing my commits with the following key:
sec rsa4096 2017-03-16 [SC]
E576BFB2CF6EB13DF57133B9E315A75846131564
uid [ultimate] Jakub Kadziolka
uid [ultimate] Jakub
Alex Vong skrev: (14 mars 2019 20:24:52 CET)
>Hello all,
>
>Laura Lazzati writes:
>
>> Hi Paul :)
>>
>>> I am looking forward to viewing the videos after I have cloned the
>>> repository as a member. Initially, I am not planning to make any
>>> changes, just to make an estimate of the total
Hi Alex!
> Hope it help :)
Thank you very much! I have it installed but did not have headsets by
that time, ended up recording them the hard way.
Regards :)
Laura
Hello all,
Laura Lazzati writes:
> Hi Paul :)
>
>> I am looking forward to viewing the videos after I have cloned the
>> repository as a member. Initially, I am not planning to make any
>> changes, just to make an estimate of the total speaking time.
> I more or less added what it took to me,
1 - 100 of 109 matches
Mail list logo
