Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Hans de Graaff]

On Tue, 2017-07-25 at 11:03 +0200, Agostino Sarubbo wrote:
> 
> 1) Don't file keywordreq, since noone work on them. File directly
> stablereq.

This does not make sense to me.

If we want to go this route we should probably state a policy instead
that new dependencies for already keyworded packages automatically get
those keywords as well, even if untested. For packages with stable
keywords this would provide a chance to find issues before the package
is marked stable.

For KEYWORDREQ bugs we could also enlist our users. As a maintainer of
dev-ruby packages I'd be happy to add any keywords based on a "emerge
--info" and "build.log with FEATURES=test" combo added to a KEYWORDREQ
bug. Putting out a call for action and an easy way for users to scan
open KEYWORDREQ bugs for their arch might put a good dent in these.

Hans

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

On wto, 2017-07-25 at 18:46 -0400, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 6:30 PM, Michał Górny  wrote:
> > On wto, 2017-07-25 at 18:26 -0400, Rich Freeman wrote:
> > > On Tue, Jul 25, 2017 at 4:29 PM, Mike Gilbert  wrote:
> > > > On Tue, Jul 25, 2017 at 12:12 PM, Michael Orlitzky  
> > > > wrote:
> > > > > On 07/25/2017 09:23 AM, Michał Górny wrote:
> > > > > > 
> > > > > > How is that relevant? Revision bumps are merely a tool to encourage
> > > > > > 'automatic' rebuilds of packages during @world upgrade. I can't 
> > > > > > think of
> > > > > > a single use case where somebody would actually think it sane to
> > > > > > checkout one commit after another, and run @world upgrade in the 
> > > > > > middle
> > > > > > of it.
> > > > > > 
> > > > > 
> > > > > Revisions are to indicate that one incarnation of a package differs 
> > > > > from
> > > > > another in a way that the user or package manager might care about. 
> > > > > And
> > > > > on principal, it's no business of yours what people want to do with
> > > > > their tree. If someone wants to check out successive commits and 
> > > > > emerge
> > > > > @world, he's within his rights to do so.
> > > > 
> > > > I don't feel I should be obligated by policy to support this use case.
> > > > One revbump per push seems sufficiently safe for 99.9% of users.
> > > > 
> > > > If you want to do more revbumps, you are free to do so.
> > > > 
> > > 
> > > What is the point of separating changes by commits if we don't
> > > generally try to keep each commit working?
> > > 
> > > Sure, there are some cases where it is just going to be too painful to
> > > ensure that, and so it doesn't have to be an absolute rule.
> > > 
> > > However, if somebody is checking out a tree at some point in the past
> > > they shouldn't have to try to figure out where the last push boundary
> > > was to ensure that it is sane.  Use cases for that include updating
> > > older systems progressively, or bisecting a problem.
> > 
> > Guys, please cut this FUD.
> > 
> > Nothing is broken if you don't revbump. The only thing that doesn't
> > happen is that the PM isn't obliged to suggest user to upgrade.
> > 
> 
> I wasn't referring to revbumps.  Just to ensuring that all commits
> generally work even if they aren't pushed.
> 

In that case, it is explicitly listed as the third rule for splitting.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Rich Freeman]

On Tue, Jul 25, 2017 at 6:30 PM, Michał Górny  wrote:
> On wto, 2017-07-25 at 18:26 -0400, Rich Freeman wrote:
>> On Tue, Jul 25, 2017 at 4:29 PM, Mike Gilbert  wrote:
>> > On Tue, Jul 25, 2017 at 12:12 PM, Michael Orlitzky  wrote:
>> > > On 07/25/2017 09:23 AM, Michał Górny wrote:
>> > > >
>> > > > How is that relevant? Revision bumps are merely a tool to encourage
>> > > > 'automatic' rebuilds of packages during @world upgrade. I can't think 
>> > > > of
>> > > > a single use case where somebody would actually think it sane to
>> > > > checkout one commit after another, and run @world upgrade in the middle
>> > > > of it.
>> > > >
>> > >
>> > > Revisions are to indicate that one incarnation of a package differs from
>> > > another in a way that the user or package manager might care about. And
>> > > on principal, it's no business of yours what people want to do with
>> > > their tree. If someone wants to check out successive commits and emerge
>> > > @world, he's within his rights to do so.
>> >
>> > I don't feel I should be obligated by policy to support this use case.
>> > One revbump per push seems sufficiently safe for 99.9% of users.
>> >
>> > If you want to do more revbumps, you are free to do so.
>> >
>>
>> What is the point of separating changes by commits if we don't
>> generally try to keep each commit working?
>>
>> Sure, there are some cases where it is just going to be too painful to
>> ensure that, and so it doesn't have to be an absolute rule.
>>
>> However, if somebody is checking out a tree at some point in the past
>> they shouldn't have to try to figure out where the last push boundary
>> was to ensure that it is sane.  Use cases for that include updating
>> older systems progressively, or bisecting a problem.
>
> Guys, please cut this FUD.
>
> Nothing is broken if you don't revbump. The only thing that doesn't
> happen is that the PM isn't obliged to suggest user to upgrade.
>

I wasn't referring to revbumps.  Just to ensuring that all commits
generally work even if they aren't pushed.

-- 
Rich

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

On wto, 2017-07-25 at 18:26 -0400, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 4:29 PM, Mike Gilbert  wrote:
> > On Tue, Jul 25, 2017 at 12:12 PM, Michael Orlitzky  wrote:
> > > On 07/25/2017 09:23 AM, Michał Górny wrote:
> > > > 
> > > > How is that relevant? Revision bumps are merely a tool to encourage
> > > > 'automatic' rebuilds of packages during @world upgrade. I can't think of
> > > > a single use case where somebody would actually think it sane to
> > > > checkout one commit after another, and run @world upgrade in the middle
> > > > of it.
> > > > 
> > > 
> > > Revisions are to indicate that one incarnation of a package differs from
> > > another in a way that the user or package manager might care about. And
> > > on principal, it's no business of yours what people want to do with
> > > their tree. If someone wants to check out successive commits and emerge
> > > @world, he's within his rights to do so.
> > 
> > I don't feel I should be obligated by policy to support this use case.
> > One revbump per push seems sufficiently safe for 99.9% of users.
> > 
> > If you want to do more revbumps, you are free to do so.
> > 
> 
> What is the point of separating changes by commits if we don't
> generally try to keep each commit working?
> 
> Sure, there are some cases where it is just going to be too painful to
> ensure that, and so it doesn't have to be an absolute rule.
> 
> However, if somebody is checking out a tree at some point in the past
> they shouldn't have to try to figure out where the last push boundary
> was to ensure that it is sane.  Use cases for that include updating
> older systems progressively, or bisecting a problem.

Guys, please cut this FUD.

Nothing is broken if you don't revbump. The only thing that doesn't
happen is that the PM isn't obliged to suggest user to upgrade.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Rich Freeman]

On Tue, Jul 25, 2017 at 4:29 PM, Mike Gilbert  wrote:
> On Tue, Jul 25, 2017 at 12:12 PM, Michael Orlitzky  wrote:
>> On 07/25/2017 09:23 AM, Michał Górny wrote:
>>>
>>> How is that relevant? Revision bumps are merely a tool to encourage
>>> 'automatic' rebuilds of packages during @world upgrade. I can't think of
>>> a single use case where somebody would actually think it sane to
>>> checkout one commit after another, and run @world upgrade in the middle
>>> of it.
>>>
>>
>> Revisions are to indicate that one incarnation of a package differs from
>> another in a way that the user or package manager might care about. And
>> on principal, it's no business of yours what people want to do with
>> their tree. If someone wants to check out successive commits and emerge
>> @world, he's within his rights to do so.
>
> I don't feel I should be obligated by policy to support this use case.
> One revbump per push seems sufficiently safe for 99.9% of users.
>
> If you want to do more revbumps, you are free to do so.
>

What is the point of separating changes by commits if we don't
generally try to keep each commit working?

Sure, there are some cases where it is just going to be too painful to
ensure that, and so it doesn't have to be an absolute rule.

However, if somebody is checking out a tree at some point in the past
they shouldn't have to try to figure out where the last push boundary
was to ensure that it is sane.  Use cases for that include updating
older systems progressively, or bisecting a problem.

-- 
Rich

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

On wto, 2017-07-25 at 16:31 -0400, Michael Orlitzky wrote:
> On 07/25/2017 04:29 PM, Mike Gilbert wrote:
> > 
> > I don't feel I should be obligated by policy to support this use case.
> > One revbump per push seems sufficiently safe for 99.9% of users.
> > 
> > If you want to do more revbumps, you are free to do so.
> > 
> 
> Can I also delete packages and break the tree so long as I put
> everything back before I push?

That is not the same, and you know that. Plus, there's a major
difference between not doing unnecessary work and purposely doing
something awful just to prove a point.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michael Orlitzky]

On 07/25/2017 04:29 PM, Mike Gilbert wrote:
> 
> I don't feel I should be obligated by policy to support this use case.
> One revbump per push seems sufficiently safe for 99.9% of users.
> 
> If you want to do more revbumps, you are free to do so.
> 

Can I also delete packages and break the tree so long as I put
everything back before I push?

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Mike Gilbert]

On Tue, Jul 25, 2017 at 12:12 PM, Michael Orlitzky  wrote:
> On 07/25/2017 09:23 AM, Michał Górny wrote:
>>
>> How is that relevant? Revision bumps are merely a tool to encourage
>> 'automatic' rebuilds of packages during @world upgrade. I can't think of
>> a single use case where somebody would actually think it sane to
>> checkout one commit after another, and run @world upgrade in the middle
>> of it.
>>
>
> Revisions are to indicate that one incarnation of a package differs from
> another in a way that the user or package manager might care about. And
> on principal, it's no business of yours what people want to do with
> their tree. If someone wants to check out successive commits and emerge
> @world, he's within his rights to do so.

I don't feel I should be obligated by policy to support this use case.
One revbump per push seems sufficiently safe for 99.9% of users.

If you want to do more revbumps, you are free to do so.

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Daniel Campbell]

On 07/25/2017 06:22 AM, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka  
> wrote:
>>
>> The 30 day waiting period is useful for smoking out major upstream bugs,
>> but can't replace stabilisation integration testing. For example,
>> package foobar may build fine in ~arch but fails in stable because it
>> needs a newer libbaz.
>>
> 
> I think this is a good reason why everything should be at least
> build-tested on a stable tree before getting stabilized.  Now, that
> might not be on each arch if it is truly arch-independent (and if
> arches keep the dependencies reasonably in sync).
> 
> This might be a situation where a compromise could exist.  Have some
> kind of flag (in metadata, or maybe the ebuild) that indicates that
> the maintainer believes the package is low-risk to stabilize purely on
> a build test.  Then after 30 days in testing a tinderbox could
> build-test the package and stabilize it automatically.
> 
> If the package is considered at-risk then it goes through manual
> testing, either by the maintainer or an arch team.
> 
> This will also encourage the teams doing testing to actually do more
> testing on the packages that would benefit from it.
> 
> We wouldn't set hard criteria but leave it up to maintainer
> discretion, with a guideline being that past performance is probably a
> good predictor of future results.
> 
This reads like a practical use of both developer time and machine time.
Build testing at a minimum, imo, is necessary if the word "stable" is
going to mean anything for us. So +1.

Since there are bound to be fewer manually tested packages than
automatic "it builds, ship it" packages, I think it would make a bit
more sense to add a "manually test this please" tag to metadata.xml,
rather than expect auto-stabilizers to have additional tags, which will
outnumber the manual packages and inflate the size of the tree (albeit
slightly).

Since maintainers also manage their packages in various ways, could we
extend this to a general  element? Maintainers can specify how
they'd prefer bugs or commits to be done, and an additional element to
indicate hand-testing. This would solve two problems instead of just
one: indicate a package is ready for auto-stabilization, and give a
single, canonical location for a maintainer to put maintenance policy.

Just my 2¢,

~zlg
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Tue, Jul 25, 2017 at 3:45 PM, Markus Meier  wrote:
> On Tue, 25 Jul 2017 11:03:30 +0200
> Agostino Sarubbo  wrote:
>
>> On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote:
>> > 1. lack of automation
>> I'd summarize the techical steps into:
>> 1) get the list of packages
>> 2) test
>> 3) commit to git
>> 4) write on bugzilla
>>
>> 1 is done by getatoms https://github.com/kensington/bugbot
>> 2 is done by the tester in the manner he prefer
>> 3 no official tool available, I used a modified version of
>> https://gitweb.gentoo.org/proj/arch-tools.git/tree/batch-stabilize.py
>> which is still based on CVS
>> 4 no official tool available, I used my own bash script which calls
>> pybugz
>>
>> So, points 3 and 4 needs to be improved, I have the idea on how the
>> script should look, but I have no time to do it and no python
>> knowledge. I can assist everyone that candidate itself to make the
>> tool/script like I did with kensington when he made getatoms.
>
> for 3 and 4 there's the keyword.sh script in my overlay (under scripts)
> that has been working for ages (at least for me)...
>

It is a slightly different process, but there is also the situation
where an arch is slow to respond to a stablereq and the maintainer
wishes to drop keywords.

In that case a script is needed which will remove stable keywords on
all reverse deps of the package.

Back when the council approved dropping keywords in these situations
it seemed to be that the effort required to do so was the main barrier
to maintainers taking advantage of the policy.  Awareness might be
another issue, as I don't think it really got documented outside of
the summaries.

-- 
Rich

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Markus Meier]

On Tue, 25 Jul 2017 11:03:30 +0200
Agostino Sarubbo  wrote:

> On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote:
> > 1. lack of automation  
> I'd summarize the techical steps into:
> 1) get the list of packages
> 2) test
> 3) commit to git
> 4) write on bugzilla
> 
> 1 is done by getatoms https://github.com/kensington/bugbot
> 2 is done by the tester in the manner he prefer
> 3 no official tool available, I used a modified version of 
> https://gitweb.gentoo.org/proj/arch-tools.git/tree/batch-stabilize.py
> which is still based on CVS
> 4 no official tool available, I used my own bash script which calls
> pybugz
>
> So, points 3 and 4 needs to be improved, I have the idea on how the
> script should look, but I have no time to do it and no python
> knowledge. I can assist everyone that candidate itself to make the
> tool/script like I did with kensington when he made getatoms.

for 3 and 4 there's the keyword.sh script in my overlay (under scripts)
that has been working for ages (at least for me)...


Regards,
Markus

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michael Orlitzky]

On 07/25/2017 09:23 AM, Michał Górny wrote:
> 
> How is that relevant? Revision bumps are merely a tool to encourage
> 'automatic' rebuilds of packages during @world upgrade. I can't think of
> a single use case where somebody would actually think it sane to
> checkout one commit after another, and run @world upgrade in the middle
> of it.
> 

Revisions are to indicate that one incarnation of a package differs from
another in a way that the user or package manager might care about. And
on principal, it's no business of yours what people want to do with
their tree. If someone wants to check out successive commits and emerge
@world, he's within his rights to do so.

This is relevant because your proposed policy,

  * presumes to know how people will use the tree, and places arbitrary
restrictions on them

  * can cause problems if those assumptions don't hold

  * requires developers to think about when it's safe to push (Did I
push those changes last night? Do I need another revision?)

  * and is more complicated than the safe solution, anyway

Here's my proposal regarding revisions:

  If you make a commit that requires a revision, make a revision.

If you wind up with an -r15 in the tree, who cares? It's simpler, safer,
and less to think about.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Tue, Jul 25, 2017 at 10:13 AM, Michał Górny  wrote:
>
> I feel like this is going towards 'anybody can do keywording /
> stabilization'. I'd rather not go this route right now, and just let
> arch teams recruit people as they see fit.
>

I think this depends on the arch team.

Back in the early days of amd64 I was an AT and an early adopter in
general.  There were a lot of bugs with types/etc and broken
assumptions.  It was helpful to have a team that was familiar with the
most common problems and which had the hardware to test things.

Now we never see an amd64-specific issue because that is what all the
upstream projects do their own QA using.  If anything we'd be more
likely to see x86 bugs, but most people have learned how to use types
correctly/etc, and I suspect this has benefited other architectures as
well.

I saw an analogous situation with systemd.  In the early days we were
writing a lot of units.  These days it is just dealing with one-offs
as much of the work is now upstreamed.

I think that the more mainstream something is, the less the need for
specialized teams to deal with every issue.  Sure, somebody could
always escalate a sticky problem, but having an arch team do every
stabilization seems like having the gcc team look at every build
error.

-- 
Rich

Re: [gentoo-dev] New eclass: opam.eclass

[Michał Górny]

On pon, 2017-07-24 at 17:20 +0200, Alexis Ballier wrote:
> # Copyright 1999-2017 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> 
> # @ECLASS: opam.eclass
> # @MAINTAINER:
> # Gentoo ML Project 
> # @AUTHOR:
> # Alexis Ballier 
> # @BLURB: Provides functions for installing opam packages.
> # @DESCRIPTION:
> # Provides dependencies on opam and ocaml, opam-install and a default
> # src_install for opam-based packages.
> 
> case ${EAPI:-0} in
> 0|1|2|3|4) die "You need at least EAPI-5 to use opam.eclass";;

Why not start straight with EAPI 6? You will have less to clean up
later.

> *) ;;
> esac
> 
> RDEPEND=">=dev-lang/ocaml-4:="
> DEPEND="${RDEPEND}
>   dev-ml/opam"
> 
> # @FUNCTION: opam-install
> # @USAGE: 
> # @DESCRIPTION:
> # Installs the opam packages given as arguments. For each "${pkg}" element in
> # that list, "${pkg}.install" must be readable from current working directory.
> opam-install() {

local pkg

>   for pkg ; do
>   opam-installer -i \
>   --prefix="${ED}/usr" \
>   --libdir="${D}/$(ocamlc -where)" \
>   --docdir="${ED}/usr/share/doc/${PF}" \
>   --mandir="${ED}/usr/share/man" \

Both ED and D include the trailing slash, so either remove the extra
slash or use ${ED%/}.

>   "${pkg}.install" || die
>   done
> }
> 
> opam_src_install() {
>   opam-install "${PN}"
>   # Handle opam putting doc in a subdir
>   if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then

Is PN always the correct subdirectory here?

>   mv "${ED}/usr/share/doc/${PF}/${PN}/"* 
> "${ED}/usr/share/doc/${PF}/" || die
>   rmdir "${ED}/usr/share/doc/${PF}/${PN}" || die
>   fi
> }
> 
> EXPORT_FUNCTIONS src_install

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Peter Stuge]

Michael Palimaka wrote:
> The 30 day waiting period is useful for smoking out major upstream bugs,
> but can't replace stabilisation integration testing. For example,
> package foobar may build fine in ~arch but fails in stable because it
> needs a newer libbaz.

So that's either because of an ebuild bug (incorrect DEPEND) or an
upstream bug (e.g. incorrect PKG_CONFIG_CHECK in configure.ac), right?

It seems to me that waiting (random()=30) days and then testing
against (random()=current-version) libbaz in stable isn't amazing. :)

The ebuild bug could be detected automatically for upstreams using
configure.ac and maybe also cmake.

The upstream bug, well, that's a bit more tricky.


I'll try to write a thoughtful response in the other part of this
thread later. Gotta run now. Thanks everyone for your insights!


//Peter

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michał Górny]

Hi,

Before I start replying to specific bits, I think it would be reasonable
to outline the flow of a keywording/stabilization bug. I would split it
into 4 steps:

S1. Someone (anyone) files a bug requesting it.

S2. Someone (maintainer or OP) prepares a complete list of packages
(including dependencies).

S3. The maintainers approve (or reject) the request.

S4. The arch teams process the request.

Now, I think all considerations on automation should be from
the perspective of those steps.


On pon, 2017-07-24 at 22:22 +0100, Sergei Trofimovich wrote:
> TL;DR
> -
> 
> I see the problem of lagging stable and unstable trees as:
> 
> 1. lack of automation
> 2. lack of manpower
> 
> The PROPOSAL to solve the '1. automation' part is to draft
> a new GLEP. If there is any interest (I assume there is!) I'll start one.
> Let's call that fufure 'life of KEYWORDS'. It will cover:
> 
> - Update on GLEP-40 ("x86 stabilization can do only x86@ team")
>   to allow package maintainers to do ARCH=x86 stabilization.
>   It will be an arch-agnostic way: each arch will have minimal requirements
>   to setup environment suitable for stabilization and keywording:
>   CFLAGS to have, hardware required, whatever else is practical.

I'd dare say arch-specific policies are arch team's business.
The replacement for GLEP 40 should set some base rules but allow arch
teams to override them.

I feel like this is going towards 'anybody can do keywording /
stabilization'. I'd rather not go this route right now, and just let
arch teams recruit people as they see fit.

- Formalize list of stable arches as such (will be covered by
>   'arches.desc' GLEP)
> - Formalize what is a "stable arch". In short:
>   - arch is marked as such in 'arches.desc'
>   - performs most of STABLEREQ/KEYWORDREQ or gives rationale
> why progress can't be easily done before 90-days timeout

Just to be clear, is this going into your GLEP? I'd prefer if
the 'arches.desc' GLEP was kept purely technical wrt the file format
and not covered policies.

Oh, and when you are doing the new GLEP, don't forget to mention
ALLARCHES.

> 
> - Formalize and automate process of dropping keywords for timed out
>   STABLEREQ/KEYWORDREQ requests.
> - Automate process of restoring dropped KEYWORDS due to bumps
>   adding new unkeyworded dependencies. repoman already complains
>   about those. What is left is to grab them in batches time to time
>   and handle those as if those were KEYWORDREQ.

This might require making more proactive use of '-foo' keywords (QA
tools complain about them right now), or some other way of indicating
'I have tested it and it won't work'. Or at least checking for WONTFIX
bugs.

> - File more automated STABLEREQs to rely less on lazy maintainers
>   (I am example of lazy maintainer not siling STABLEREQs enough).

What I'm a little worried about is that this would proactively try to
stabilize package versions that are not suitable for stabilizations,
e.g. upstream development branch. Without expecting too much guesswork
on the scripting, I'd say it'd be reasonable enough if it checked for
WONTFIX bugs to avoid filing the same rejected bug again.

Those are the solution for S1 and maybe partially S2 in my flow above.
What I'd add for S2:

- make stable bot more proactive on complaining about package lists with
missing dependencies -- right now it waits for arch teams to be CC-ed;
given this might require packages from other maintainers, it'd be better
if it tried investigating earlier (guessing keywords from existing
package if they are not explicitly given in package list).

> - Formalize which STABLEREQ/KEYWORDREQ can be done automatically
>   by arch teams (or maybe anyone else having the hardware!).
>   In short: anything not marked as "Runtime testing required"
>   on bugzilla and not having any blocker bugs.

And that's S4. I'd focus on leaving it for the arch teams to have
a final say but the 'runtime testing required' part is reasonable.


All that said, I think there's one more important part of tooling we're
missing right now: reverse mapping of packages into keywording /
stabilization bugs. In other words, having a package app-foo/bar, I'd
like to know if its keywording or stabilization has been requested
anywhere. In other words, if I should include it in my bug, or just link
to some other bug, or...

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michał Górny]

On wto, 2017-07-25 at 22:59 +1000, Michael Palimaka wrote:
> On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> > 2. Q: How to make arch testing faster and easier?
> > 
> >A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> > required" will be automatically tested and keyworded.
> > 
> > [handwave] automated tinderbox setup would help a lot
> > to now upfront what fails to built, fails tests.
> 
> I've had similar thoughts about this and have already been working on
> some tooling for this.
> 
> We would need to establish exactly what criteria must be met for an
> automated test to be considered as successful.
> 
> Here's a sample report that my tool produces:
> https://dev.gentoo.org/~kensington/tinderbox/sys-apps/dbus/dbus-1.6.18-r1/df017e14-bd68-47e2-9738-554e7ba1cf10.html
> 
> In this case, would it be enough that it builds and tests pass? What
> about the QA issues? Do we need someone to review them to determine if
> they should block stabilisation, or if they're even a regression or not?
> 

There are different kinds of QA issues and they have different
significance. You can ignore some of them, some others are more
important.

GLEP 65 defines a 'eqatag' function that the checks can use to provide
machine-readable results for the checks. You should work with that
instead of parsing the verbose messages.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

On wto, 2017-07-25 at 09:26 -0400, Rich Freeman wrote:
> On Tue, Jul 25, 2017 at 7:52 AM, Michał Górny  wrote:
> > 
> > Except that there is no machines using it. In all contexts, using full URL 
> > for machine readability is better as it works with all software out of the 
> > box.
> > 
> 
> Until the domain name of the bugzilla server changes/etc.  Even if we
> migrated all the old bugs the URLs would break.  That might be an
> argument for not having a full URL.

This is a very stupid argument. If we ever break bug URLs, commit
messages are the *least* of our concerns.

> There would also be less variation.  Bug: 123456 is pretty unambiguous
> as a reference.  When you start having http vs https and maybe a few
> different ways of creating a URL to a bug it could get messier.

Except that 123456 could refer to any bugtracker anywhere. No reasonable
tool will do anything with that number since it's ambiguous by
definition.

And if I were to use stupid arguments, then I should point out if we
ever have a review platform, then the numbers would suddenly become
ambiguous -- is it Bugzilla or the review platform?

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

On wto, 2017-07-25 at 08:54 -0400, Joshua Kinard wrote:
> On 07/25/2017 04:05, Michał Górny wrote:
> > Hi, everyone.
> > 
> > There have been multiple attempts at grasping this but none so far
> > resulted in something official and indisputable. At the same time, we
> > end having to point our users at semi-official guides which change
> > in unpredictable ways.
> > 
> > Here's the current draft:
> > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
> > 
> > The basic idea is that the GLEP provides basic guidelines for using git,
> > and then we write a proper manual on top of it (right now, all the pages
> > about it end up as a mix of requirements and a partial git manual).
> > 
> > What do you think about it? Is there anything else that needs being
> > covered?
> > 
> > Copy of the markup for inline comments follows.
> 
> I haven't seen it mentioned yet, but will this GLEP update or replace this
> existing Wiki article on using git w/ Gentoo?:
> 
> https://wiki.gentoo.org/wiki/Gentoo_git_workflow

We will probably remove it in favor of a proper devmanual section.
Proxy-maint already stopped using it because there's too much noise
there.

> Some of the step-by-step bits in the above Wiki page look like good candidates
> to be integrated into the GLEP.

Could you be more specific?

>   It also contains guidelines on writing commit
> messages, such as limiting the first line to ~50 characters, an optional body
> wrapped at 75 chars/line, and including the usual git tags for sign-off and
> such.  Though, I like the explicitness of the GLEP's text on a few things 
> more.

There is a large section on commit messages in the GLEP. Though it uses
69 as the technical limit of summary line, since ~50 is realistically
hard to achieve for Gentoo.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] New eclass: opam.eclass

[Michał Górny]

On wto, 2017-07-25 at 12:48 +, Peter Stuge wrote:
> Good work on the refactoring!
> 
> Alexis Ballier wrote:
> > > > if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then  
> > > 
> > > It’s always been recommended to me that we should use the [[ … ]]
> > > form.
> > 
> > Doesn't make much difference here
> 
> Some; you need neither quote nor {} in expansions within [[ ]]. So
> instead of the above one could write:

{} is completely irrelevant to [ ] vs [[ ]].

> 
> if [[ -d $ED/usr/share/doc/$PF/$PN ]]; then
> 
> 
> > and I've always been recommending the other way :p
> 
> ..
> > if you only do ebuilds or bash, then you don't care, but I definitely
> > do other scripts
> 
> Be that as it may this is an eclass, and I think conforming to an
> established coding style has significant value. I too have understood
> that to be [[ ]].

...and ${}.

> 
> 
> Thanks
> 
> //Peter
> 

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 23:10 +1000, Michael Palimaka escribió:
> On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote:
> > First, the assumption in our processes seems to be that many or
> > important bugs will be due to architecture-specific differences, and I
> > wonder if that assumption really holds up. Do arch testers for a smaller
> > arch often find problems that were not noticed on one of the larger
> > arches? With the languages and tools that we have today, it seems like
> > for many of our packages, bugs due to architectural differences
> > represent a minority of the problems we found. In this case, the whole
> > idea of per-arch stabilization does not really make sense, and doing
> > away with that idea could drastically shortcut our process.
> 
> This would be really interesting to know.

Anyway, I think it depends on the arch you are running. I remember to have seen
specific issues for ia64, hppa, ppc64 or arm. But, for example, I agree that,
*at present time*, I don't remember to have seen a package failing on x86 and
not on amd64 for example (well, I now remember a past systemd upstream runtime
bug that was catched in testing period ;)). 

Then, I guess it depends on each arch. For example, for x86 it could be probably
done if things work on amd64 :/. Between ppc and ppc64 I don't know. For the
others, I don't think that we can extrapolate between amd64 and ia64 for example
(I remember important runtime issues to be catched only affecting ia64 for
example).

Re: [gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

On wto, 2017-07-25 at 22:28 +1000, Michael Palimaka wrote:
> On 07/25/2017 06:05 PM, Michał Górny wrote:
> > Hi, everyone.
> > 
> > There have been multiple attempts at grasping this but none so far
> > resulted in something official and indisputable. At the same time, we
> > end having to point our users at semi-official guides which change
> > in unpredictable ways.
> > 
> > Here's the current draft:
> > https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
> 
> This looks really nice, thanks for working on it.
> 
> > * When doing a minor change to a large number of packages, it is
> > reasonable to do so in a single commit. However, when doing a major
> > change (e.g. a version bump), it is better to split commits on package
> > boundaries.
> 
> In some cases we do prefer to make major changes on a set of related
> package all in one commit. For example, we always bump the 240+ KDE
> Applications collection together because that's how it's released.

It's merely a recommendation. I don't want to cover every single use
case because that would be insane. I'm already worried I've covered too
many cases for people to read it all.

> > ===Commit messages===
> > A standard git commit message consists of three parts, in order: a
> > summary line, an optional body and an optional set of tags. The parts
> > are separated by a single empty line.
> > 
> > The summary line is included in the short logs (git log --
> > oneline, gitweb, GitHub, mail subject) and therefore should
> > provide a short yet accurate description of the change. The summary line
> > starts with a logical unit name, followed by a colon, a space and a
> > short description of the most important changes. If a bug is associated
> > with a change, then it should be included in the summary line as
> > #nn or likewise. The summary line must not exceed 69
> > characters, and must not be wrapped.
> 
> Does a bug # really need to always be in the summary line? It can eat
> valuable characters and tags which are pretty popular are equally valid IMO.

Tags don't appear on 'git log --oneline' or cgit/gitweb shortlog. If you
are groking through multiple bugs, it is more convenient if you can find
the bug no straight away.

> > ** Bug: https://bugs.gentoo.org/NN;; — to
> > reference a bug,
> > ** Closes: https://github.com/gentoo/gentoo/pull/ > ki>; — to automatically close a GitHub pull request,
> > ** Fixes: https://bugs.gentoo.org/NN;; —
> > to indicate a fixed bug,
> 
> grepping the git log shows that 'Gentoo-bug' is much more common than
> plain 'Bug'. 'Fixes' is hardly used at all, and I think it's a bit
> confusing to use this for bugs as well as commits.

'Fixes' is the original tag used by other projects. 'Bug' is shorter
than 'Gentoo-bug' and avoids repeating the obvious. Much like we do not
have 'Gentoo-signed-off-by', 'Gentoo-thanks-to' and so on, having
'Gentoo-bug' is equally silly.

Furthermore, full URLs should be used with tags. If you are already
using tags (i.e. long form), don't do it half-way and put useless digits
there. Put URL that will be interpreted by practically all visual git
tools written ever.

> > a few branches on the repository, and did not maintain them. The Infra
> > had to query the developers about the state of the branches and clean
> > them up.
> 
> Should 'The Infra' be 'The Infra team' or just 'Infra'?

Yes, thanks.

> 
> > Gentoo developers are still frequently using Gentoo-Bug tag,
> > sometimes followed by Gentoo-Bug-URL. Using both
> > simultaneously is meaningless (they are redundant), and using the former
> > has no advantages over using the classic #nn form in the
> > summary or the body.
> 
> I agree that using both is redundant, but I don't agree with
> discouraging or banning the use of 'Gentoo-bug'. If someone prefers to
> use it so it sits nicely with the other tags why stop them?

I'm not stopping anyone. This is merely a suggestion. Encouraging two
different tags for the same thing would be confusing to users.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 22:59 +1000, Michael Palimaka escribió:
> On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> > 2. Q: How to make arch testing faster and easier?
> > 
> >    A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> > required" will be automatically tested and keyworded.
> > 
> > [handwave] automated tinderbox setup would help a lot
> > to now upfront what fails to built, fails tests.
> 
> I've had similar thoughts about this and have already been working on
> some tooling for this.
> 
> We would need to establish exactly what criteria must be met for an
> automated test to be considered as successful.
> 
> Here's a sample report that my tool produces:
> https://dev.gentoo.org/~kensington/tinderbox/sys-apps/dbus/dbus-1.6.18-r1/df01
> 7e14-bd68-47e2-9738-554e7ba1cf10.html
> 
> In this case, would it be enough that it builds and tests pass? What
> about the QA issues?

Personally, I don't feel QA issues as major enough to block a stabilization,
usually they won't cause major issues for stable users and, if they do, for sure
they shouldn't be only QA issues :/

>  Do we need someone to review them to determine if
> they should block stabilisation, or if they're even a regression or not?
> 

Regarding general regressions, that is probably the harder point to handle
automatically. In the past, the scripts in arch-tools.git were avoiding to open
automated stable bug reports for packages having opened bugs (excluding
enhancement and QA bug reports), but that approach is not too good as, for
example, having a bug report asking for a version bump but tagged as "normal"
and not "enhancement" will lead to the bug not being opened :S

Then, I am unsure about if that part can be done automatically :/

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Rich Freeman]

On Tue, Jul 25, 2017 at 7:52 AM, Michał Górny  wrote:
>
> Except that there is no machines using it. In all contexts, using full URL 
> for machine readability is better as it works with all software out of the 
> box.
>

Until the domain name of the bugzilla server changes/etc.  Even if we
migrated all the old bugs the URLs would break.  That might be an
argument for not having a full URL.

There would also be less variation.  Bug: 123456 is pretty unambiguous
as a reference.  When you start having http vs https and maybe a few
different ways of creating a URL to a bug it could get messier.

That said, I really don't have a strong opinion on this.

-- 
Rich

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 15:19 +0200, Michał Górny escribió:
> On wto, 2017-07-25 at 14:15 +0200, Pacho Ramos wrote:
> > El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> > > Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos 
> > > napisał(a):
> > > > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> > > > > On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
> > > > > > 
> > > > > > I hold a perhaps radical view: I would like to simply remove
> > > > 
> > > > stable.
> > > > > > 
> > > > > > [snip]
> > > > > > 
> > > > > > I consider dev time a precious resource.
> > > > > 
> > > > > If we were to drop stable I would have to start maintaining my own
> > > > > stable lists to determine what would be ready to into production for
> > > > 
> > > > my
> > > > > company. In production "works most of the time" and "good enough"
> > > > > simply aren't good enough.
> > > > > 
> > > > > I estimate that would at least equal the amount of time I'm currently
> > > > > spending on Gentoo work, and consequently my contributions to Gentoo
> > > > > would dwindle to a halt. Most likely I would start looking at other
> > > > > solutions altogether.
> > > > > 
> > > > > > More troubleshooting and fixing "hard" problems, less routine work.
> > > > > 
> > > > > Except that some of that routine work is actually what I enjoy doing
> > > > 
> > > > in
> > > > > Gentoo. I already get plenty of the other two in my day job.
> > > > > 
> > > > > Hans
> > > > 
> > > > If stable goes away I will simply switch to other distribution and
> > > > retire
> > > 
> > > What's the "over my dead commit access" spirit? 
> > > 
> > 
> > Jumping from trying to maintain stable tree to arches dead for ages to drop
> > all
> > stable trees looks to me like a joke promoted by people that has never
> > handled
> > any stabilization request and saw on them how running a pure "testing"
> > system is
> > impossible on many conditions. It seems that some people think that if it
> > fits
> > ok for them, it will fit for all others like we were all using Gentoo for
> > doing
> > the same.
> > 
> 
> I'm sorry, that was supposed to be 'where', not 'what' (stupid
> autocompletion!). I simply meant to say that you should have said 'over
> my dead commit access' there ;-).
> 
> 

Ah, no problem. I am also sorry for my quick response to the thread but,
seriously, when I read the suggestion I was like =O

Best regards!

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

On wto, 2017-07-25 at 08:26 -0400, Michael Orlitzky wrote:
> On 07/25/2017 07:52 AM, Michał Górny wrote:
> > 
> > I have no clue what you mean. I'm just saying that if you push 10
> > changes in 10 commits, you don't have to go straight to -r10 in a
> > single push.
> > 
> 
> Exactly. Do that instead of hoping that no one checks out your
> intermediate commits. There's no limit to the number of revisions we can
> have, and trying to keep track of when it's safe to push in your head is
> asking for trouble.
> 

How is that relevant? Revision bumps are merely a tool to encourage
'automatic' rebuilds of packages during @world upgrade. I can't think of
a single use case where somebody would actually think it sane to
checkout one commit after another, and run @world upgrade in the middle
of it.

-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Tue, Jul 25, 2017 at 9:10 AM, Michael Palimaka  wrote:
>
> The 30 day waiting period is useful for smoking out major upstream bugs,
> but can't replace stabilisation integration testing. For example,
> package foobar may build fine in ~arch but fails in stable because it
> needs a newer libbaz.
>

I think this is a good reason why everything should be at least
build-tested on a stable tree before getting stabilized.  Now, that
might not be on each arch if it is truly arch-independent (and if
arches keep the dependencies reasonably in sync).

This might be a situation where a compromise could exist.  Have some
kind of flag (in metadata, or maybe the ebuild) that indicates that
the maintainer believes the package is low-risk to stabilize purely on
a build test.  Then after 30 days in testing a tinderbox could
build-test the package and stabilize it automatically.

If the package is considered at-risk then it goes through manual
testing, either by the maintainer or an arch team.

This will also encourage the teams doing testing to actually do more
testing on the packages that would benefit from it.

We wouldn't set hard criteria but leave it up to maintainer
discretion, with a guideline being that past performance is probably a
good predictor of future results.

-- 
Rich

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michał Górny]

On wto, 2017-07-25 at 14:15 +0200, Pacho Ramos wrote:
> El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> > Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos  napisał(a):
> > > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> > > > On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
> > > > > 
> > > > > I hold a perhaps radical view: I would like to simply remove
> > > 
> > > stable.
> > > > > 
> > > > > [snip]
> > > > > 
> > > > > I consider dev time a precious resource.
> > > > 
> > > > If we were to drop stable I would have to start maintaining my own
> > > > stable lists to determine what would be ready to into production for
> > > 
> > > my
> > > > company. In production "works most of the time" and "good enough"
> > > > simply aren't good enough.
> > > > 
> > > > I estimate that would at least equal the amount of time I'm currently
> > > > spending on Gentoo work, and consequently my contributions to Gentoo
> > > > would dwindle to a halt. Most likely I would start looking at other
> > > > solutions altogether.
> > > > 
> > > > > More troubleshooting and fixing "hard" problems, less routine work.
> > > > 
> > > > Except that some of that routine work is actually what I enjoy doing
> > > 
> > > in
> > > > Gentoo. I already get plenty of the other two in my day job.
> > > > 
> > > > Hans
> > > 
> > > If stable goes away I will simply switch to other distribution and
> > > retire
> > 
> > What's the "over my dead commit access" spirit? 
> > 
> 
> Jumping from trying to maintain stable tree to arches dead for ages to drop 
> all
> stable trees looks to me like a joke promoted by people that has never handled
> any stabilization request and saw on them how running a pure "testing" system 
> is
> impossible on many conditions. It seems that some people think that if it fits
> ok for them, it will fit for all others like we were all using Gentoo for 
> doing
> the same.
> 

I'm sorry, that was supposed to be 'where', not 'what' (stupid
autocompletion!). I simply meant to say that you should have said 'over
my dead commit access' there ;-).


-- 
Best regards,
Michał Górny


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michael Palimaka]

On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote:
> First, the assumption in our processes seems to be that many or
> important bugs will be due to architecture-specific differences, and I
> wonder if that assumption really holds up. Do arch testers for a smaller
> arch often find problems that were not noticed on one of the larger
> arches? With the languages and tools that we have today, it seems like
> for many of our packages, bugs due to architectural differences
> represent a minority of the problems we found. In this case, the whole
> idea of per-arch stabilization does not really make sense, and doing
> away with that idea could drastically shortcut our process.

This would be really interesting to know.

> Second, I believe a lot of the value in our stable tree comes *just*
> from the requirement that stabilization is only requested after 30 days
> without major bugs/changes in the unstable tree. Assuming there are
> enough users of a package on unstable, that means important bugs can be
> shaken out before a version hits stable. This could mean that
> potentially, even if we inverted our entire model to say we
> "automatically" stabilize after a 30-day period without major bugs, we
> hit most of the value of the stable tree with again drastically reduced
> pain/work.

The 30 day waiting period is useful for smoking out major upstream bugs,
but can't replace stabilisation integration testing. For example,
package foobar may build fine in ~arch but fails in stable because it
needs a newer libbaz.

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michael Palimaka]

On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> 2. Q: How to make arch testing faster and easier?
> 
>A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> required" will be automatically tested and keyworded.
> 
> [handwave] automated tinderbox setup would help a lot
> to now upfront what fails to built, fails tests.

I've had similar thoughts about this and have already been working on
some tooling for this.

We would need to establish exactly what criteria must be met for an
automated test to be considered as successful.

Here's a sample report that my tool produces:
https://dev.gentoo.org/~kensington/tinderbox/sys-apps/dbus/dbus-1.6.18-r1/df017e14-bd68-47e2-9738-554e7ba1cf10.html

In this case, would it be enough that it builds and tests pass? What
about the QA issues? Do we need someone to review them to determine if
they should block stabilisation, or if they're even a regression or not?

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Joshua Kinard]

On 07/25/2017 04:05, Michał Górny wrote:
> Hi, everyone.
> 
> There have been multiple attempts at grasping this but none so far
> resulted in something official and indisputable. At the same time, we
> end having to point our users at semi-official guides which change
> in unpredictable ways.
> 
> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
> 
> The basic idea is that the GLEP provides basic guidelines for using git,
> and then we write a proper manual on top of it (right now, all the pages
> about it end up as a mix of requirements and a partial git manual).
> 
> What do you think about it? Is there anything else that needs being
> covered?
> 
> Copy of the markup for inline comments follows.

I haven't seen it mentioned yet, but will this GLEP update or replace this
existing Wiki article on using git w/ Gentoo?:

https://wiki.gentoo.org/wiki/Gentoo_git_workflow

Some of the step-by-step bits in the above Wiki page look like good candidates
to be integrated into the GLEP.  It also contains guidelines on writing commit
messages, such as limiting the first line to ~50 characters, an optional body
wrapped at 75 chars/line, and including the usual git tags for sign-off and
such.  Though, I like the explicitness of the GLEP's text on a few things more.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] New eclass: opam.eclass

[Peter Stuge]

Good work on the refactoring!

Alexis Ballier wrote:
> > >   if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then  
> > 
> > It’s always been recommended to me that we should use the [[ … ]]
> > form.
> 
> Doesn't make much difference here

Some; you need neither quote nor {} in expansions within [[ ]]. So
instead of the above one could write:

if [[ -d $ED/usr/share/doc/$PF/$PN ]]; then


> and I've always been recommending the other way :p
..
> if you only do ebuilds or bash, then you don't care, but I definitely
> do other scripts

Be that as it may this is an eclass, and I think conforming to an
established coding style has significant value. I too have understood
that to be [[ ]].


Thanks

//Peter

[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

[Michael Palimaka]

On 07/25/2017 06:05 PM, Michał Górny wrote:
> Hi, everyone.
> 
> There have been multiple attempts at grasping this but none so far
> resulted in something official and indisputable. At the same time, we
> end having to point our users at semi-official guides which change
> in unpredictable ways.
> 
> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git

This looks really nice, thanks for working on it.

> * When doing a minor change to a large number of packages, it is
> reasonable to do so in a single commit. However, when doing a major
> change (e.g. a version bump), it is better to split commits on package
> boundaries.

In some cases we do prefer to make major changes on a set of related
package all in one commit. For example, we always bump the 240+ KDE
Applications collection together because that's how it's released.

> ===Commit messages===
> A standard git commit message consists of three parts, in order: a
> summary line, an optional body and an optional set of tags. The parts
> are separated by a single empty line.
> 
> The summary line is included in the short logs (git log --
> oneline, gitweb, GitHub, mail subject) and therefore should
> provide a short yet accurate description of the change. The summary line
> starts with a logical unit name, followed by a colon, a space and a
> short description of the most important changes. If a bug is associated
> with a change, then it should be included in the summary line as
> #nn or likewise. The summary line must not exceed 69
> characters, and must not be wrapped.

Does a bug # really need to always be in the summary line? It can eat
valuable characters and tags which are pretty popular are equally valid IMO.

> ** Bug: https://bugs.gentoo.org/NN; — to
> reference a bug,
> ** Closes: https://github.com/gentoo/gentoo/pull/ ki>; — to automatically close a GitHub pull request,
> ** Fixes: https://bugs.gentoo.org/NN; —
> to indicate a fixed bug,

grepping the git log shows that 'Gentoo-bug' is much more common than
plain 'Bug'. 'Fixes' is hardly used at all, and I think it's a bit
confusing to use this for bugs as well as commits.

> a few branches on the repository, and did not maintain them. The Infra
> had to query the developers about the state of the branches and clean
> them up.

Should 'The Infra' be 'The Infra team' or just 'Infra'?

> Gentoo developers are still frequently using Gentoo-Bug tag,
> sometimes followed by Gentoo-Bug-URL. Using both
> simultaneously is meaningless (they are redundant), and using the former
> has no advantages over using the classic #nn form in the
> summary or the body.

I agree that using both is redundant, but I don't agree with
discouraging or banning the use of 'Gentoo-bug'. If someone prefers to
use it so it sits nicely with the other tags why stop them?

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michael Orlitzky]

On 07/25/2017 07:52 AM, Michał Górny wrote:
> 
> I have no clue what you mean. I'm just saying that if you push 10
> changes in 10 commits, you don't have to go straight to -r10 in a
> single push.
> 

Exactly. Do that instead of hoping that no one checks out your
intermediate commits. There's no limit to the number of revisions we can
have, and trying to keep track of when it's safe to push in your head is
asking for trouble.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 13:54 +0200, Michał Górny escribió:
> Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos  napisał(a):
> > El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> > > On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
> > > > 
> > > > I hold a perhaps radical view: I would like to simply remove
> > 
> > stable.
> > > > 
> > > > [snip]
> > > > 
> > > > I consider dev time a precious resource.
> > > 
> > > If we were to drop stable I would have to start maintaining my own
> > > stable lists to determine what would be ready to into production for
> > 
> > my
> > > company. In production "works most of the time" and "good enough"
> > > simply aren't good enough.
> > > 
> > > I estimate that would at least equal the amount of time I'm currently
> > > spending on Gentoo work, and consequently my contributions to Gentoo
> > > would dwindle to a halt. Most likely I would start looking at other
> > > solutions altogether.
> > > 
> > > > More troubleshooting and fixing "hard" problems, less routine work.
> > > 
> > > Except that some of that routine work is actually what I enjoy doing
> > 
> > in
> > > Gentoo. I already get plenty of the other two in my day job.
> > > 
> > > Hans
> > 
> > If stable goes away I will simply switch to other distribution and
> > retire
> 
> What's the "over my dead commit access" spirit? 
> 

Jumping from trying to maintain stable tree to arches dead for ages to drop all
stable trees looks to me like a joke promoted by people that has never handled
any stabilization request and saw on them how running a pure "testing" system is
impossible on many conditions. It seems that some people think that if it fits
ok for them, it will fit for all others like we were all using Gentoo for doing
the same.

I could of course deal with things in my personal computer like, for example,
needing to run gcc-6 (current testing) and having tons of packages failing to
build, or run python-3.6 with only a few subset of packages, or running latest
ffmpeg with random packages going to fail with it, or many other issues that
anyone doing some stabilization work would have noticed. But, of course, I
cannot pretend that all the people using Gentoo systems for working or doing
something productive and that for now rely on me for maintaining or helping them
with the issues that could arise, will now be also forced to run systems that
are likely going to break in different and new ways every time they pretend to
update.

I am also really surprised to see how we can jump from some people that were
fighting in the past against we running automatic scripts that already existed
to fill stabilization bug reports and CC arches after timeouts, to a new
situation of "oh, testing tree is good enough for all the people". We will jump
for some people asking for things like doing deeper tests runs for packages
going to stable (at a level that was really unfeasible on a large scale) to a
situation in that nothing (even no compile test) will be checked at all.

Additionally, this will also cause new issues between people that were used to
run "testing" in the way they are running it now and they pushing to unmask
things faster and, others used to "stable", pushing to keep more things hard
masked until they are fixed. It's not the first time that we see that, for
example, a new glibc version is unmasked when maintainer feels it's ready to
allow people to catch the bugs before it going to be stable. If we have no
stable tree, that couldn't be done as we couldn't use "testing" for the purpose
of "lets unmask X package it give it more visibility and let people catch the
bugs". Then, either we keep breaking "testing" even knowing there is no stable,
or we will start getting lots of packages in package.mask leading to new issues
(like those packages having less visibility and fights between people thinking
that a mid breakage is ok and others that not).

Then, in my case it will be as simply as, if Gentoo becomes testing only, I
won't be able to use it for anything productive, only for "playing" with it...
and then, I won't see much sense on staying while I will need to use a different
distribution de facto for the work and any computer that is not the laptop I use
for committing and doing Gentoo dev work.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michał Górny]

Dnia 25 lipca 2017 11:18:21 CEST, Pacho Ramos  napisał(a):
>El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
>> On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
>> > 
>> > I hold a perhaps radical view: I would like to simply remove
>stable.
>> > 
>> > [snip]
>> > 
>> > I consider dev time a precious resource.
>> 
>> If we were to drop stable I would have to start maintaining my own
>> stable lists to determine what would be ready to into production for
>my
>> company. In production "works most of the time" and "good enough"
>> simply aren't good enough.
>> 
>> I estimate that would at least equal the amount of time I'm currently
>> spending on Gentoo work, and consequently my contributions to Gentoo
>> would dwindle to a halt. Most likely I would start looking at other
>> solutions altogether.
>> 
>> > More troubleshooting and fixing "hard" problems, less routine work.
>> 
>> Except that some of that routine work is actually what I enjoy doing
>in
>> Gentoo. I already get plenty of the other two in my day job.
>> 
>> Hans
>
>If stable goes away I will simply switch to other distribution and
>retire

What's the "over my dead commit access" spirit? 


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

Dnia 25 lipca 2017 13:25:38 CEST, Michael Orlitzky  napisał(a):
>On 07/25/2017 04:05 AM, Michał Górny wrote:
>> 
>> Here's the current draft:
>> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
>> 
>
>It's mostly fine, but there are two changes I disagree with:
>
>> When doing one or more changes that require a revision bump, bump the
>> revision in the commit including the first change. Split the changes
>> into multiple logical commits without further revision bumps — since
>> they are going to be pushed in a single push, the user will not be
>> exposed to interim state.
>
>We shouldn't play games in the repo and hope that everything works out
>if we wait to push until just the right time. We're not going to run
>out
>of numbers -- it's simpler and more correct to do a new revision with
>each commit.

I have no clue what you mean. I'm just saying that if you push 10 changes in 10 
commits, you don't have to go straight to -r10 in a single push.

>
>
>> Gentoo developers are still frequently using Gentoo-Bug tag,
>> sometimes followed by Gentoo-Bug-URL. Using both simultaneously is
>> meaningless (they are redundant), and using the former has no
>> advantages over using the classic #nn form in the summary or the
>> body.
>
>There are two main advantages over having the bug number in the
>summary.
>Space is at a premium in the summary, as Tobias pointed out, and the
>
>  Gentoo-Bug: whatever
>
>format is trivially machine-readable, whereas sticking it somewhere
>else
>is less so.

Except that there is no machines using it. In all contexts, using full URL for 
machine readability is better as it works with all software out of the box.

>
>And just a reminder -- Gokturk worked to get a lot of this stuff into
>the devmanual, e.g.
>
>  https://devmanual.gentoo.org/ebuild-maintenance/index.html
>
>Some of that is important, like the warning not to use "bug #x" in the
>body of the commit message.


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Jonas Stein]

Hi everyone,

> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
> 
> The basic idea is that the GLEP provides basic guidelines for using git,
> and then we write a proper manual on top of it (right now, all the pages
> about it end up as a mix of requirements and a partial git manual).
> 
> What do you think about it? Is there anything else that needs being
> covered?

Thank you, Michał, for preparing an official guide from all the spread
informations. I think it is important for Gentoo to have such GLEP.

I think we should not bundle GLEPs to companies, but keep it more
abstract. The GLEP should still be valid, if we do not use github
anymore. Many large repositories have shut down in the last years. Even
after years we have not fixed all ebuilds [1]. We must be prepared, to
loose github very suddenly and should not hope that it will end with an
announcement years before.


Hence, I suggest to write the GLEP without naming "github" a single time.

[1] https://wiki.gentoo.org/wiki/Upstream_repository_shutdowns

-- 
Best,
Jonas

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

Dnia 25 lipca 2017 12:59:21 CEST, Tobias Klausmann  
napisał(a):
>Hi! 
>
>On Tue, 25 Jul 2017, Michał Górny wrote:
>> The summary line is included in the short logs (git log --
>> oneline, gitweb, GitHub, mail subject) and therefore should
>> provide a short yet accurate description of the change. The summary
>line
>> starts with a logical unit name, followed by a colon, a space and a
>> short description of the most important changes. If a bug is
>associated
>> with a change, then it should be included in the summary line as
>> #nn or likewise. The summary line must not exceed 69
>> characters, and must not be wrapped.
>
>This limit can be a problem if there's a nontrivial change to the
>more than 80 packages in the tree that have more than forty characters
>in
>cat/pkg[0]. Is the only option there to do word-smithing or
>making the commit summary less usefu?
>
>Or do we have a "violate if necessary" agreement regarding that?

Yeah, i meant to apply the "must not" to wrapping but "should not" to length. 
Though I suggest you to ellipsize the package name, if it is unambiguous enough.

The problem is that if you exceed the length, the summary will be usually cut 
one way or another anyway.

>
>
>Regards,
>Tobias
>
>[0] 
>$ cd /usr/portage
>$ ls -d *-*/*|awk '{if (length>=40) {print length, $0}}'|sort -n


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Tue, Jul 25, 2017 at 2:18 AM, Hans de Graaff  wrote:
>
> On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
>
> > More troubleshooting and fixing "hard" problems, less routine work.
>
> Except that some of that routine work is actually what I enjoy doing in
> Gentoo. I already get plenty of the other two in my day job.
>

This goes to a principle of volunteer work - you can't really direct
the work of volunteers (at least not with anything close to 100%
efficiency).  If you tell a volunteer they aren't allowed to work on
x, that doesn't mean that the time they used to spend on x is now
available to the organization to work on higher priority projects.  It
just means that they won't work on x any longer.

If a volunteer wanted to be working on something they considered
higher priority, they would probably already be doing it, or they
would be the ones looking for somebody to take over the lower priority
jobs.

Paid work is an entirely different matter, because the project most
employees are really working on is the "collect a paycheck" project
and what they do to collect it tends to be secondary.  That obviously
isn't 100% the case and if you're trying to retain the next Elon Musk
the rules are different, but it holds for most normal work.

So, don't assume you can fix manpower problems by delivering less.
You might be able to fix them by relaxing rules so that you can
deliver the same with less effort, but keep in mind whether those
rules added some kind of value to the final product.

-- 
Rich

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michael Orlitzky]

On 07/25/2017 04:05 AM, Michał Górny wrote:
> 
> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
> 

It's mostly fine, but there are two changes I disagree with:

> When doing one or more changes that require a revision bump, bump the
> revision in the commit including the first change. Split the changes
> into multiple logical commits without further revision bumps — since
> they are going to be pushed in a single push, the user will not be
> exposed to interim state.

We shouldn't play games in the repo and hope that everything works out
if we wait to push until just the right time. We're not going to run out
of numbers -- it's simpler and more correct to do a new revision with
each commit.


> Gentoo developers are still frequently using Gentoo-Bug tag,
> sometimes followed by Gentoo-Bug-URL. Using both simultaneously is
> meaningless (they are redundant), and using the former has no
> advantages over using the classic #nn form in the summary or the
> body.

There are two main advantages over having the bug number in the summary.
Space is at a premium in the summary, as Tobias pointed out, and the

  Gentoo-Bug: whatever

format is trivially machine-readable, whereas sticking it somewhere else
is less so.

And just a reminder -- Gokturk worked to get a lot of this stuff into
the devmanual, e.g.

  https://devmanual.gentoo.org/ebuild-maintenance/index.html

Some of that is important, like the warning not to use "bug #x" in the
body of the commit message.

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Tobias Klausmann]

Hi! 

On Tue, 25 Jul 2017, Michał Górny wrote:
> The summary line is included in the short logs (git log --
> oneline, gitweb, GitHub, mail subject) and therefore should
> provide a short yet accurate description of the change. The summary line
> starts with a logical unit name, followed by a colon, a space and a
> short description of the most important changes. If a bug is associated
> with a change, then it should be included in the summary line as
> #nn or likewise. The summary line must not exceed 69
> characters, and must not be wrapped.

This limit can be a problem if there's a nontrivial change to the
more than 80 packages in the tree that have more than forty characters in
cat/pkg[0]. Is the only option there to do word-smithing or
making the commit summary less usefu?

Or do we have a "violate if necessary" agreement regarding that?


Regards,
Tobias

[0] 
$ cd /usr/portage
$ ls -d *-*/*|awk '{if (length>=40) {print length, $0}}'|sort -n


-- 
Sent from aboard the Culture ship
GSV Of Course I Still Love You

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Pacho Ramos]

El mar, 25-07-2017 a las 08:18 +0200, Hans de Graaff escribió:
> On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
> > 
> > I hold a perhaps radical view: I would like to simply remove stable.
> > 
> > [snip]
> > 
> > I consider dev time a precious resource.
> 
> If we were to drop stable I would have to start maintaining my own
> stable lists to determine what would be ready to into production for my
> company. In production "works most of the time" and "good enough"
> simply aren't good enough.
> 
> I estimate that would at least equal the amount of time I'm currently
> spending on Gentoo work, and consequently my contributions to Gentoo
> would dwindle to a halt. Most likely I would start looking at other
> solutions altogether.
> 
> > More troubleshooting and fixing "hard" problems, less routine work.
> 
> Except that some of that routine work is actually what I enjoy doing in
> Gentoo. I already get plenty of the other two in my day job.
> 
> Hans

If stable goes away I will simply switch to other distribution and retire

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Agostino Sarubbo]

Hello Sergei,

thanks to bring into the topic which nowadays is a common point of discussion 
:)


On Monday 24 July 2017 22:22:23 Sergei Trofimovich wrote:
> 1. lack of automation
I'd summarize the techical steps into:
1) get the list of packages
2) test
3) commit to git
4) write on bugzilla

1 is done by getatoms https://github.com/kensington/bugbot
2 is done by the tester in the manner he prefer
3 no official tool available, I used a modified version of 
https://gitweb.gentoo.org/proj/arch-tools.git/tree/batch-stabilize.py which is 
still based on CVS
4 no official tool available, I used my own bash script which calls pybugz

So, points 3 and 4 needs to be improved, I have the idea on how the script 
should look, but I have no time to do it and no python knowledge. I can assist 
everyone that candidate itself to make the tool/script like I did with 
kensington when he made getatoms.

> 2. lack of manpower

lack of manpower, so in my opinion reduce a bit the workload. I proposed 
something in one of my last mail to -dev, the following refers to the arches 
with very less manpower:
1) Don't file keywordreq, since noone work on them. File directly stablereq.
2) Reduce the number of the stable packages on those arches
3) Make a more visible list (like this list in term of 
visibility:https://qa-reports.gentoo.org/output/gentoo-ci/output.html) of the 
arches-dependent bugs so that everyone can contribute to maintain alive the 
exotic arches.

-- 
Agostino Sarubbo
Gentoo Linux Developer

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Dirkjan Ochtman]

On Tue, Jul 25, 2017 at 10:05 AM, Michał Górny  wrote:

> What do you think about it? Is there anything else that needs being
> covered?
>

Looks good to me. Thanks for writing it up!

Cheers,

Dirkjan

Re: [gentoo-dev] New eclass: opam.eclass

[Alexis Ballier]

On Mon, 24 Jul 2017 18:11:39 -0400
"Aaron W. Swenson"  wrote:

> On 2017-07-24 17:20, Alexis Ballier wrote:
> > Hey,
> > 
> > Here is an eclass that would allow me to factor quite a bit of
> > redundant code.
> > 
> > …
> > if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then  
> 
> It’s always been recommended to me that we should use the [[ … ]]
> form.

Doesn't make much difference here and I've always been recommending the
other way :p
(the idea is that you don't get to write the [[ ]] in a /bin/sh script
just because you're used to it; if you only do ebuilds or bash, then
you don't care, but I definitely do other scripts)

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Nicolas Bock]

On Tue, Jul 25, 2017 at 10:05:06AM +0200, Michał Górny wrote:

Hi, everyone.

There have been multiple attempts at grasping this but none so far
resulted in something official and indisputable. At the same time, we
end having to point our users at semi-official guides which change
in unpredictable ways.

Here's the current draft:
https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git

The basic idea is that the GLEP provides basic guidelines for using git,
and then we write a proper manual on top of it (right now, all the pages
about it end up as a mix of requirements and a partial git manual).

What do you think about it? Is there anything else that needs being
covered?


I like it. +1


Copy of the markup for inline comments follows.



--
Nicolas Bock 


signature.asc
Description: PGP signature

[gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Michał Górny]

Hi, everyone.

There have been multiple attempts at grasping this but none so far
resulted in something official and indisputable. At the same time, we
end having to point our users at semi-official guides which change
in unpredictable ways.

Here's the current draft:
https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git

The basic idea is that the GLEP provides basic guidelines for using git,
and then we write a proper manual on top of it (right now, all the pages
about it end up as a mix of requirements and a partial git manual).

What do you think about it? Is there anything else that needs being
covered?

Copy of the markup for inline comments follows.

---

{{GLEP
|Number=xx
|Title=Gentoo Git Workflow
|Type=Standards Track
|Status=Draft
|Author=Michał Górny 
}}

==Abstract==
This GLEP specifies basic standards and recommendations for using git
with the Gentoo ebuild repository. It covers only Gentoo-specific
policies, and is not meant to be a complete guide.

==Motivation==
Although the main Gentoo repository is using git for two years already,
developers still lack official documentation on how to use git
consistently. Most of the developers learn spoken standards from others
and follow them. This eventually brings consistency to some extent but
is suboptimal. Furthermore, it results in users having to learn things
the hard way instead of having proper documentation to follow.

There were a few attempts to standardize git use over the time. Most
noteworthy are [[Gentoo git workflow]] and [[Gentoo GitHub]] articles.
However, they are not any kind of official standards, and they have too
broad focus to become one. There was also an initial GLEP attempt but it
never even reached the draft stage.

This GLEP aims to finally provide basic standardization for the use of
git in the Gentoo repository. It aims to focus purely on Gentoo-specific 
standards and not git usage in general. It doesn't mean to be a complete
guide but a formal basis on top of which official guides could be
created.

==Specification==
===Branching model===
The main branch of the Gentoo repository is the master
branch. All Gentoo developers push their work straight to the master
branch, provided that the commits meet the minimal quality standards.
The master branch is also used straight for continous user repository
deployment.

Since multiple developers work on master concurrently, they may be
required to rebase multiple times before being able to push. Developers
are requested not to use workflows that could prevent others from
pushing, e.g. pushing single commits frequently instead of staging them
and using a single push.

Developers can use additional branches to facilitate review and testing
of long-term projects of larger scale. However, since git fetches all
branches by default, they should be used scarcely. For smaller projects,
local branches or repository forks are preferred.

Unless stated otherwise, the rules set by this specification apply to
the master branch only. The development branches can use relaxed rules.

Rewriting history (i.e. force pushes) of the master branch is forbidden.

===Merge commits===
The use of merge commits in the Gentoo repository is strongly
discouraged. Usually it is preferable to rebase instead. However, the
developers are allowed to use merge commits in justified cases. Merge
commits can be only used to merge additional branches, the use of
implicit git pull merges is entirely forbidden.

In a merge commit that is committed straight to the Gentoo repository,
the first parent is expected to reference an actual Gentoo commit
preceding the merge, while the remaining parents can be used to
reference external repositories. The commits following the first parent
are required to conform to this specification alike regular Gentoo
commits. The additional commits following other parents can use relaxed
rules.

===OpenPGP signatures===
Each commit in the Gentoo repository must be signed using the
committer's OpenPGP key. Furthermore, each push to the repository must
be signed using the key belonging to the developer performing the push
(matched via the SSH key).

The requirements for OpenPGP keys are covered by [[GLEP:63|GLEP 63]].

===Splitting commits===
Git commits are lightweight, and the developers are encouraged to split
their commits to improve readability and the ability of reverting
specific sub-changes. When choosing how to split the commits, the
developers should consider the following three rules:
# Use atomic commits — one commit per logical change.
# Split commits at logical unit (package, eclass, profile…) boundaries.
# Avoid creating commits that are 'broken' — e.g. are incomplete, have
uninstallable packages.

It is technically impossible to always respect all of the three rules,
so developers have to balance between them at their own discretion. Side
changes that are implied by other change (e.g. revbump due to some
change) should be included in the first commit requiring 

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Sergei Trofimovich]

On Mon, 24 Jul 2017 23:22:44 +
Peter Stuge  wrote:

> Thank you for working on this.
> 
> Sergei Trofimovich wrote:
> > Can this proposal make a difference and make gentoo better and
> > easier to work with?
> > 
> > Does it try to attack the right thing?
> > 
> > Does it completely miss the point?  
> 
> I hold a perhaps radical view: I would like to simply remove stable.
> 
> I continue to feel that maintaining two worlds (stable+unstable)
> carries with it an unneccessary cost.
> 
> Based solely on how excellently unstable (and similar approaches before
> using Gentoo) works for me in practice, I believe that skipping stable
> and instead focusing efforts on resolving problems reported in unstable
> a little quicker would yield a much better end result - and would net
> positive dev time.

Good point.

Stable is used by Gentoo to guard against wide-spread bugs sneaking
into everyone's systems: SIGSEGVing bootloaders (hard to recover),
crashing at startup browsers (hard to find a safe point to rollback),
hosed toolchains (hard to diagnose in time), widespread build breakages
due to incompatible API (or ABI) changes upstream (hard to recover).

It takes time to identify and devise mitigation for new issues. What
would be the mitigation mechanisims for those when we know something
is broken? Currently we say STABLE should work better as packages
there had wider and longer testing.

Why would removing stable speed things up?
Due to smaller amount of bugs to deal with?

Do you think Gentoo needs KEYWORDS at all?

Should packages be tracked as "seemingly working" on the arch
or package.mask is enough?

> > Does it sound fun?  
> 
> Sorry, no, not to me. It sounds like "double" overhead. :\
> 
> 
> I consider dev time a precious resource. Devs should need to do as
> few things as possible, to keep things going, and should be able to
> immediately reuse as much input from the wider community as possible.
> 
> More troubleshooting and fixing "hard" problems, less routine work.

Can you clarify what exactly you see currently as a routine work
on the dev side WRT stable?

Fixing bugs for non-latest packages?
Tracking manually lists for stabilization?
Something else?

Thanks!

-- 

  Sergei


pgpWykn18E81f.pgp
Description: Цифровая подпись OpenPGP

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Dirkjan Ochtman]

On Mon, Jul 24, 2017 at 11:22 PM, Sergei Trofimovich 
wrote:

> TL;DR;TL;DR:
> 
>
> This email seeks for one step towards less toil tied to gentoo's
> keywording/stabilization process. I've CCed a few groups who
> might be interested in making this area better:
>
> - gentoo-dev@ as it affects most devs (and non-devs!)
> - wg-stable@ as it overlaps quite a bit with efforts staged on STABLEREQ
>   (should I join? :)
> - arch-leads@ as it directly helps (or breaks everything for) arch teams
> - all individual arches for wider visibility
>

Thanks for kicking off this discussion. As a stable user, this is an
important topic to me.

Your email is kind of long, and I wonder if we can condense the problem
back to simpler first principles.

First, the assumption in our processes seems to be that many or important
bugs will be due to architecture-specific differences, and I wonder if that
assumption really holds up. Do arch testers for a smaller arch often find
problems that were not noticed on one of the larger arches? With the
languages and tools that we have today, it seems like for many of our
packages, bugs due to architectural differences represent a minority of the
problems we found. In this case, the whole idea of per-arch stabilization
does not really make sense, and doing away with that idea could drastically
shortcut our process.

Second, I believe a lot of the value in our stable tree comes *just* from
the requirement that stabilization is only requested after 30 days without
major bugs/changes in the unstable tree. Assuming there are enough users of
a package on unstable, that means important bugs can be shaken out before a
version hits stable. This could mean that potentially, even if we inverted
our entire model to say we "automatically" stabilize after a 30-day period
without major bugs, we hit most of the value of the stable tree with again
drastically reduced pain/work.

Cheers,

Dirkjan

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Hans de Graaff]

On Tue, 2017-07-25 at 04:34 +, Duncan wrote:
> 
> Automating stabilization and automated keyword dropping on timeouts
> seems 
> the only other practical choice, as unfortunately, "stale" is what
> we 
> have today in practice, if not in name.

Looking at https://repology.org/statistics stable isn't quite that
stale compared to other distributions. We're not doing great either, so
we should certainly try to improve.

Hans

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Hans de Graaff]

On Mon, 2017-07-24 at 23:22 +, Peter Stuge wrote:
> 
> I hold a perhaps radical view: I would like to simply remove stable.
> 
> [snip]
> 
> I consider dev time a precious resource.

If we were to drop stable I would have to start maintaining my own
stable lists to determine what would be ready to into production for my
company. In production "works most of the time" and "good enough"
simply aren't good enough.

I estimate that would at least equal the amount of time I'm currently
spending on Gentoo work, and consequently my contributions to Gentoo
would dwindle to a halt. Most likely I would start looking at other
solutions altogether.

> More troubleshooting and fixing "hard" problems, less routine work.

Except that some of that routine work is actually what I enjoy doing in
Gentoo. I already get plenty of the other two in my day job.

Hans

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] vim-syntax USE flag

[Hans de Graaff]

On Mon, 2017-07-24 at 12:10 +0200, Ulrich Mueller wrote:
> 
> Similarly, if we get rid of the vim-syntax flag, should we phase out
> the emacs USE flag, too?

I would say no because in almost all cases the emacs code needs to be
compiled and that requires emacs to be present.

As far as I understand installing a vim syntax file does not require
compilation and can therefore be done without having vim on the system.

Hans

signature.asc
Description: This is a digitally signed message part