Hello,
Ludovic Courtès skribis:
> With the proposed policy, members of a team would also have to review
> and approve each other’s work. Formal approval means getting an
> explicit “LGTM” (or similar) from at least one other team member.
I think it’s fair to say that there was no consensus on
Hi Ludovic,
Ludovic Courtès writes:
> Hello!
>
> Maxim Cournoyer skribis:
>
> [...]
>
>>> “Pacify” in the sense that, by being explicit, we avoid
>>> misunderstandings that could turn into unpleasant experiences.
>>>
>>> Like you I’m glad collaboration is nice and friendly; yet, over the past
>
Hello!
Maxim Cournoyer skribis:
[...]
>> “Pacify” in the sense that, by being explicit, we avoid
>> misunderstandings that could turn into unpleasant experiences.
>>
>> Like you I’m glad collaboration is nice and friendly; yet, over the past
>> few months I’ve experienced misunderstandings that
Hi,
Peter Polidoro writes:
> There is a phenomenon in manufacturing quality control where sometimes
> adding inspectors decreases the number of defects that get past
> inspection unnoticed, because one inspector catches a defect that
> another inspector missed, but other times the number of unno
There is a phenomenon in manufacturing quality control where
sometimes adding inspectors decreases the number of defects that
get past inspection unnoticed, because one inspector catches a
defect that another inspector missed, but other times the number
of unnoticed defects actually goes UP, pr
Hi Andreas,
Andreas Enge writes:
> Hello,
>
> Am Sat, Mar 11, 2023 at 10:26:18PM -0500 schrieb Maxim Cournoyer:
>> Ludovic Courtès writes:
>> > I hope the maintainer team can help make teams “more functional”,
>> > whatever that teams. It’s really what maintainership is about in Guix;
>> > it’
Hi Maxim,
On Sat, 11 Mar 2023 at 22:26, Maxim Cournoyer wrote:
> I'm sorry that you feel that way. I don't think consensus was willfully
> broken, and perhaps by studying some actual examples of these
> occurrences we can better understand what went wrong and how the new
> suggested policy woul
Hello,
Am Sat, Mar 11, 2023 at 10:26:18PM -0500 schrieb Maxim Cournoyer:
> Ludovic Courtès writes:
> > I hope the maintainer team can help make teams “more functional”,
> > whatever that teams. It’s really what maintainership is about in Guix;
> > it’s not about writing code.
> I'm happy to help
Hi,
On Sat, 11 Mar 2023 at 21:33, Maxim Cournoyer wrote:
> It may help to shed a bit of light on the original reason I think this
> change came into existence, and in the interest of transparency and
> hopefully improving or finding alternatives to the proposed change, I
> consent to Ludovic ope
Hi Ludovic,
Ludovic Courtès writes:
> Hello Maxim and all!
>
> Maxim Cournoyer skribis:
>
>>> With the proposed policy, members of a team would also have to review
>>> and approve each other’s work. Formal approval means getting an
>>> explicit “LGTM” (or similar) from at least one other team
Hi Felix,
Felix Lechner writes:
> Hi Ludo',
>
> On Fri, Mar 10, 2023 at 9:22 AM Ludovic Courtès wrote:
>>
>> Like you I’m glad collaboration is nice and friendly; yet, over the past
>> few months I’ve experienced misunderstandings that seemingly broke the
>> consensus-based process that has alw
Hi,
On Sat, 11 Mar 2023 at 00:19, Andreas Enge wrote:
> In the longer run I also agree with (b). But I am not sure it will be easy
> to formulate a rule that captures well the intended policy and draws the
> line between "trivial", anybody can push any time, and "complex", where more
> opinions
Am Fri, Mar 10, 2023 at 06:33:58PM +0100 schrieb Simon Tournier:
> However, for some packages or changes, the impact is far from being
> trivial. I have in mind many changes that happen aside gnu/packages and
> also some core packages (Guile, etc.).
> For these kind of changes, it does not appear
Hi Ludo',
On Fri, Mar 10, 2023 at 9:22 AM Ludovic Courtès wrote:
>
> Like you I’m glad collaboration is nice and friendly; yet, over the past
> few months I’ve experienced misunderstandings that seemingly broke the
> consensus-based process that has always prevailed.
I have no idea what happened
Hi Andreas,
Re-reading the thread, I think we started with different frames. :-)
On ven., 10 mars 2023 at 15:19, Andreas Enge wrote:
> while I am sensitive to your argument about privileges, I am afraid that
> the suggestion would remove privileges from the committers, while not
> bestowing th
Hello Maxim and all!
Maxim Cournoyer skribis:
>> With the proposed policy, members of a team would also have to review
>> and approve each other’s work. Formal approval means getting an
>> explicit “LGTM” (or similar) from at least one other team member.
>
> In other words, to give teams the po
Hello Simon,
Am Thu, Mar 09, 2023 at 10:46:08AM +0100 schrieb Simon Tournier:
> Hierarchy already exists, as in any social group, as in any group of
> people collaborating. The hierarchy is currently informal.
while I am sensitive to your argument about privileges, I am afraid that
the suggestio
Hi Simon et al.,
Simon Tournier writes:
> Hi Maxim,
>
> On Wed, 08 Mar 2023 at 12:05, Maxim Cournoyer
> wrote:
>
>> On a side note, it would also introduce some kind of hierarchy in the
>> group, which I dislike. One of the things that make Guix special is
>> that it's pretty flat -- everybod
Hi,
On Wed, 08 Mar 2023 at 13:58, Maxim Cournoyer wrote:
> number of their R package updates (thanks!)). It seems starting to use
> the 'Reviewed-by' git message tag would make this easy to account for.
Quoting from thread [1]:
I agree that Reviewed-by would be helpful.
Once
Hi Maxim,
On Wed, 08 Mar 2023 at 12:05, Maxim Cournoyer wrote:
> On a side note, it would also introduce some kind of hierarchy in the
> group, which I dislike. One of the things that make Guix special is
> that it's pretty flat -- everybody can participate at the same level, at
> least between
Hi,
Vagrant Cascadian writes:
[...]
> I almost wonder if it wouldn't be good to spell out what exactly is
> desired to be accomplished by having teams? Maybe much of that
> conversation has already happened, but ... spelling it out first, and
> then trying to come up with implementation details
On 2023-03-08, Maxim Cournoyer wrote:
> On a side note, it would also introduce some kind of hierarchy in the
> group, which I dislike. One of the things that make Guix special is
> that it's pretty flat -- everybody can participate at the same level, at
> least between committers). I'd rather we
Hi Leo,
Leo Famulari writes:
[...]
> In release announcements, alongside to the the normal `git shortlog`
> list of authors, I suggest also publicizing the list of committers:
>
> `git shortlog --numbered --summary --committer v1.4.0..HEAD`
>
> A small thing, but hopefully one of many incentive
Hi Efraim,
Efraim Flashner writes:
> On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote:
>> Hi Simon,
>>
>> Simon Tournier writes:
>>
>> > Hi,
>> >
>> > On Tue, 07 Mar 2023 at 11:36, Andreas Enge wrote:
>> >
>> >> 1) Every current and potential new package is covered by a team.
On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote:
> Hi Simon,
>
> Simon Tournier writes:
>
> > Hi,
> >
> > On Tue, 07 Mar 2023 at 11:36, Andreas Enge wrote:
> >
> >> 1) Every current and potential new package is covered by a team.
> >> 2) Every team has at least 3 members, better
I don't have a strong opinion one way or the other about whether we
should formalize the review process. The status quo isn't working well,
so I'm in favor of trying something.
On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote:
> I think the main problem we have is social, not organi
Hi Simon,
Simon Tournier writes:
> Hi,
>
> On Tue, 07 Mar 2023 at 11:36, Andreas Enge wrote:
>
>> 1) Every current and potential new package is covered by a team.
>> 2) Every team has at least 3 members, better yet 4 or 5.
>>3 members would make it possible that even if one of them is on va
Hi,
On Tue, Mar 7, 2023 at 2:37 AM Andreas Enge wrote:
>
> And the feature branches with
> QA on cuirass or the Guix Build Coordinator that we talked about at the
> Guix Days.
For what it's worth, someone turned one of my patch sets into a
proof-of-concept for feature branches. You can follow th
Hi,
On Tue, 07 Mar 2023 at 11:36, Andreas Enge wrote:
> 1) Every current and potential new package is covered by a team.
> 2) Every team has at least 3 members, better yet 4 or 5.
>3 members would make it possible that even if one of them is on vacation
>or otherwise busy a patch could b
Hello,
Am Tue, Mar 07, 2023 at 09:53:29AM +0800 schrieb 宋文武:
> I usually push patches for others who don't have commit access, while
> most packages don't have a team at all, and some with me as the only
> team member.
> Should I wait for another commiter's approvol under this new policy or
> can
Ludovic Courtès writes:
> Hi Chris,
>
> Christopher Baines skribis:
>
>> Regarding this change specifically though, I'm unclear how it would
>> impact the things I push for others. I pushed some patches today, would
>> this mean that I'd have to look at what team/teams are involved
>> (according
Hi,
Maxim Cournoyer skribis:
> It sounds reasonable and a good change "on paper", but in practice I
> think it may be too soon to formalize teams that way. Teams are a
> nascent concept which hasn't reached a point we can rely on it, in my
> opinion. We are still ironing out kinks in the tools
Hi Ludovic,
Ludovic Courtès writes:
> Hello Guix!
>
> The project has been steadily gaining new contributors, which is great,
> and I think we need to adjust our processes accordingly.
>
> Currently teams are described mostly as pools of people who can mentor
> contributors in a particular area
Andreas Enge writes:
> Hello,
>
> in the current situation I think the suggestion is putting the horse before
> the cart. In a first step before adding policy, we should make the teams
> functional.
I find debian have various teams, and each team has a page for packages
status: https://tracker.d
Hi,
tl;dr:
If you want to expand the list of committers rapidly,
would it make sense to have a sand-box repo for new committers
which trusted committers could channel cherry-picks from?
Pick your bugaboo, but I consider plausible that some
volunteering committers are there on p
Hello,
in the current situation I think the suggestion is putting the horse before
the cart. In a first step before adding policy, we should make the teams
functional. While working on core-updates, I have been realising we are
already spread too thin: Some important languages have teams with one
Hi,
On Wed, Mar 1, 2023 at 9:31 AM Christopher Baines wrote:
>
> I'm unclear how it would
> impact the things I push for others. I pushed some patches today, would
> this mean that I'd have to look at what team/teams are involved
> (according to /etc/teams.scm.in) for each commit/series, and then
Hi Chris,
Christopher Baines skribis:
> I guess I'm still a team sceptic, I think the idea is interesting and I
> have added myself as a member of some teams. But the main impact on me
> so far is that I've just been getting some unwanted personal email,
> messages that previously wouldn't have
Björn Höfling writes:
> On Wed, 01 Mar 2023 17:15:26 +
> Christopher Baines wrote:
>
>> I guess I'm still a team sceptic, I think the idea is interesting and
>> I have added myself as a member of some teams. But the main impact on
>> me so far is that I've just been getting some unwanted pe
On Wed, 01 Mar 2023 17:15:26 +
Christopher Baines wrote:
> I guess I'm still a team sceptic, I think the idea is interesting and
> I have added myself as a member of some teams. But the main impact on
> me so far is that I've just been getting some unwanted personal email,
> messages that p
Ludovic Courtès writes:
> Currently teams are described mostly as pools of people who can mentor
> contributors in a particular area and who can review patches in that
> area. My proposal is to give teams formal approval power over changes
> to code in their area.
>
> This is sorta happening al
Hello Guix!
The project has been steadily gaining new contributors, which is great,
and I think we need to adjust our processes accordingly.
Currently teams are described mostly as pools of people who can mentor
contributors in a particular area and who can review patches in that
area. My propos
42 matches
Mail list logo
