[gentoo-science] Git reorganisation

[François Bissey]

Furthermore, I am considering requiring full GPG-signed commits for the
overlay, and for this I would like to get some input.

Weren’t we already doing this?

François

[David Seifert]

Hi David,

Dear users of the sci overlay,
we've recently rearranged the git setup. The current sci setup is
now
1. The authoritative repo is the one hosted by infra
(git://anongit.gentoo.org/proj/sci.git)
2. All commits to the sci repo will be synced over to Github
automatically, in ONE DIRECTION only. This means all the dual HEAD
merging is obsolete now.
3. The Github repo is now meant as a (friendly) interface to
potential
contributors.
4. As a new QA policy, merge commits in the overlay are banned now.
The
sci overlay has much lower contention than the main repository,
such
that you can realistically always avoid merge commits, even for
large
batches of commits. This will require you to rebase your commits on
top
  git pull --rebase=preserve
I will likely further tighten the QA standards of the repository,
due
to a history of poor COMMITMSGs and other QA violations. This is
supposed to be a testing ground for the main repo, where plans are
to
also introduce such QA measures.
Furthermore, I am considering requiring full GPG-signed commits for
the
 overlay, and for this I would like to get some input. I believe
this
prepares contributors for eventually joining Gentoo. For low-volume
contributors not wanting to join, we can always merge pull requests
from Github. Ideas? Are you opposed to this?

I welcome all these changes. If we can help in educating people on
the
more tricky things, like signing with a GPG key, even better. I have
some ebuilds I use personally now that I will try to add in the next
few days to the overlay.
That said, once we reach good enough quality of ebuilds in the
overlay,
we should start just moving them to the main tree. Gentoo is used by
quite a few physicists (myself included) and other scientists, so
eliminating the need for an extra overlay would be nice. I remember
having problems with things like blas/atlas and eselect due to
divergences with the main tree in not so distant past. Also, using
overlays with prefix is not always a seamless experience.
I'm not saying the overlay should go away, but just be a staging area
for scientific packages before they land on the main tree. What are
your
thoughts on this?
Cheers,
—Guilherme

You're putting it much too lightly - in its current state, the overlay
is a disaster. More often than not it contains awful ebuilds, awfully
broken, and noone feels a responsibility to fix the mess. People keep
adding broken ebuilds to it. So yes, people should stop adding broken
stuff to it, and more importantly, should rather send in high-quality
stuff directly to the main tree instead of using the overlay as a
quasi-permanent dumping ground.

David

[Benda Xu]

Hi,

Post by David Seifert
You're putting it much too lightly - in its current state, the overlay
is a disaster. More often than not it contains awful ebuilds, awfully
broken, and noone feels a responsibility to fix the mess. People keep
adding broken ebuilds to it. So yes, people should stop adding broken
stuff to it, and more importantly, should rather send in high-quality
stuff directly to the main tree instead of using the overlay as a
quasi-permanent dumping ground.

One pain in migrating ebuild to the main repo is that the
alternative.eclass ecosystem. Is there a plan to merge it? I am
wondering what is the blocking issue remaining.

Yours,
Benda

[François Bissey]

Post by Benda Xu
I am
wondering what is the blocking issue remaining.

Personally I’d like to discuss https://github.com/gentoo/sci/issues/709
before it is merged.

François

[David Seifert]

Hi everybody,

Hi David,

Dear users of the sci overlay,
we've recently rearranged the git setup. The current sci setup is
now
1. The authoritative repo is the one hosted by infra
(git://anongit.gentoo.org/proj/sci.git)
2. All commits to the sci repo will be synced over to Github
automatically, in ONE DIRECTION only. This means all the dual
HEAD
merging is obsolete now.
3. The Github repo is now meant as a (friendly) interface to
potential
contributors.
4. As a new QA policy, merge commits in the overlay are banned
now. The
sci overlay has much lower contention than the main repository,
such
that you can realistically always avoid merge commits, even for
large
batches of commits. This will require you to rebase your commits
on top
  git pull --rebase=preserve
I will likely further tighten the QA standards of the repository,
due
to a history of poor COMMITMSGs and other QA violations. This is
supposed to be a testing ground for the main repo, where plans
are to
also introduce such QA measures.
Furthermore, I am considering requiring full GPG-signed commits
for the
 overlay, and for this I would like to get some input. I believe
this
prepares contributors for eventually joining Gentoo. For low-
volume
contributors not wanting to join, we can always merge pull
requests
from Github. Ideas? Are you opposed to this?

I welcome all these changes. If we can help in educating people on
the
more tricky things, like signing with a GPG key, even better. I
have
some ebuilds I use personally now that I will try to add in the
next
few days to the overlay.
That said, once we reach good enough quality of ebuilds in the
overlay,
we should start just moving them to the main tree. Gentoo is used
by
quite a few physicists (myself included) and other scientists, so
eliminating the need for an extra overlay would be nice. I remember
having problems with things like blas/atlas and eselect due to
divergences with the main tree in not so distant past. Also, using
overlays with prefix is not always a seamless experience.
I'm not saying the overlay should go away, but just be a staging
area
for scientific packages before they land on the main tree. What are
your
thoughts on this?
Cheers,
—Guilherme

I actually agree and support the idea. However, I recently noticed
that
I no longer have the permission to close issues in github. Is it
possible to get those for sci again?
Before the announcement, I was using git.gentoo.org:proj/sci.git, for
which I have sufficient rights. Is there any difference, or rather
should I switch over to anongit.gentoo.org/proj/sci.git?
Best Regards
Marius

Which brings me to the next point - that thing shouldn't even be there.
The Github issue tracker was used in ancient days, and I'd much rather
people use bugzie than having 3 divergent issue trackers. I will add
you in the mean time.

[David Seifert]

Post by François Bissey

Furthermore, I am considering requiring full GPG-signed commits for the
overlay, and for this I would like to get some input.

Weren’t we already doing this?
François

Nope, not required. I'll talk on infra and likely start enabling this
soon, right after the COMMITMSG filter.

[François Bissey]

Post by David Seifert

Post by François Bissey

Furthermore, I am considering requiring full GPG-signed commits for the
overlay, and for this I would like to get some input.

Weren’t we already doing this?
François

Nope, not required. I'll talk on infra and likely start enabling this
soon, right after the COMMITMSG filter.

OK, now I remember. repoman forced you to do it, but just doing "git commit"
wasn’t requiring it. I changed my default settings after noticing that I didn’t
have to sign to send changes to an eclass.

[David Seifert]

Post by François Bissey

Post by David Seifert

Post by François Bissey

Furthermore, I am considering requiring full GPG-signed commits
for
the
overlay, and for this I would like to get some input.

Weren’t we already doing this?
François

Nope, not required. I'll talk on infra and likely start enabling this
soon, right after the COMMITMSG filter.

OK, now I remember. repoman forced you to do it, but just doing "git commit"
wasn’t requiring it. I changed my default settings after noticing that I didn’t
have to sign to send changes to an eclass.

I have now made signed commits and signed pushes mandatory on the
repository. To have your commits signed in the repo run

git config commit.gpgsign true

You will also need to sign your pushes to the repo.

git config push.gpgsign true

I will also start with adding a QA COMMITMSG filter that rejects bad
COMMITMSGs lacking the prelude: part.

Regards
David