[Reproducible-builds] [GSoC 2016] : Application review
Jérémy Bobbio
lunar at debian.org
Wed Mar 23 14:26:35 UTC 2016
Satyam Zode:
> >> Official coding period.
> >> 3) Week 1 - 2 (May 27 - June 9):
> >> - Work on "Allow users to ignore arbitrary differences" part.
> >> - Work simultaneously on unreproducible packages.
> >
> > How much time are you going to give to the community so they can review
> > your proposed user interfaces?
> >
> I think, I will be ready with a design of above by 1st May. After that
> till 10th May we can discuss user interfaces because from 11th May I
> will have exams so I won't be available for active discussions. If
> some things will be remained to discuss then we can always discuss
> alongside during a coding period.
Mh… I was not expecting you to work during the community bounding
period, but it's your call.
> >> 4) Week 3 - 4 (June 10 - June 22):
> >> - Work on Parallel processing part.
> >> - Work simultaneously on unreproducible packages.
> >
> > This is unlikely to work. Implementing parallel processing requires
> > deep focus because it's also about adding missing locks and
> > understanding subtle concurrency issues.
> >
> > How much experience do you have with concurrent programming?
> I have good experience with concurrent programming. I have written
> many concurrent programs in golang and I believe it'll help me here.
>
> > I think you underevaluate how hard this is to get right. To the very
> > least you shoud be entirely focused on this and not fixing packages at
> > the same time.
> I understand that this is not going to be a piece of cake for me.
I believe it applies to you as well as anyone else. I've been working
myself on and off on that code for six months without getting it to a
point where it was stable enough to be usable! It's reassuring that you
have previous experience in concurrent programing.
> However, If we remove fixing of packages from this schedule then I
> will get enough time to concentrate on this particular problem.
Alright. :)
> In my opinion, there must a buffer time in software development
> process for any unexpected incidence. Hence, I am planning to keep
> this time as a buffer time. What do you think about it ? (Of course, I
> will devote this time for community work only).
If you feel you need buffer time, then let's call it that way. :)
I'd rather have it stated as such than promising stuff you should be
doing along the way.
--
Lunar .''`.
lunar at debian.org : :Ⓐ : # apt-get install anarchism
`. `'`
`-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20160323/80de6308/attachment.sig>
More information about the Reproducible-builds
mailing list