Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted:
> ==Backwards Compatibility==
> Most of the new policy will apply to the commits following its approval.
> Backwards compatibility is not relevant there.
s/Backwards/Backward/ (both header and body)
"Backwards" is a
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted:
> ===Commit messages===
[...]
> Historically, Gentoo has been using a few tags starting with X-
> . However, this practice was abandoned once it has been pointed
> out that git does not enforce any standard set of tags, and
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted:
> ===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
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted:
> ==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
Michał Górny posted on Tue, 25 Jul 2017 10:05:06 +0200 as excerpted:
> ==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
On śro, 2017-07-26 at 19:05 +0200, Kristian Fiskerstrand wrote:
> On 07/25/2017 02:28 PM, Michael Palimaka wrote:
> > 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.
>
> I would prefer the
On 07/26/2017 10:05 AM, Kristian Fiskerstrand wrote:
> On 07/25/2017 02:28 PM, Michael Palimaka wrote:
>> 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.
>
> I would prefer the summary to be
On Wed, Jul 26, 2017 at 07:05:47PM +0200, Kristian Fiskerstrand wrote:
> On 07/25/2017 02:28 PM, Michael Palimaka wrote:
> > 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.
>
> I would prefer
On 07/25/2017 02:28 PM, Michael Palimaka wrote:
> 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.
I would prefer the summary to be informative without having bug ID at
all. Summary should describe
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
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.
11 matches
Mail list logo
