[E-devel] Contributing

2018-08-30 Thread Diego Loiola
Hello everyone!

I've installed  Enlightenment a couple of days ago and found an amazing and
promising project. It is smooth, beatiful, has some features which others
DEs don't , and i'ts even lighter than XFCE. As I see a great pontential,
though it has some problems, I would like to help its evolving if it's
possible. I'm writing a list of the best features and others to improve
(documentation, themes, etc...). I'm designer and an newbie programmer, so
I can translate to pt-br, draw, make usability tests, and so on.


Best regards,

Diego Loiola
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Gitlab

2018-08-30 Thread Daniel Kolesa
On Thu, Aug 30, 2018, at 10:41, Stefan Schmidt wrote:
> Hello.
> 
> On 08/28/2018 05:08 PM, Stephen Houston wrote:
> > Hello,
> > 
> > Just checking in here on the status of this - Does there need to be a
> > slowvote or does it seem that everyone is on board here or do people
> > disagree and want to voice why?
> 
> I have not replied to this so far (a longer reply to Mike's mail will
> come in a bit).
> 
> There can be seen some support in this thread, but I honestly think we
> are missing opinions from many other active people before we should go
> further here. In particular I would like to hear opinions from hermet,
> bu5hman, netstar, q66, raster, vtorri, xavi, chris, derek, yohoho, beber
>  and more I forgot.

>From my side, I fully support a move to another system, be it Gitlab or 
>something else, as long as there is a reasonable git integration with a pull 
>request system. I'd prefer self-hosting but when it comes to it I realize that 
>it might not be possible with our current server situation, so I won't be 
>against a hosted solution either.

D5

> 
> A slowvote that would ask for general acceptance of a move to gitlab
> (not on all the details) might be a good step to understand if the
> people not commented yet are in the yes, no or don't care camp.
> 
> More detailed comments on the proposal in a separate mail.
> 
> regards
> Stefan Schmidt
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Gitlab

2018-08-30 Thread Xavi Artigas
Hi,

Since you explicitly asked for my opinion... I know git, but I have never
used Gitlab (or Github) to submit patches for review, and I only learned
Phab when I got here. Therefore I have too little background to be of any
help, I think

However, if somebody could explain what would change regarding the current
process (Instead of "arc diff" what would I need to do? Would "Tasks"
become "Issues"?) I would appreciate it.

Once thing that jumped at me is that we would miss all the comments on the
patch reviews? Don't we have an awful lot of information there?
Also, playing with the prototype at
https://gitlab-prototype.s-opensource.org/, I do not se the hierarchical
dependency of tasks. Would it be gone?

Xavi

On Thu, 30 Aug 2018 at 10:42, Stefan Schmidt 
wrote:

> Hello.
>
> On 08/28/2018 05:08 PM, Stephen Houston wrote:
> > Hello,
> >
> > Just checking in here on the status of this - Does there need to be a
> > slowvote or does it seem that everyone is on board here or do people
> > disagree and want to voice why?
>
> I have not replied to this so far (a longer reply to Mike's mail will
> come in a bit).
>
> There can be seen some support in this thread, but I honestly think we
> are missing opinions from many other active people before we should go
> further here. In particular I would like to hear opinions from hermet,
> bu5hman, netstar, q66, raster, vtorri, xavi, chris, derek, yohoho, beber
>  and more I forgot.
>
> A slowvote that would ask for general acceptance of a move to gitlab
> (not on all the details) might be a good step to understand if the
> people not commented yet are in the yes, no or don't care camp.
>
> More detailed comments on the proposal in a separate mail.
>
> regards
> Stefan Schmidt
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Gitlab

2018-08-30 Thread Simon Lees


On 30/08/2018 18:57, Stefan Schmidt wrote:
> Hello.
> 
> On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote:
>>
>> Q: Where would this be hosted?
>> A: The provided link here is a cloud service which will be funded for the
>> foreseeable future.
> 
> This is a crucial point here. Business decisions change and the
> community has no influence on this. With my community hat on I
> appreciate that there would be a sponsoring of a cloud service, but I
> truly think we should not depend on this mid or long term (having it run
> there for a few month of migration would not worry me).
> Even if it would be more paperwork having the sponsorship going to the
> foundation and the service being paid out from there would be the right
> way. We can acknowledge the sponsorship on our sponsors page.
> 

I tend to agree here, unless we knew we had a simple easy way to migrate
it to other hosting at anytime we needed.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Gitlab

2018-08-30 Thread Stefan Schmidt
Hello.

On 08/10/2018 08:15 PM, Mike Blumenkrantz wrote:
> To list some pros and cons for a switch:
> 
> PROS:
> * Greatly improved patch review UI
> Gitlab is similar in workflow and usage to Github, so it will be much
> easier to use the patch review tools

What patch review tools are you talking about here besides the web UI?

> * Simplified patch submission workflow
> Gitlab uses git and does not require external tools such as arc/git-phab

This is indeed a very big plus in my view. The move from arc to git-phab
helped but its still cumbersome compared to just use git directly.

> * Actively developed
> Phabricator is basically closed-source at this point, and they develop only
> as they decide to or as people pay them to. Gitlab is open source and the
> developers actively reply to tickets and fix issues

I would not go as far as calling it closed source. They have a clear
view and agenda they want phab to develop into. Problems arise if this
is not the same vision we want to use phab and if we have little
influence. On the other hand it is not like we have been really dicing
into it and proposed patches to them in a big way either.

> CONS:
> * Does require having people manage a migration

A key point. Who would handle the migration and do all the manual work
involved? I remember that Daniel and Tom spend many, many days on the
git and phab migration.

Is the intern without name available to do this? If not who else would
do it?

> * Will take time to migrate

As I outlined in my other mail I would expect several iterations with
reviews of the results, moving a project at a time over when happy.

> * Will take time to adjust to new tools/workflows

It would also mean updating our docs on contributions (as sparse as they
might be)

One con missing here is the fact that the language of the system used is
switching from php to ruby. Personally I do not care, but we had
modifications on the phab code in the past to help against some spam
attacks. With php that was possible because people here with C
background just hacked on it. To the best of my knowledge we have nobody
with a ruby background here though. We could hope that we never come
into the situation that we would need to modify it, but its a risk we
need to keep in mind.

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Gitlab

2018-08-30 Thread Stefan Schmidt
Hello.

On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote:
> 
> https://gitlab-prototype.s-opensource.org/

Thanks to the intern without name to get a real PoC out for this.
While people have advocating for such a move no one before her/him spent
the actual time to get this demonstrated!

This will help us to understand the details of a potential move way better.

> 
> Some notes:
> * This is read-only for now
> * User creation is disabled, don't bother trying
> * Issues with their comments have been imported

Cool

> * Patch submissions have been imported (the intern screwed up some of the
> early imports so there are a few patches without the diff inlined)
>   - Comments on patch submissions cannot be imported because Phabricator
> has no API for retrieving comments on patch review

That is a bit of a pity. One could think of scraping the original
diffusion web pages for the comments. Not sure if it would really be
worth the effort spent on a script doing that.

If we are able to clear out our patch queue enough this issue would minor.

> * Wiki pages are not imported since some decision-making is required
> 
> As is easily noticeable, not all projects have been imported by my intern.
> Importing the repo takes some time on its own, and then running the
> migration script takes a variable amount of time on top of that depending
> on the size of the project (EFL was estimated to take 10+ hours to fully
> import).

As a first demonstration this helps already. If the community wants to
go this way we can have further steps where we import more projects and
check for consistency and sanity. I would expect there would be several
of such cycles before we are happy and would make a final switch

> Wiki pages have not been imported. On Gitlab, a wiki is project-specific
> and so it is impossible to do a 1:1 copy unless we decided to stick
> everything onto a specific project. We would have to decide how we want to
> do this.

Hmm. The way we used the phab wiki was really for the overall community
and not individual projects. Having said that I would think that most of
the wiki pages could be attached to efl, EFL or Terminology. The rest
will most likely be pages on process (commits guidelines, releases, etc)

There will also be a ton of outdated pages which could simply be removed.

In the end we would need to go through all of them and decide what to
do. e.g move process docs into dokuwiki, remove outdated ones, move to a
specific project.

If we should do this sortign before or after me moved all pages over I
am on the fence. It would be cleaner to only import the sorted pages but
that can delay the move for some time.

> If we decided to switch to Gitlab, there would be a number of questions
> that need to be answered:
> Q: How do we migrate?
> A: Gitlab cannot accurately mirror all of Phabricator, it can only do a
> one-time migration of projects. This means we would at some point lock phab
> and then begin migrating, likely over a weekend for the major projects with
> the remainders being added later.

As written above I would expect that we would have more trial runs on
the migration while fine tuning the script and reviewing the results. If
we are happy with what we have for a project we could lock it for a
weekend and move the projects over.

> Q: What happens to phab?
> A: We would likely want to keep phab in read-only mode for a while after
> the migration since all the migrated tickets/patches will provide links to
> it. We can later evaluate if we need to keep it running.

With all the reference to tickets and differentials we might need keep
it around read only for a long time. The alternative would be to have
all the old issues and differentials imported as well and have a
re-write mapping for the links in our http server. Not very attractive
either.

> Q: Where would this be hosted?
> A: The provided link here is a cloud service which will be funded for the
> foreseeable future.

This is a crucial point here. Business decisions change and the
community has no influence on this. With my community hat on I
appreciate that there would be a sponsoring of a cloud service, but I
truly think we should not depend on this mid or long term (having it run
there for a few month of migration would not worry me).
Even if it would be more paperwork having the sponsorship going to the
foundation and the service being paid out from there would be the right
way. We can acknowledge the sponsorship on our sponsors page.

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Gitlab

2018-08-30 Thread Stefan Schmidt
Hello.

On 08/28/2018 05:08 PM, Stephen Houston wrote:
> Hello,
> 
> Just checking in here on the status of this - Does there need to be a
> slowvote or does it seem that everyone is on board here or do people
> disagree and want to voice why?

I have not replied to this so far (a longer reply to Mike's mail will
come in a bit).

There can be seen some support in this thread, but I honestly think we
are missing opinions from many other active people before we should go
further here. In particular I would like to hear opinions from hermet,
bu5hman, netstar, q66, raster, vtorri, xavi, chris, derek, yohoho, beber
 and more I forgot.

A slowvote that would ask for general acceptance of a move to gitlab
(not on all the details) might be a good step to understand if the
people not commented yet are in the yes, no or don't care camp.

More detailed comments on the proposal in a separate mail.

regards
Stefan Schmidt


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel