Sounds like a bug in their migration/etc tool. MS has history going
back to 1984 and migrated everything to Git with zero problems.
At some point you should apply Ionescu's Razor: "Hmmm, a company of
150,000 developers and the most complicated and oldest series of
repositories in the world, was able to move to Git, including while
employing people who have been there for 30 years and used to other,
older systems.... but 30 open source developers can't make that change
because X". It follows from this that X is bullshit.
On the polluting history, again, just read commits that have [FOOBAR]
in them, and ignore others. Write a post-commit hook to rewrite/squash
them.
Best regards,
Alex Ionescu
On Thu, Feb 16, 2017 at 9:41 AM, Zachary Gorden
<drakekaizer666(a)gmail.com> wrote:
> The project that I worked with using git has history going back to 1988.
> They certainly didn't start with git, nor did they necessarily start with
> any revision control at the beginning, but after they migrated to it they
> discovered the history problem.
>
> On Thu, Feb 16, 2017 at 10:42 AM, Colin Finck <colin(a)reactos.org> wrote:
>>
>> Am 16.02.2017 um 14:40 schrieb Alex Ionescu:
>> > That being said, that type of "dirty history" only happens if you
>> > heavily work with branches. That's not how reactos developers work -- we
>> > don't open PRs and separate branches for every checkin.
>> >
>> > These ALL sound like manufactured problems or poor/strange use of git.
>>
>> That merge hell is easily reproducible using my default Git setup:
>>
>> 1) Change something in your clone of master and do a "git commit".
>> 2) Let someone else change something in his clone of master and let him
>> "git commit" and "git push" it.
>> 3) Try to "git push" your commit, won't work because of the commit of
>> the other person.
>> 4) Do a "git pull" to fix the problem in 3) -> Bam! Git will do an
>> automatic merge of both masters and pollute your history.
>>
>> You see, not a single extra branch is involved and yet we get two
>> parallel streams of history.
>>
>> Rafal's mentioned "pull.rebase" option sounds promising, but can we
>> enforce that somehow?
>>
>>
>> - Colin
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
Hi all!
Daniel and me collected some additional ideas for GSoC today, which I've
added to our Wiki Ideas list:
https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas
In particular:
* Fundamental WiFi components
* USBXHCI driver for supporting USB 3.x controllers
* Bluetooth Stack
* WebKit-based MSHTML implementation
I'm open for comments and suggestions!
We can still add ideas until March 20, so let's give students a large
pool to draw from.
Cheers,
Colin
Am 16.03.2017 um 00:00 schrieb Giannis Adamopoulos:
> I was wondering if it is possible to delete every second iso instead of purging all isos before some time?
That's a good idea and makes sense for the bootcd-dbg ISOs.
So my final proposal is this one:
bootcd-dbg: 5 years (after that every second ISO is purged)
bootcd-dbgwin: 0.5 years
bootcd-rel: 0.5 years
bootcdregtest: 1 week
livecd-dbg: 0.5 years
livecd-dbgwin: 0.5 years
livecd-rel: 0.5 years
I'll be away until the beginning of April, so there is enough time for
any objections.
Otherwise, it will be set up exactly this way when I'm back.
- Colin
Hello everyone,
I am a Masters student and want to do the GSoC with this organization this
summer. I have gone through the list and found some projects domain
interesting but I couldn't research in the depth of the project due to
resource and time constraint at the moment.
I have some professional background in working with embedded software
development (mostly C programming), networking stacks and an RTOS porting.
Did some work in Linux development as well. I will be thankful if someone
can guide me chose the best suitable project that is beneficial for myself
and the organization at the same time. Currently, I have a look at
following projects:
Bluetooth Stack
Integrating SMB into ReactOS
Kernel mode test suite
WebKit-based MSHTML implementation
Support for the GPT Partitioning Scheme
Taskbar Shell extensions
If someone is interested in mentoring anyone of the above project, I will
be happy to talk more on that and submit a timely proposal.
Thanks a lot and best regards,
--
M Abdul Rehman
Dear all,
I'm a student interested in working for ReactOS. I've previously worked
with ReactOS(not GSOC). I've looked into xHci project, as I don't have prev
experience in writing drivers I'm a bit baffled.
>From what I've seen Johannes Anderwald , Michael Martin and Hervé
Poussineau have contributed most to the development of USB code. Is anyone
available to mentor me for this project?
Thanks in advance,
Rama Teja.G
Hi there,
I am under the impression that no mentor can be assigned to my audio mixer
proposal. Can someone confirm this or the opposite? If so I would like to
create a proposal on "Improving the quality of our Registry Hive
implementation", but since I don't have much time left and I haven't gone
through the relevant code, I would really appreciate it if you point me to
the mentor for this project.
Thank You
--
*Pranay Pratyush,*
3rd year undergraduate ,
Computer Science and Engineering Department
Indian Institute Of Technology, Kharagpur
--
Hello .
I am call atemafac kingsley. i am an undergraduate computer engineering student.
please i will like to take part on google summer of code . this is the time i am applying .
so i will like to be directed on how i can contribute .
thanks.
University of Beua Cameroon.
Hi all!
As you all know, our #reactos-dev IRC channel has been a moderated IRC
channel for decades, and only operators (devs) and voiced people can
talk. While we always tried to keep discussions dev-related there, no
topic has ever been enforced on #reactos. The result is that I see a
notable number of developers only on #reactos-dev these days.
This is a pretty bad situation! Emerging developers hardly have a way to
interact with all existing devs on IRC. Often enough, legitimate
questions from them remain unanswered on #reactos. Moreover, we don't
maintain the list of voiced people thoroughly, so even some contributors
have to ask for temporary voice on #reactos-dev.
Keep in mind that we're currently in the GSoC phase where students shall
submit their proposals and get in touch with the developers.
How are they going to do this on IRC if #reactos-dev continues to be an
exclusive club?
Because of these reasons, I'm proposing to remove the moderation bit on
#reactos-dev and let everybody talk there.
Its development topic should be enforced though! As soon as people get
too off-topic, they should be directed to #reactos and kicked if nothing
else helps. Given that all devs are already operators on #reactos-dev,
it's fully in their hands.
Cheers,
Colin
I don't agree. Maintain the auto-voice lists and get someone in charge of
operations, like I used to be for many years on IRC.
Instead, why not create a #reactos-gsoc or something?
Best regards,
Alex Ionescu
On Fri, Mar 24, 2017 at 11:19 AM, Mark Jansen <learn0more+ros(a)gmail.com>
wrote:
> We can always try it out?
> If it doesnt work, restoring it is a simple as setting a flag on the
> channel.
>
> On 24 March 2017 at 16:31, David Quintana (gigaherz) <gigaherz(a)gmail.com>
> wrote:
> > I disagree -- if we can be firm about the channel being only for
> development
> > talk, things should remain mostly as they are now.
> >
> > In any community, there's inevitably going to be idle talk, offtopic
> > conversations, etc. If you only have ONE place to talk in, all those
> thigns
> > are going to be mixed in with actual dev talk, but if you have clear
> rooms
> > set for each thing, the majority of people will be happy to leave all the
> > offtopic talk to the main channel, and dev talk to the dev channel.
> >
> > It works for plenty other projects and communities so there's no reason
> to
> > be pessimistic and think that "our idiots are worse". It's simply not
> true.
> >
> > I vote for trying, and we can always put back the +m if things get out of
> > hand.
> >
> > On 24 March 2017 at 16:13, Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr>
> > wrote:
> >>
> >> I don’t approve the idea. The fact is that if the devs quit originally
> >> #reactos, it’s because it was generally too noisy, etc… . If we remove
> the
> >> moderation irc bit in #reactos-dev, you may expect the same phenomenon
> to
> >> occur in #reactos-dev too.
> >>
> >>
> >>
> >> De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de David
> >> Quintana (gigaherz)
> >> Envoyé : vendredi 24 mars 2017 11:35
> >> À : ReactOS Development List
> >> Objet : Re: [ros-dev] Opening up #reactos-dev to the public
> >>
> >>
> >>
> >> I approve the idea.
> >>
> >>
> >>
> >> On 24 March 2017 at 11:21, Colin Finck <colin(a)reactos.org> wrote:
> >>
> >> Hi all!
> >>
> >> As you all know, our #reactos-dev IRC channel has been a moderated IRC
> >> channel for decades, and only operators (devs) and voiced people can
> >> talk. While we always tried to keep discussions dev-related there, no
> >> topic has ever been enforced on #reactos. The result is that I see a
> >> notable number of developers only on #reactos-dev these days.
> >>
> >> This is a pretty bad situation! Emerging developers hardly have a way to
> >> interact with all existing devs on IRC. Often enough, legitimate
> >> questions from them remain unanswered on #reactos. Moreover, we don't
> >> maintain the list of voiced people thoroughly, so even some contributors
> >> have to ask for temporary voice on #reactos-dev.
> >>
> >> Keep in mind that we're currently in the GSoC phase where students shall
> >> submit their proposals and get in touch with the developers.
> >> How are they going to do this on IRC if #reactos-dev continues to be an
> >> exclusive club?
> >>
> >> Because of these reasons, I'm proposing to remove the moderation bit on
> >> #reactos-dev and let everybody talk there.
> >> Its development topic should be enforced though! As soon as people get
> >> too off-topic, they should be directed to #reactos and kicked if nothing
> >> else helps. Given that all devs are already operators on #reactos-dev,
> >> it's fully in their hands.
> >>
> >>
> >> Cheers,
> >>
> >> Colin
> >>
> >> _______________________________________________
> >> Ros-dev mailing list
> >> Ros-dev(a)reactos.org
> >> http://www.reactos.org/mailman/listinfo/ros-dev
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Ros-dev mailing list
> >> Ros-dev(a)reactos.org
> >> http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
On 2017-03-12 10:48, gadamopoulos(a)svn.reactos.org wrote:
> // *** IServiceProvider methods ***
> HRESULT STDMETHODCALLTYPE CExplorerBand::QueryService(REFGUID guidService, REFIID riid, void **ppvObject)
> {
> - UNIMPLEMENTED;
> - return E_NOTIMPL;
> + /* FIXME: we probably want to handle more services here */
> + return IUnknown_QueryService(pSite, SID_SShellBrowser, riid, ppvObject);
> }
This seems dangerous. If someone requests something other than
SID_SShellBrowser, we'll just return them a different object without
any indication that something is wrong.
Shouldn't we either pass guidService down or fail somehow if it's not
asking for ShellBrowser?
