I have sent this email for serval days before, but have not received any
response for this, so send this email again.I am through the GSoC in 2016
and find GitLab/development tools integration
GSoC, and I am interested in this project. I have built gitlab for my lab
and integrated the CI system, and I am maintaining it now. I am enrolled
under Computer Science and Technology for master degree in Tsinghua
University, and it's my first year.
*My Programming skills:*
- Comfortable with coding in Python and also have good experience in
- Comprehensive experience in application development, such as web,
desktop applications, especially in python.
- Experience in using git version control system for about three years.
- Strong ability for algorithms and data struct.
Looking forward to your favorable reply.
Database Research Group,
Department of Computer Science and Technology,
Tsinghua University, Beijing, China, 100084
Note that these are my personal thoughts and nothing official. :-)
On 03/21/2016 10:50 PM, Shubham Ghiya wrote:
> My name is Shubham Ghiya, a 3 year undergraduate from IIIT-Hyderbad.
> I was going through the GSOC 2016 ideas and found "GitLab/development tools
> integration" project interesting.
> I have setup the mailman and postorius and have tried my hand on some bugs
> also.Right now,I am learning more about hyperkitty which will help me learn
> more about the implementation details for the project.I have a good
> understanding of functionality of various modules and how mailman works. I
> have also read the chapter on mailman by Barry Warsaw to understand mailman
> in a much better way.
> For the project "GitLab/development tools integration" I figured out that
> we are expected to create a tool that will extract the contents of the mail
> on a mailing list and create an issue of it on Gitlab/Github through
> various Gitlab/hub API's and python libraries.
> 1. For the extraction part Hyperkitty will be used from where we can
> extract and parse the contents of the mail.
Please note that it should be a thread not just one message of a thread.
> 2. For creating an issue on Gitlab, different API's will be used which I
> have to figure out yet.
It would be nice if you design your project so that it can be used with different
providers/API's. You could add supporting Github, launchpad, etc. to your stretch goals.
> I know the above points are a very naive and a basic approach. Please tell
> me if I am thinking in the right direction and how to proceed further.
I think the most challenging part is to implement a UI that let's the users decide what gets
included in the issue and what not. (Which messages of the thread, which parts of a message,
As this is only targeted at lists used by developers it would be nice if the plugin for hyperkitty
is optional meaning you don't need to have it installed at all and if you have it installed, you
don't need to enable it for a list.
There might be other practical ways to trigger the creation of an issue.
For instance by including specific headers in the email or putting a special string in the subject.
I don't think you need to do that, but if you want something challenging you can think about it.
On Mar 13, 2016, at 03:01 AM, Harshit Bansal wrote:
>Sorry, I think I have used wrong terminology here. By 'copying' I
>actually meant 'inheriting'.
Just a quick follow up to my previous comment about multiple inheritance. I
was thinking about the way it's done in the Python code now, but even there, a
specific ordering is imposed (see LegacyDefaultStyle.apply() and
The point of this break down is because some things (and it's not a perfect
separation) really won't be shared between mailing lists. OTOH, you might
want site-wide bounce settings that all lists will inherit and shouldn't be
able to change. Other sub-styles give the list its "flavor", i.e. an open
discussion list where anyone can join just by confirming their email, or a
one-way announcement list that can't be unsubscribed from because it's an
I know this gets complicated quickly and I don't mean to throw a wrench into
things. Harshit, I think you're essentially on the right track and Steve is
right that we should be careful not to overengineer the whole thing. I think
you've got enough ideas, input, feedback, and comments to have plenty of fun
with it, and no doubt you'll discover a lot as you work out the details and
On Mar 22, 2016, at 10:37 PM, Aditya Divekar wrote:
>So according to what I've gathered from the conversation, the fall back on
>the user name can be made implicit. The user name is to be always used in
>case of missing display name for the subscribed address.
>The feature for suggesting the display names from the other records i.e.
>linked via the user, but not subscribed, could, as suggested, be raised in
>postorius for the UI part.
Right, and thus, not in core.
>@Barry The mr code would first check if a display name is provided while
>subscription i.e. `member.address.display_name`. If not, it will check if
>the linked user has a display name and use that if it exists
>i.e. `member.user.display_name`. And as a final case when both these fail, it
>will use an empty string. I'll go ahead and make these changes.
Yes, I think that's it.
On Mar 17, 2016, at 11:27 PM, Aditya Divekar wrote:
>Suppose you have a user with two linked addresses, one of which is the
>preferred address. Only the preferred address has a display name, and the
>user does not. Now in the scenario where the other linked address(not the
>preferred one) is subscribed to a mailing list without providing a display
>name, it would be natural to check if the user has a display name, and use
>that if it exists. But the user too does not have a display name in this
>case. In such a case should we perform a further check and try to use the
>preferred address's display name if it exists or simply use an empty string
>In the opinion I gave, in case we are not supplied with a display name, we
>should check the user display name followed by the preferred address
>display name, and use them in the specified order respectively. If none
>exist, empty string would be used.
>In a more general scenario, as pointed out by Barry to question this
>method, suppose a user has multiple linked addresses, only one of which has
>a display name, and its neither the preferred address, nor the subscribed
>address. Should the display name search algorithm find that one too, since
>it still is a linked address for the user and hence contains valid user
One other comment. In the more general case I outlined (i.e. your last
paragraph), *if* we decide to use display_names in other linked addresses, we
can only use ones that are associated with validated addresses. A user's
preferred address will always be validated.
The other thing about the more general case is that there's no natural
ordering. So yes, we could use the preferred address first, and then pick an
arbitrary ordering criteria for falling back to all linked, validated
addresses. That could be alphabetical by email address, or chronological by
validation or registration date.
On 2016-02-28 1:34 PM, aahan bhatt wrote:
> Please explain about the gitlab integration in layman terms. I would like
> to contribute to the project.
Gitlab integration can mean a lot of things, and we've left this
particular project pretty open to see what people will suggest.
The tweet linked talks about moving a discussion from a mailing list to
a bug tracker. So imagine that you have a bunch of people discussing an
issue on a mailing list and after a few posts someone says "hm, that
configuration didn't work the way I expected, this sounds like a bug,
maybe we should file it" -- we want a way to dump the whole discussion
into a bug so when someone goes to fix it they have all the information.
You'd need to think a bit about privacy (were the mailing list posts
public? what about the bug tracker?) and relevance of information (what
if I only want some of the posts? what if I want to link the discussion
but only provide a summary?) to go from the idea of "make it easier to
file bugs using information from a mailing list discussion" to an actual
workable interface for doing that, but that's the core of it.
If you want to understand the whole gitlab integration idea better
beyond that one use case, try brainstorming a little bit about how the
pieces could work together. How could a mailing list integrate better
with a bug tracker? How could it integrate better with merge requests?
What information would people want to pass from one system to the
other and why?
For an example you might want to take a look at idea #27 on this page:
My name is Shubham Ghiya, a 3 year undergraduate from IIIT-Hyderbad.
I was going through the GSOC 2016 ideas and found "GitLab/development tools
integration" project interesting.
I have setup the mailman and postorius and have tried my hand on some bugs
also.Right now,I am learning more about hyperkitty which will help me learn
more about the implementation details for the project.I have a good
understanding of functionality of various modules and how mailman works. I
have also read the chapter on mailman by Barry Warsaw to understand mailman
in a much better way.
For the project "GitLab/development tools integration" I figured out that
we are expected to create a tool that will extract the contents of the mail
on a mailing list and create an issue of it on Gitlab/Github through
various Gitlab/hub API's and python libraries.
1. For the extraction part Hyperkitty will be used from where we can
extract and parse the contents of the mail.
2. For creating an issue on Gitlab, different API's will be used which I
have to figure out yet.
I know the above points are a very naive and a basic approach. Please tell
me if I am thinking in the right direction and how to proceed further.
Thank you for your time. Looking forward to hear from you.
IRC - shubham__
On Mar 21, 2016, at 03:47 AM, Anirudh Dahiya wrote:
>1. Reliability - Currently, as I see, the messages are archived in
>Hyperkitty via a simple POST request, but in the event of some failure(like
>hk server being down for a while), there is no way the message is being
>tried to be archived again. Thus are we aiming to add some reliability to
>the system via the message queue systems?
I think that's correct. Currently if we can't deliver to HK, the message
doesn't even get shunted.
>Apart from this and extensibility, what all advanteges are we looking
>forward to as a result of this project?
I think part of it should also be a more robust distributed architecture. We
do have some separation now because submitting to HK is a POST, but it still
requires a localhost connection (for security purposes).
>2. Should I add/mention the potential scope for adding mailman events (like
>list creation etc) to our archivers?
>3. Am I supposed to alter Hyperkitty(as what seems to be mentioned in the
>project description) or should the basic scope of the project stay about
>building the pub/sub or message queue interface(as what seems to be mentioned
>by some of our conversations on irc)
That's up to Aurelien I think. The model of the HK plugin is a good one to
follow though because the pub/sub doesn't necessarily need to be part of Core.
Hi,I am a third year Engineering student and had been working on django and python for almost 3 years. My biggest project is developing a hospital web application which is funded by my college. I would like to know the Details of above project and would need some help while drafting the proposal.