| 1 |
On Wed, 2017-05-24 at 09:17 +0200, Guilherme Amadio wrote: |
| 2 |
> Hi David, |
| 3 |
> |
| 4 |
> On Tue, May 23, 2017 at 09:11:03AM +0200, David Seifert wrote: |
| 5 |
> > Dear users of the sci overlay, |
| 6 |
> > we've recently rearranged the git setup. The current sci setup is |
| 7 |
> > now |
| 8 |
> > exactly like the main tree setup, namely: |
| 9 |
> > |
| 10 |
> > 1. The authoritative repo is the one hosted by infra |
| 11 |
> > (git://anongit.gentoo.org/proj/sci.git) |
| 12 |
> > 2. All commits to the sci repo will be synced over to Github |
| 13 |
> > automatically, in ONE DIRECTION only. This means all the dual HEAD |
| 14 |
> > merging is obsolete now. |
| 15 |
> > 3. The Github repo is now meant as a (friendly) interface to |
| 16 |
> > potential |
| 17 |
> > contributors. |
| 18 |
> > 4. As a new QA policy, merge commits in the overlay are banned now. |
| 19 |
> > The |
| 20 |
> > sci overlay has much lower contention than the main repository, |
| 21 |
> > such |
| 22 |
> > that you can realistically always avoid merge commits, even for |
| 23 |
> > large |
| 24 |
> > batches of commits. This will require you to rebase your commits on |
| 25 |
> > top |
| 26 |
> > of remote: |
| 27 |
> > |
| 28 |
> > git pull --rebase=preserve |
| 29 |
> > |
| 30 |
> > I will likely further tighten the QA standards of the repository, |
| 31 |
> > due |
| 32 |
> > to a history of poor COMMITMSGs and other QA violations. This is |
| 33 |
> > supposed to be a testing ground for the main repo, where plans are |
| 34 |
> > to |
| 35 |
> > also introduce such QA measures. |
| 36 |
> > |
| 37 |
> > Furthermore, I am considering requiring full GPG-signed commits for |
| 38 |
> > the |
| 39 |
> > overlay, and for this I would like to get some input. I believe |
| 40 |
> > this |
| 41 |
> > prepares contributors for eventually joining Gentoo. For low-volume |
| 42 |
> > contributors not wanting to join, we can always merge pull requests |
| 43 |
> > from Github. Ideas? Are you opposed to this? |
| 44 |
> |
| 45 |
> I welcome all these changes. If we can help in educating people on |
| 46 |
> the |
| 47 |
> more tricky things, like signing with a GPG key, even better. I have |
| 48 |
> some ebuilds I use personally now that I will try to add in the next |
| 49 |
> few days to the overlay. |
| 50 |
> |
| 51 |
> That said, once we reach good enough quality of ebuilds in the |
| 52 |
> overlay, |
| 53 |
> we should start just moving them to the main tree. Gentoo is used by |
| 54 |
> quite a few physicists (myself included) and other scientists, so |
| 55 |
> eliminating the need for an extra overlay would be nice. I remember |
| 56 |
> having problems with things like blas/atlas and eselect due to |
| 57 |
> divergences with the main tree in not so distant past. Also, using |
| 58 |
> overlays with prefix is not always a seamless experience. |
| 59 |
> |
| 60 |
> I'm not saying the overlay should go away, but just be a staging area |
| 61 |
> for scientific packages before they land on the main tree. What are |
| 62 |
> your |
| 63 |
> thoughts on this? |
| 64 |
> |
| 65 |
> Cheers, |
| 66 |
> —Guilherme |
| 67 |
> |
| 68 |
|
| 69 |
You're putting it much too lightly - in its current state, the overlay |
| 70 |
is a disaster. More often than not it contains awful ebuilds, awfully |
| 71 |
broken, and noone feels a responsibility to fix the mess. People keep |
| 72 |
adding broken ebuilds to it. So yes, people should stop adding broken |
| 73 |
stuff to it, and more importantly, should rather send in high-quality |
| 74 |
stuff directly to the main tree instead of using the overlay as a |
| 75 |
quasi-permanent dumping ground. |
| 76 |
|
| 77 |
David |
Archives