On Mon, Sep 25, 2017 at 09:03:00PM +0200, Tobias Mueller wrote:
> Hi.
>
> On Mi, 2017-05-17 at 14:21 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote:
> > > By attaching a patch to a bugtracker ticket, we loose the information of
> > >
On Mon, Sep 25, 2017 at 09:03:00PM +0200, Tobias Mueller wrote:
> On Mi, 2017-05-17 at 14:21 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote:
> > > By attaching a patch to a bugtracker ticket, we loose the information of
> > > the
Hi.
On Mi, 2017-05-17 at 14:21 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote:
> > By attaching a patch to a bugtracker ticket, we loose the information of
> > the parent commit: where the commit has been initially created in the
> >
On Sat, Jun 17, 2017 at 11:29 PM Florian Müllner
wrote:
> I hope that subscribers to an issue will receive a notification when a
> mentioned issue is closed
>
To answer my own question: It looks like that's not the case, so anyone
interested will need to explicitly
On Sat, Jun 17, 2017 at 4:48 PM Michael Catanzaro
wrote:
> I think we had
> some rough consensus on this list that the primary missing enterprise
> feature we need in the open source edition is rebase-style merge
> requests. Was there anything else?
>
It looks like
At the risk of reopening this debate, here's an interesting LWN article
about why Debian has rejected a proposed move to GitLab:
https://lwn.net/SubscriberLink/724986/c26a7fab6ab5981b/
(For those unfamiliar with LWN, the subscriber link is just to allow
you to bypass the paywall.)
It looks
On Wed, May 17, 2017 at 02:21:55PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote:
> > By attaching a patch to a bugtracker ticket, we loose the information of
> > the parent commit: where the commit has been initially created in the
>
Hey Felipe,
What is that you are no fan of in the merge request workflow? Would a command
line application thay works similarly to git bz fox these issues?
Regarding useless forks, why is that a problem? (Definitely something to take
care on our infra though if it grows too big)
Cheers
On Tue, May 23, 2017 at 2:13 PM, Adrian Perez de Castro
wrote:
> Hi there,
>
> No strong opinion here about GitLab, just a comment below...
>
> On Tue, 23 May 2017 11:21:25 +0200, Felipe Borges
> wrote:
>
>> [...]
>>
>> Cons:
>> - not a big fan of
On Tue, 2017-05-23 at 15:13 +0300, Adrian Perez de Castro wrote:
> Hi there,
>
> No strong opinion here about GitLab, just a comment below...
>
> On Tue, 23 May 2017 11:21:25 +0200, Felipe Borges il.com> wrote:
>
> > [...]
> >
> > Cons:
> > - not a big fan of the
Hi there,
No strong opinion here about GitLab, just a comment below...
On Tue, 23 May 2017 11:21:25 +0200, Felipe Borges
wrote:
> [...]
>
> Cons:
> - not a big fan of the merge-request workflow
> - we will have a bunch of useless forks across the users' accounts
I
On Mon, 2017-05-22 at 11:50 +0100, Philip Withnall wrote:
> I would also be supportive of a solution using Phabricator+cgit. Phab
> for task management and patch review, since its task management is
> more
> powerful than gitlab’s, and its patch review workflow doesn’t have
> the
> problems of
On Tue, 2017-05-23 at 11:21 +0200, Felipe Borges wrote:
>
> +1: I am supportive of the initiative.
>
> After catching up with the discussion, my personal pros and cons are:
>
> Pros:
>
> - code browsing is better than cgit
Seeing the history of a single file is unfortunately much harder than
On Tue, May 23, 2017 at 11:00 AM, Milan Crha wrote:
> On Thu, 2017-05-18 at 15:12 -0500, mcatanz...@gnome.org wrote:
>> I think we should remove this extension immediately.
>
> Hi,
> that sounds quite radical, does it not?
>
> Removing everything what has bugs, instead
On Thu, 2017-05-18 at 15:12 -0500, mcatanz...@gnome.org wrote:
> I think we should remove this extension immediately.
Hi,
that sounds quite radical, does it not?
Removing everything what has bugs, instead of fixing them, what would
you ship to your users?
> It provides limited value,
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> In recent months we have got together to examine the possibilities
> for GNOME’s development infrastructure. We’ve spent a lot of time on
> this, because we want the community to have faith in our conclusions.
> If you are interested in this,
On Fri, May 19, 2017 at 9:55 PM Shaun McCance wrote:
> I don't disagree with anything you're saying. As long as there's an
> easy way to get a list of issues with a specific label across all
> projects (and projects in different groups?), then we'll figure it out.
> And if
On Thu, 2017-05-18 at 18:08 +0200, Andre Klapper wrote:
> On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote:
> >
> > That said, here's a potential pain point: in Bugzilla, you can have
> > different components auto-assign to different accounts, and we made
> > these @gnome.bugs fake accounts
On Thu, May 18, 2017 at 11:36 AM, Andre Klapper wrote:
The Traceparser is another (basically) unmaintained custom extension
we
have in our Bugzilla, with some confusing bugs (e.g. bug 744491).
I think we should remove this extension immediately. It provides
limited value,
Hi,
One thing we missed from the translators requirements is the workflow for
tracking issues. At the moment, there's a "l10n" product [1] at Bugzilla
where users report bugs choosing a language from "Components" list.
My question here is, how things are going to work with Gitlab now that all
On Thu, 2017-05-18 at 12:17 +0200, Milan Crha wrote:
> please, do not forget of Bugzilla integration with backtraces. It can
> colorize them, it can show possible duplicates with score when the
> backtrace is opened in its own window, and it can even notify the
> reporter that the backtrace
On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote:
> That said, here's a potential pain point: in Bugzilla, you can have
> different components auto-assign to different accounts, and we made
> these @gnome.bugs fake accounts for teams. The docs team uses this to
> make it easy to follow docs
On Tue, 2017-05-16 at 10:28 -0400, Carlos Soriano wrote:
> 2- what are the migration plans for bugzilla: bugzilla URL, bug numbers and
> the actual content
[...]
> Also, different projects might have different needs for migration.
While that is true, it is more confusing if I can find all the
On Tue, 2017-05-16 at 17:54 +0100, Allan Day wrote:
> On Tue, May 16, 2017 at 5:36 PM, wrote:
> ...
> > We need a much better migration plan than that. If we don't have a
> > script to migrate Bugzilla issues, comments, and attachments to our
> > new GitLab instance, then we
Hey,
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> [Written on behalf of Alberto Ruiz, Carlos Soriano, Andrea Veri,
> Emmanuele Bassi and myself.]
>
> Please bear in mind that this is just a recommendation! We are not
> claiming to have complete knowledge and we would like to hear
>
of actions to take.
Feel free to put more comments in the comments section
https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/Comments and/or
continue with the emails.
Cheers,
Carlos Soriano
Original Message
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> The outcome of this evaluation process is that we are recommending
> that GNOME sets up its own GitLab instance, as a replacement for
> Bugzilla and cgit.
Hi,
with respect of the cgit, it lets me download sources (snapshot) as
a .zip
On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote:
> That said, here's a potential pain point
Hi,
please, do not forget of Bugzilla integration with backtraces. It can
colorize them, it can show possible duplicates with score when the
backtrace is opened in its own window, and it can
On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano via desktop-devel-
list wrote:
[...]
> >
> > > - git-bz attach equals to git push origin HEAD:fix2340issue, then
> > > click create merge request.
> >
> > Does this rewrite the commit message to include the PR or bug
> > number?
>
> No, as
Hi,
On Wed, May 17, 2017 at 5:59 PM, Mathieu Bridon wrote:
> On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote:
>> On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon > > wrote:
>> > On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
>> > > IMO this
On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon wrote:
> One-time contributions can be done entirely in the web UI, for example:
One-time doesn’t necessarily mean trivial. What you describe is the
workflow for a trivial change. One may still want to clone, compile,
test
On Wed, 2017-05-17 at 17:44 +0200, Jehan Pagès wrote:
> On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon > wrote:
> > On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
> > > IMO this is a completely broken and over-complicated workflow.
> > > For
> > > long term
Hi,
On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon wrote:
> On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
>> IMO this is a completely broken and over-complicated workflow. For
>> long term contributors, having their own remote can be
>> understandable.
>> But for
On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
> Hi,
> […]
> The typical workflow as advised by github (and therefore I believe
> that's similar in gitlab), if not mistaken, is:
Unless you have push privileges, in which case you'd just create a wip-
or feature branch and make a merge
On Wed, May 17, 2017 at 04:36:48PM +0200, Jehan Pagès wrote:
> Hi,
>
> On Wed, May 17, 2017 at 4:30 PM, Zbigniew Jędrzejewski-Szmek
> wrote:
> > On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagčs wrote:
> >> Hi,
> >>
> >> On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano
On Wed, 2017-05-17 at 16:47 +0200, Jehan Pagès wrote:
> IMO this is a completely broken and over-complicated workflow. For
> long term contributors, having their own remote can be
> understandable.
> But for one-time contribs?
One-time contributions can be done entirely in the web UI, for
On Wed, May 17, 2017 at 4:08 PM Mathieu Bridon wrote:
> On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote:
> > > No, as written in the wiki you write "Closes: $number" and it will
> > > handle things automatically.
> > > Of course some addition could be done to do the
Hi,
On Wed, May 17, 2017 at 3:55 PM, Bastien Nocera <had...@hadess.net> wrote:
> On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote:
>> > Original Message
>> > Subject: Re: Proposal to deploy GitLab on gnome.org
>> > Local Time: May 17
On Wed, May 17, 2017 at 01:23:43PM +0200, Christoph Reiter wrote:
> On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès
> wrote:
> > The only thing I am annoyed at is this forking workflow. Both as a
> > contributor, and as a code committer/reviewer. Having to fetch a new
>
On Wed, May 17, 2017 at 2:20 PM Jehan Pagès
wrote:
> On Wed, May 17, 2017 at 2:10 PM, Bastien Nocera wrote:
> > I don't like the fact that the bug report and the merge request are
> > separate.
>
> I don't like this either. This just makes no
Hi,
On Wed, May 17, 2017 at 4:30 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagčs wrote:
>> Hi,
>>
>> On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano
>> wrote:
>> > Ah, I see what you mean now. But then
On Wed, 2017-05-17 at 10:06 -0400, Pat Suwalski wrote:
> On 2017-05-16 07:10 PM, Mattias Bengtsson wrote:
> > How did you install GitLab? We use the omnibus RPM package for
> > CentOS
> > and have had no dependency problems while upgrading from some 7.x
> > release all the way to 9.1.x over the
On Wed, May 17, 2017 at 04:25:09PM +0200, Jehan Pagès wrote:
> Hi,
>
> On Wed, May 17, 2017 at 2:44 PM, Carlos Soriano
> wrote:
> > Ah, I see what you mean now. But then you can rebase yourself in master
> > right? And the build time would be exactly the same no?
>
>
can checkout the rebased branch.
This is possible and not too bad if you have to do it often, actually.
Though it's still going through a lot of hoops.
Jehan
>
> Best regards,
> Carlos Soriano
>
> Original Message ----
> Subject: Re: Proposal to deploy GitLab on gnome.org
&
On Wed, May 17, 2017 at 01:49:21PM +0200, Sébastien Wilmet wrote:
> By attaching a patch to a bugtracker ticket, we loose the information of
> the parent commit: where the commit has been initially created in the
> git history.
If the patch is created by git format-patch, it contains the hash of
On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote:
> If I'm a registered developer for the GNOME org, or that particular
> module, I'd create my merge requests as wip branches in the main
> repo?Or as branches in a separate repo that I have the control of?
That would be up to you. Choose
On 2017-05-16 07:10 PM, Mattias Bengtsson wrote:
How did you install GitLab? We use the omnibus RPM package for CentOS
and have had no dependency problems while upgrading from some 7.x
release all the way to 9.1.x over the last few years. A lot come
bundled in the omnibus package and the rest
On Wed, 2017-05-17 at 15:55 +0200, Bastien Nocera wrote:
> On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote:
> > > Original Message
> > > Subject: Re: Proposal to deploy GitLab on gnome.org
> > > Local Time: May 17, 2017 2:10 PM
> &g
On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote:
> > Original Message
> > Subject: Re: Proposal to deploy GitLab on gnome.org
> > Local Time: May 17, 2017 2:10 PM
> > UTC Time: May 17, 2017 12:10 PM
> > From: had...@hadess.net
Original Message
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 2:10 PM
UTC Time: May 17, 2017 12:10 PM
From: had...@hadess.net
To: Carlos Soriano <csori...@protonmail.com>
desktop-devel-list@gnome.org <desktop-devel-list@gnome.org>
On
Ah, I see what you mean now. But then you can rebase yourself in master right?
And the build time would be exactly the same no?
Best regards,
Carlos Soriano
Original Message
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 2:03 PM
UTC Time: May 17
Hi,
On Wed, May 17, 2017 at 2:10 PM, Bastien Nocera wrote:
> On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-devel-
> list wrote:
>> Do you mean you don't like the extra step that is clicking once per
>> issue the "create merge request" button?
>
> I don't like
On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-devel-
list wrote:
> Hey Bastien,
>
> Not sure if you read the wiki and the workflow we outlined in there,
> since we mention how this works. You will realize that's not
> necessary for you, neither a git-bz alternative since you will
Hi,
On Wed, May 17, 2017 at 1:59 PM, Bastien Nocera wrote:
> On Wed, 2017-05-17 at 13:54 +0200, Jehan Pagès wrote:
>> Hi,
>>
>> On Wed, May 17, 2017 at 1:49 PM, Sébastien Wilmet
>> wrote:
>> > On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote:
Hi,
On Wed, May 17, 2017 at 1:49 PM, Sébastien Wilmet wrote:
> On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote:
>> On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote:
>> >
>>
>> > Most developers are more familiar with the GitHub workflow, I think
>> >
Hi
> On 17 May 2017, at 12:33, Sébastien Wilmet wrote:
>
> On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote:
>> I don't share your optimism about gitlab bug tracking, nor do I share
>> in the mentioned frustration with bugzilla.
>
> Me too, I like bugzilla
is
not rebased properly on top of the master branch (and the UI in GitLab will say
so, so the contributor will need to do it because otherwise there is no fast
forward merge anyway)?
Best regards,
Carlos Soriano
Original Message
Subject: Re: Proposal to deploy GitLab on gnome.org
Hi,
On Wed, May 17, 2017 at 1:23 PM, Christoph Reiter
wrote:
> On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès
> wrote:
>> The only thing I am annoyed at is this forking workflow. Both as a
>> contributor, and as a code committer/reviewer.
On Wed, May 17, 2017 at 11:45:26AM +0200, Bastien Nocera wrote:
> On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote:
> >
>
> > Most developers are more familiar with the GitHub workflow, I think
> > it's
> > an easier workflow than attaching a patch to a bugtracker ticket.
> > Once
> >
arounds now! ;P
So yeah, that's not as bright and simple as it could be.
Jehan
> Cheers,
> Carlos Soriano
>
> Original Message ----
> Subject: Re: Proposal to deploy GitLab on gnome.org
> Local Time: May 17, 2017 12:47 PM
> UTC Time: May 17, 2017 10:47 AM
> Fr
On Wed, May 17, 2017 at 12:47 PM, Jehan Pagès
wrote:
> The only thing I am annoyed at is this forking workflow. Both as a
> contributor, and as a code committer/reviewer. Having to fetch a new
> remote for every single-commit contribution out there is terrible.
In
a patch?
Cheers,
Carlos Soriano
Original Message
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 12:47 PM
UTC Time: May 17, 2017 10:47 AM
From: jehan.marmott...@gmail.com
To: Tristan Van Berkom <tristan.vanber...@codethink.co.uk>, desktop-deve
Hi,
On Wed, May 17, 2017 at 12:33 PM, Sébastien Wilmet wrote:
> On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote:
>> I don't share your optimism about gitlab bug tracking, nor do I share
>> in the mentioned frustration with bugzilla.
>
> Me too, I like
he command line tool we mention in the wiki not
good for you? (you will need some alias for adapting it to your needs, or maybe
we can modify to make the "create merge request" more comprehensible?)
Best regards,
Carlos Soriano
Original Message ----
Subject: Re: Propo
Hi,
On Wed, May 17, 2017 at 11:33 AM, Sébastien Wilmet wrote:
> On Wed, May 17, 2017 at 01:42:15AM +0200, Jehan Pagès wrote:
>> Github/gitlab wants to force you to fork the project into a public
>> repository on your private account so that you can make a pull
>> request. This
On Tue, May 16, 2017 at 11:15:51PM +0900, Tristan Van Berkom wrote:
> I don't share your optimism about gitlab bug tracking, nor do I share
> in the mentioned frustration with bugzilla.
Me too, I like bugzilla (but not for doing code reviews).
What would be the pain points if GitLab is used
On 17 May 2017 at 13:56, Carlos Soriano <csori...@protonmail.com> wrote:
> Hey Arun,
>
> Glad to hear you are positive about the proposal!
>
> Let me answer your points:
>
> Original Message ----
> Subject: Re: Proposal to deploy GitLab on gnome.org
>
On Wed, May 17, 2017 at 3:15 PM, Bastien Nocera wrote:
> On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote:
>>
>
>> Most developers are more familiar with the GitHub workflow, I think
>> it's
>> an easier workflow than attaching a patch to a bugtracker ticket.
>> Once
On Wed, 2017-05-17 at 11:33 +0200, Sébastien Wilmet wrote:
>
> Most developers are more familiar with the GitHub workflow, I think
> it's
> an easier workflow than attaching a patch to a bugtracker ticket.
> Once
> the contributor has pushed a branch on the fork repo, all the rest
> can
> be
On Wed, May 17, 2017 at 01:42:15AM +0200, Jehan Pagès wrote:
> Github/gitlab wants to force you to fork the project into a public
> repository on your private account so that you can make a pull
> request. This is seriously stupid IMO and very poor workflow. That's
> the reason why github/gitlab
Hey Arun,
Glad to hear you are positive about the proposal!
Let me answer your points:
Original Message
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 7:32 AM
UTC Time: May 17, 2017 5:32 AM
From: a...@accosted.net
To: Carlos Soriano <cs
On Wed, May 17, 2017 at 12:04 AM, Mattias Bengtsson
wrote:
> At my work we keep a semi-linear git history:
> - we only allow merges based on the tip of master
> - we always merge with --no-ff (which is what GitLab's merge
>button does)
>
> This gives us
From the migration plan in the wiki:
"Our contention is that copying/moving every existing GNOME issue
to
a new issue tracker is impractical and, in many situations,
undesirable."
May you expand in which many situations is undesirable?
I have tickets in Shotwell that have
d have just git-formatted a patch, I would
have done it).
> Best regards,
> Carlos Soriano
>
> ---- Original Message
> Subject: Re: Proposal to deploy GitLab on gnome.org
> Local Time: May 17, 2017 12:04 AM
> UTC Time: May 16, 2017 10:04 PM
> From: mattias.jc
Hi Pat!
On Tue, 2017-05-16 at 10:41 -0400, Pat Suwalski wrote:
> I only lurk here, so I don't often offer an opinion, but I do
> maintain the GitLab install at my medium-sized company.
I do the same, but our experiences seems to be pretty different.
> My problem with GitLab is how fluid it is.
First off, thank you so much for all your contributions as a user and
contributor. I think all of us appreciate that.
On Tue, May 16, 2017 at 1:27 PM Mirko Crowther via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:
> I'm *AGAINST* any initiative about moving GNOME to either GitLab
decides to switch to GitLab.
Don't worry much about this one :)
Best regards,
Carlos Soriano
Original Message
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 12:04 AM
UTC Time: May 16, 2017 10:04 PM
From: mattias.jc.bengts...@gmail.com
To: desktop
Hi all!
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> The outcome of this evaluation process is that we are recommending
> that GNOME sets up its own GitLab instance, as a replacement for
> Bugzilla and cgit.
This is very exciting! I've been following the plans on the wiki and
the
I'm *AGAINST* any initiative about moving GNOME to either GitLab or Phabricator.
> In recent months we have got together to examine the possibilities for
> GNOME’s development infrastructure. We’ve spent a lot of time on this,
> because we want the community to have faith in our conclusions.
>
On Tue, May 16, 2017 at 2:38 PM Carlos Soriano
wrote:
> That's a nice discussion to have, but a goal on the initiative was to try
> to match what we have now (with the inherited niceties for those
> workflow/use cases), with the less disruption possible, while keeping
ation.
My motivation is to not derive the discussion into details of what we could do,
but rather keep on the big change and what blockers/concerns/disruptions could
cause.
Best regards,
Carlos Soriano
Original Message
Subject: Re: Proposal to deploy GitLab on gnome.org
Local
I agree with Ray. Open ACLs is a big + for GNOME and there are no
significant evidence of abuse of that. Big NO for the artificial
barriers by fine grained ACLs
On 16 May 2017 at 23:51, Ray Strode wrote:
> Hi,
>>
>> It's quite hard to get commit access atm because you have to
Hi,
> It's quite hard to get commit access atm because you have to be
> trusted initially. If a maintainer can give commit access to one repo
> he/she watches anyway there is less trust needed in the beginning. Or
> if a new contributor wants to take over an abandoned project.
>
is that true? I
On Tue, May 16, 2017 at 7:03 PM, Ray Strode wrote:
> Hi,
>
> On Tue, May 16, 2017 at 12:20 PM wrote:
>>
>> Another issue we haven't discussed yet is commit permissions. Right
>> now, everyone can commit anything to every repository, but with GitLab
>>
On Tue, May 16, 2017 at 12:23 PM, mcatanz...@gnome.org wrote:
Some maintainers want this, and I think that will be fine in the
future. I don't really care much either way, because I've never seen
any intentional abuse, and if someone commits something wrong to one
of my projects I can simply
On Tue, May 16, 2017 at 12:03 PM, Ray Strode wrote:
Hi,
On Tue, May 16, 2017 at 12:20 PM wrote:
Another issue we haven't discussed yet is commit permissions. Right
now, everyone can commit anything to every repository, but with
GitLab
we'll
Hi,
On Tue, May 16, 2017 at 12:20 PM wrote:
> Another issue we haven't discussed yet is commit permissions. Right
> now, everyone can commit anything to every repository, but with GitLab
> we'll probably eventually want something more fine-grained where
> *active*
On Tue, May 16, 2017 at 5:36 PM, wrote:
...
> We need a much better migration plan than that. If we don't have a script
> to migrate Bugzilla issues, comments, and attachments to our new GitLab
> instance, then we should not be considering using GitLab's issue tracker at
>
mcatanz...@gnome.org wrote:
> > Does the plan consider a tool like bugzilla2gitlab, but removing
> > the part that copy the accounts?
>
> We need a much better migration plan than that. If we don't have a
> script to migrate Bugzilla issues, comments, and attachments to our
> new GitLab
On 16 May 2017 at 15:23, Carlos Soriano wrote:
> Glad to hear that. Could you mention what projects relevant for GNOME
> (either part of GNOME already or not) that you are maintainer of would
> benefit of a transition to GitLab?
Of immediate benefit would be
On Tue, May 16, 2017 at 11:12 AM, Germán Poo-Caamaño
wrote:
From the migration plan in the wiki:
"Our contention is that copying/moving every existing GNOME issue
to
a new issue tracker is impractical and, in many situations,
undesirable."
May you expand in which
Another issue we haven't discussed yet is commit permissions. Right
now, everyone can commit anything to every repository, but with GitLab
we'll probably eventually want something more fine-grained where
*active* maintainers have more control over who is allowed to commit.
Currently we still
On Tue, May 16, 2017 at 6:23 AM Allan Day wrote:
>
> We are confident that GitLab is a good choice for GNOME, and we can’t wait
> for GNOME to modernise our developer experience with it. It will provide us
> with vastly more effective tools, an easier landing for newcomers, and
On Tue, 2017-05-16 at 10:28 -0400, Carlos Soriano via desktop-devel-
list wrote:
> Hello Hubert,
>
> [...]
> 2- what are the migration plans for bugzilla: bugzilla URL, bug
> numbers and the actual content
> In the wiki we outline what our plans are. However this is a moving
> target based on the
On Tue, May 16, 2017 at 9:49 AM, Tobias Mueller
wrote:
Hi.
I welcome the proposal to modernise our development infrastructure.
On Di, 2017-05-16 at 10:38 -0400, Carlos Soriano via
desktop-devel-list
wrote:
You can take a look at their "changelogs" between releases
On Tue, 2017-05-16 at 16:24 +0100, Emmanuele Bassi wrote:
> On 16 May 2017 at 16:17, Germán Poo-Caamaño wrote:
>
> > Another potential pain point: in Bugzilla, one can move bugs
> > between
> > products. This happen when the bug has been reported to the wrong
> > product, or when
On 16 May 2017 at 16:17, Germán Poo-Caamaño wrote:
> Another potential pain point: in Bugzilla, one can move bugs between
> products. This happen when the bug has been reported to the wrong
> product, or when triaging the bugs the developers know the bug is
> somewhere else in
On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote:
> On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> > The outcome of this evaluation process is that we are recommending
> > that GNOME sets up its own GitLab instance, as a replacement for
> > Bugzilla and cgit.
>
> I 100% support this
On Tue, May 16, 2017 at 3:51 PM, Shaun McCance wrote:
> On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> > The outcome of this evaluation process is that we are recommending
> > that GNOME sets up its own GitLab instance, as a replacement for
> > Bugzilla and cgit.
>
> I
.
Then we polished and minimized the wiki with the final decision in mind for
helping on getting an overview, so that's probably why you see the wiki is
written in that way.
Hope is clear now :)
Cheers,
Carlos Soriano
Original Message
Subject: Re: Proposal to deploy GitLab
1 - 100 of 113 matches
Mail list logo